In BlogPost, Rails, Ruby

Rails Cache: Local Testing

One great feature of Rails is how easy it makes caching. Recently, I was working on an application that needed to load thousands of rows of data on a single page.

ruby on rails

The app used the standard fragment caching and Russian doll caching as described in the Rails documentation.

I needed to understand if the caching tricks I used from the documentation were working locally. As it turns out, it’s easier than you think.

In the following steps, I will describe how to know if your stuff is being cached, how to clear the cache to see how long a fresh request will take, and finally a few other tips I pickedup.

Step 1 – Look at the logs to know if your stuff is being cached

Firstly, before hitting the cache, Rails will have to render everything.

Consequently, you’ll see something like the following in your logs.

Once Rails finishes caching, you’ll see something like the below:

Step 2 – Clear your Rails cache locally if you want to see how long a fresh request takes

When developing locally, you’ll want to be able to clear the cached results from time to time for debugging purposes. Steps 2-3 will help you do that.

For example, I wanted to see how long a certain request was taking on the initial non-cached page load.

You can either clear the cache from the console or clear it with a rake task.

Clear it from the console

Boot up the rails console and do:

Clear it with a rake task

Step 3 – Reset Your Cache in Chrome Dev Tools Whether Or Not You Change the JavaScript Files

Next, you should reset your browser cache. This applies whether or not you are debugging JavaScript.

In order to do this in the Google Chrome browser, open developer tools.

After doing this, mouse click and hold on the refresh button.

Finally, select the “Empty Cache and Hard Reload” option. As explained in this post, this forces the browser to re-download everything.

If you are debugging JavaScript, I’ve run into the experience of thinking a JavaScript file I had just changed was being used when in fact a cached version of it was being used. Thus, I was not using the new JavaScript file. This is why I emphasize doing a hard reload.

Step 4 – Use production data (or a large size dataset) if you can

The effects of caching are easier to observe with a large dataset. In my case, I was reading thousands of rows. But if you don’t have a large dataset, you can use the logs.

A Bit About Memcached

Memcached is pretty easy to configure for Heroku.

In config/environments/production.rb:

Step 5 – A word about Rails 5 caching

If you created a Rails 5 application, you now have a new handy command to toggle caching on and off.

The rails dev:cache command enables caching in development mode. You can re-issue this command to disable caching in development mode.

From the issue on GitHub, here is how it works:

If a caching-dev file exists, then you turn on caching in development mode. The upshot is you no longer have to restart the server manually to turn caching on and off. Apparently, this feature is “not supported by unicorn, thin, and webrick” according to the blog post from BigBinary.

Summary

Testing to see if your cache is working locally comes down to a few basic steps.

Firstly, read the documentation and look at your local development log.

Finally, clear the Rails cache and hard reset the cache in Chrome Dev tools.

Recent Posts
learning programming language outside your comfort zoneside project