Section 9.2. Session Stores

9.2. Session Stores

As a general rule, adding Ajax to an application will cause the average number of requests to increase, but the average response size to decrease. That's because the Ajax style of development encourages lots of requests, each with relatively small impact on the server and response size. The consequence of this trend is that it's increasingly important to minimize per-request overhead, like session management. In this section, we'll look at just thatthe various ways that Rails can be configured to store session information

Once you've switched to the production environment, the next piece of low-hanging fruit to reach for is sessions. The default method of storing Rails' sessions is on the file system. While that approach requires essentially no configuration, it suffers from being slow, especially as the number of sessions grow. Using the default session storage is especially problematic on shared hosts, because Rails will expect to use the same temp directory for every user.

There are a few other options for storing sessions that will help your application perform faster: ActiveRecordStore, SQLSessionStore, and memcached; however, sometimes performance might be better served by turning sessions off for certain actions.

9.2.1. ActiveRecordStore

ActiveRecordStore uses ActiveRecord (and hence the database) to store sessions, which has the benefit of being very easy to configure and plenty fast for most applications. To get it going, add the following to config/environment.rb:

config.action_controller.session_store = :active_record_store

Then, create a sessions table in your database. Rails provides a script to do it for you; from the command line in your project root, run:

rake db:sessions:create

If you need to create the table in your production database as well, use:

RAILS_ENV=production rake db:sessions:create

9.2.2. SQLSessionStore

While ActiveRecordStore is easy to configure and generally preferable to the default file-based sessions, it's not the fastest option. Accessing the database through ActiveRecord imposes overhead, but session storage doesn't really need all ActiveRecord's ORM niceties. To speed things up, you can eliminate the overhead and go straight to the database, with SQLSessionStore. The catch is that it works with only MySQL. But if that's what you're using, it's a simple transition from ActiveRecordStore. The source and installation instructions are available from the Rails Express blog: http://railsexpress.de/blog/articles/2005/12/19/roll-your-own-sql-session-store.

9.2.3. memcached

The third optimization for session storage is memcached, a popular library for distributed caching of data in system memory. The memcached system is used for very high-load Rails applications with great success. Because sessions are stored in memory as opposed to disk storage, access is very fast. Because it's separate from the database and its associated overhead, database load is reduced significantly. And because the system is distributed, multiple application servers can share one memcached pool, making better use of resources.

The downside to using memcached for session storage is that it's more difficult than the previous options to configure. For most applications, it will make sense to wait on memcached until your application has outgrown one application server. For information on installing and setting up memcached for session storage, see the Rails Express blog: http://railsexpress.de/blog/articles/2006/01/24/using-memcached-for-ruby-on-rails-session-storage.

9.2.4. Turning Sessions Off

While most applications probably need sessions, not every action does. Because there is some overhead involved in creating sessions, turning them off entirely can provide a big performance boost, when possible. The most common instance is with web feeds. Most feed readers don't use cookies, so every time the feed is requested, Rails would create a new session needlessly.

To turn off sessions for an entire controller, use the sessions class method:

Class StaticController < ApplicationController   session :off   #... end

The method can also take the :except and :only options, to exclude or specify certain actions. For example:

session :off, :only => :feed session :off, :except => :login

The :if option can be used to evaluate an arbitrary condition by passing it a Proc object (see http://corelib.rubyonrails.com/classes/Proc.html). For example:

session :off, :if => Proc.new { |req| req.params[:format]== "xml" }