Rails Sessions Work

While working on a Rails app I came across the fact that the sessions database table was accumulating 20,000 or so entries per day. Since most of these were from search bots I figured that it would be best to find a way to avoid having so many entries. I quickly came across the fast_sessions plugin, which I had noted in the past. I tried implementing it as a replacement for SQL Session Store but it failed with MySQL connection errors. So that having failed I decided to examine what was happening with sessions in more detail.

This app is using the actsasauthenticated generator for logins and I realized that one problem was that the storelocation function was writing to the session store on almost every page load. The storelocation function is used when a user logs in redirect them to the page they were on before logging in. I decided that this large number of writes for such a small use was wasteful. So I removed all of the storelocation calls from a number of controllers and instead created a beforefilter for the login/logout functions that saves the referer. Of course, this will break if a browser does not supply the referer header but that’s of little consequence since the user can just be redirected to the front page in that unlikely instance. This strikes me as a better setup if all one is concerned about is redirects on login/logout. Now if I wanted to have some sort of live session data such as which pages have been accessed in the last hour then using the store_location function might be put to better use.

The fastsessions plugin writer(s) point out a few problems with Sql Session Store. The first is that sessions are created even if there is no session data. That seems to be incorrect as the default behavior is to not create sessions. There is an option called eagersessioncreation which is set to false by default which can change this behavior. The second criticism is that Sql Session Store uses an indexed 32 char string for the id which is slower than a numerical id. This seems to be accurate though I’m not sure that the performance difference is significant. The third is that it uses an autoincrement primary key which causes locks on InnoDB tables. However Sql Session Store recommends MyISAM instead of InnoDB due to not needing transactions thus eliminating such locks.

So I’ve lost faith in the fastsessions plugin as i seems as though they either didn’t understand or correctly implement SQL Session Store. Not to mention that my attempt at using fastsessions was riddled with errors. I will continue to use and recommend Sql Session Store or parhaps smartsessionstore which is derived from Sql Session Store.

Addendum

With regard to the changes in store_location that there are a couple of other points to make. First, one could store the location in the cookie, thus preventing the session data write and yet achieve the same effect. However my solution os using a referer still is much simpler and also avoids the case where a user has multiple browser windows open, first window A, then window B, then logs in from Window A and is redirected to the url of Window B. I think this is a much better solution unless, as I stated, one actually wants to have more real-time data about sessions.