Caching in Ruby on Rails
As I mentioned, I’ll probably be doing quite a few more Ruby on Rails posts here since I have been wrapping up a new application that we have built. Part of the final development stages has been to go through and determine a caching strategy, which is interesting. That being said, I thought I would put up a quick post to kick of a series of posts on caching in Rails.
First, why cache anything? Or more importantly, what happens when you cache content in Rails?
To start with, caching means to store information that is repeatedly accessed so that (typically) a database does not need to be queried over and over for the same information. Since querying a database requires quite a bit of server resources compared to simply going to the disk, cached content in a static HTML document can be served something like 100x more efficiently than content that requires a database to be queried. Simply put, why make your web server work harder than it needs to? Better yet, when traffic rises and performance problems occur, in my experience they pop up first around database-query related issues. Scalability’s first ugly trick is to make your web server scream for mercy as it waits for information from the database.
So when you cache information in Ruby on Rails, it can be done in a couple of different ways. I will be outlining Page Caching and Fragment Caching in the next few posts. Page caching happens when you tell Rails to cache an entire page of a website. Let’s say that you are caching your home page, which has a list of articles on it. The first time the page is cached, Rails will do what it normally does and run through the Ruby scripts to generate the page. However, it will also generate a static HTML file that goes into “public/” folder in your rails app. Assuming that the URL for the home page is “/”, and that there is not already an “index.html” file in your public folder, one will be generated. The next time that you try and access that cached page, the homepage, Rails will not even get involved. There will be no database queries, rather the cached page will be served directly from the “public” folder as a static HTML page. And that is page caching.
Fragment caching is a bit more involved, and less efficient since it still requires Rails to get involved. Let’s say that the same home page from above has a list of articles on it, but then also other information that needs to be updated each time a user visits the page. In that case, we would want to cache only the fragment of the page that has our articles. In this version of caching, the database is queried the first time to generate the cache, and then a file is written into the “tmp/caches” directory of your Rails app. The next time the page is visited, Rails will works it’s magic, but rather than querying the database for our list of articles, it will simply draw of the cache file instead. This takes advantage of the performance gains that go with accessing the disk rather than the database. Fragment caching is simple to learn but can be very complicated to apply.
As you may have guessed, caching is rather easy. Real easy. But it’s not so much in creating caches that is tricky, but rather when to expire them. If left as we outlined above, the article list on our site will never update since the caches are not being expired. Going through and determining which caches need to be expired and when can be quite complicated. Once I get through caching methods, I’ll put up a post about using “cache sweepers”, which is a convenient way to set up a Rails application to expire caches.
Again, the next post will start into how to do Page Caching. From there I will probably put up a few posts about fragment caching, and then there will be at least two posts about sweepers and cache expiring. Since I have been doing a bunch of Rails development in the last few months, I have been running into challenges that I imagine other developers are running into, so I will try and post about them.
0 Comments
Connect with us