Using MongoDB to replace the sessions table?

tracy — Sun, 02/21/2010 - 14:48

Maintaining session information has long been the bane of the web developer. Many web platforms put that information into a MySQL table, something that can work decently well for small to medium sites. The problem is that as the site's popularity grows, so do the number of database entries and hits. Sites that aren't as good about purging the sessions table of stale entries are going to see increasingly slower lookup times at a time when the number of hits are increasing.

One common solution is to turn off session logging of anonymous users. A module exists for Drupal users which does just that, No Anonymous Sessions. This can help reduce server load and database contention issues, particularly on busy sites. However, this also can have some effects that are less than desirable. For instance, if you are a stats junkie, it can be a lot harder to figure out the traffic patterns of different anonymous users. In addition, some sites provide use user functionality to anonymous users, such as the ability to vote, bookmark favorites, etc. These sites often do this as a way to allow the user to "try before they buy," allowing the user to determine how useful they find the site before requiring registration. Likewise, if you run your own targeted advertising, not having anonymous sessions can make it harder to determine if you've shown a particular ad to a user, etc.

Given the drawbacks to completely turning off anonymous sessions, some sites have turned to putting them into some other sort of cache instead, commonly something along the lines of APC for single-server setups or memcached for multi-server setups. Since the information resides in memory, these can be much faster to look up compared to MySQL. In addition, they are memory-constrained areas where older data is periodically removed from the cache. This means we don't have to worry about creating cron scripts to clean out the database and our data set can get only so large. Granted, it also means that if there is an issue with memcached or if we have to restart our web server, all the current session data will be lost and, during particularly busy times, active user sessions might be lost if there is just too much session data being saved at once.

All of this makes me wonder if MongoDB might be a good replacement for these methods of saving session data, particularly using the capped collections option. There are a couple of caveats that are important to note before going down this path:

You can not explicitly delete an object from a capped collection.

You can modify an object in a capped collection, but you can not increase its size. However, you can pad the object to make it take the max amount of space required.

I'm creating a simplified script to test how these different options compare to one another. The sessions table is based off of the sessions table used in Drupal 6 since I would most likely use this to help improve the speed of my personal websites. The code will prefill the sessions table with some sessions so we can emulate returning visitors. I'm not going to worry about putting information into the cache key for now so I don't have to worry about solving the issue of changing the object size. Likewise, I'm not going to worry about the instances of a user explicitly logging out or of session expiration.

I ran this code on an Amazon EC2 instance, m1.large, running Ubuntu 8.04 (hardy). That instance type is a 64-bit platform with 7.5 GB of memory, 4 EC2 Compute Units, and 850 GB of local instance storage. My test code had the following results:

We spent 675 seconds on pre-caching 60000 sessions.
We spent 3060 seconds simulating 10000 hits.
We had a cached session hit percentage of 40.36%.
We spent 3062 seconds simulating 10000 hits.
We had a cached session hit percentage of 40.31%.
We spent 3064 seconds simulating 10000 hits.
We had a cached session hit percentage of 39.94%.
We spent 3065 seconds simulating 10000 hits.
We had a cached session hit percentage of 40.35%.
We spent 3065 seconds simulating 10000 hits.
We had a cached session hit percentage of 39.78%.
We spent 3066 seconds simulating 10000 hits.
We had a cached session hit percentage of 40.37%.
We spent 3067 seconds simulating 10000 hits.
We had a cached session hit percentage of 39.75%.
We spent 3067 seconds simulating 10000 hits.
We had a cached session hit percentage of 40.14%.
We spent 3068 seconds simulating 10000 hits.
We had a cached session hit percentage of 40.08%.
We spent 3069 seconds simulating 10000 hits.
We had a cached session hit percentage of 39.9%.

In future articles, I'll run similar code to populate a MySQL database and a memcached instance so we can draw comparisons.