Most of you will know by now, that ActiveRecord isn’t the fastest ORM on the planet, so why use it for storing session data in your database? Plan A would be to flip over to SqlSession, which bypasses the ActiveRecord method and goes straight to the database. That’s fine for most sites, but what about those really high traffic sites?
Alexey Kovyrin (for scribd.com) has written the ultimate solution, FastSessions. FastSessions uses some clever MySQL (no, it’s not agnostic) tricks to make for real speedy session storing and lookup. Now I’m no database guru, but this plugin is by one of the MySQL Performance Blog fella’s so you can be sure that it does exactly what it says on the tin.
Installation and use is easy as pie:
piston import http://rails-fast-sessions.googlecode.com/svn/trunk/ vendor/plugins/fast_sessions
Rails environment configuration:
config.action_controller.session_store = :active_record_store
Set up your migration to create the table:
./script/generate fast_session_migration AddFastSessions
Run the migration:
rake db:migrate
Little tricks like not saving the session data back to the database unless it changes, or is not empty, make for a huge saving over time.
Read more about it here: http://code.google.com/p/rails-fast-sessions/.
February 6th, 2008 at 3:18 pm
Hasn’t this problem become obsolete since the new default session mechanism is based on cookies?
Any reasons not to use cookies store in your opinion?
February 6th, 2008 at 5:27 pm
I thought that too, but some sites still need to count sessions and aggregate data from them, it’s not possible to do that with cookie based sessions.
That’s the only reason I can think of right now.
February 7th, 2008 at 4:50 pm
Actually, there is at least one more problem with cookie sessions store - size limits. Especially weird situation is with some proxy servers not allowing large cookies. Another problem is that you can’t store any sensible data in cookies because it is not encrypted there.