Sep 07

In Rails Session Management Howto, Part II, I discussed using the PStore approach for session data storage. The p_store based sessions utilize the local OS file system. In this post, I will present memory based storage approaches for session management in Rails.

The first approach is to use memory_store based sessions. With MemoryStore the session objects are kept in the applications memory with no serialization necessary. While this approach will make it extremely fast for an application to move objects in and out of a session store, it is not a reliable method because the memory where the session data is stored is only available to a single server. Thus it also does not scale well since it requires sticky sessions.

The second approach utilizes memcached, a high-performance, distributed memory object caching system. Memcached is used by some of the largest websites in the world and is certainly a very solid approach for session storage. The mem_cache_store based sessions meet the criteria of scalability (just add more servers) but this approach is still not reliable. Because it is a cache you still need to use some form of reliable storage for your session data, such as a database store. But if you need super fast reads of the session data across multiple servers, then memcached is really the best performing approach. You can find some discussion of that approach discussed in Sessions. Several memcached Ruby clients are available including RMemCache.

For more discussion of these memory based sessions and their configuration, I recommend you pickup a copy of the excellent reference Agile Web Development with Rails.

Are you using a memory based session approach? How do you scale and protect against server crashes (or maintenance)?

3 Responses to “Rails Session Management Howto, Part III”

  1. [...] Rails Session Management Howto, Part III Sep 13 [...]

  2. Norm Scherer says:

    As my application is very limited in the number of concurrent users (probably 1 to 2 and hard to imagine more than 3) I find memory store is very suitable.

    In AWDR memory store is dismissed with only the comment that it is simplistic but this ignores the fact that many (most?) applications will never get large and some are aimed at a very small audience. For these memory store is very attractive because of its simplicity and performance.

    Memory store is very easy in maintenance. When the server is restarted or the host is rebooted it all goes away. In my case most servers are on windows systems so they will reboot fairly often.


  3. dcpatton says:


    It could certainly work in your situation. I have not run into any applications like that. Have any other readers tried it?

Leave a Reply

preload preload preload