dogweather / asset_ram Public

My app has been amazingly efficient since using these: memory usage stays flat at just 50% usage (512MB) for 4 Puma workers. It's very quick, with production response times averaging 37ms a Heroku 1GB Standard-2x Dyno.

Some of my app's views are an exception, however. It's multi-tenant and the views serve content for several sub-domains. And so the call to #cache allows extra key info to be passed. In my HTML HEAD view, I have a site variable for choosing the CSS file for the domain:

In an effort to help my app run in a small 512MB virtual server, I looked through every view invocation in the logs. After I optimized a bunch of my code, I realized that the asset helpers create a relatively large amount of objects. The code is pretty complex too implying some amount of CPU overhead. Moreover, this work is done over on every request.

These asset fingerprints are potentially re-generated on every deploy. So they can't be stored in the usual Rails cache. I realized that storing the computed paths in a simple hash (in RAM only) would be fast and never return stale data: The RAM cache goes away on a deploy/restart, which is when asset fingerprints could change.

Leave a Comment