Rails%203%20In%20Action

462 CHAPTER 16 Basic performance enhancements
added to the output, rather than re-processed. All in all, this solution is more elegant
than caches_action. Another commit is in order!
git add .
git commit -m "Implement tidier caching for the tickets
➥list on the projects page"
That covers all the major methods for basic caching in controllers and views. You’ve
seen ways to cache entire pages and parts of pages as cached files on the filesystem. In
a Rails application there may be a lot of reading and writing to the filesystem, which
can cause degradation of performance, so storing these files on the filesystem may not
be the best idea. A speedier way of doing this would be to store these files in memory
by switching the cache store that Rails uses. You can do this by putting this line in one
of your config/environments files, probably production.rb:
config.action_controller.cache_store = :memory_store
Rather than storing the fragments on the file system, Rails will now store them in memory
along with the code for the application. The retrieval time is faster here, but comes
at the cost losing the cache if the server was ever stopped. If you want something more
persistent, you may choose to use either Memcached (http://memcached.org) or
Redis (http://redis.io). We won’t go into these in this chapter, as they exceed the
boundaries of what would be considered basic performance enhancements.
In this section you’ve learned how to use fragment caching to store parts of the
view that may take a long time to process. This type of caching would store these fragments
in the tmp/cache directory; they can be retrieved later on.
16.4 Background workers
There are other situations where requests can be slow for your application too. One of
these cases would be if a ticket had a large number of watchers, and a comment was
posted to that ticket. The reason for this slowdown would be because Rails would have
to iterate through all the watchers and send out the update notification email to each
of them individually, using the feature that you developed in chapter 12.
Rather than having a user make the request to create a comment in the application,
having the server process the email notifications, and then send a response back,
you can take the long-running task of sending these emails and move it into a job that
runs in a background.
This will work by having your CommentObserver add the task of sending these
emails to a job queue that runs in the background. You’ll then have a background process
separate from your application that will run these jobs as it receives them. This
way, the hard work is done behind the scenes and the user receives the request back
almost as if nothing of consequence happened.
To make this happen, you’ll use a gem called delayed_job. This gem will allow you
to create a table in your database where the jobs that the background worker needs to
work off will be stored. The gem will also provide you with the ability to start a worker
process. To add this to your application you’ll put this line in your Gemfile: