In some large client sites, we see many queries from the session handling code in drupal, mostly from the sess_write() function in includs/

Examples of creating a new session:

INSERT INTO sessions (sid, uid, cache, hostname, session, timestamp) VALUES ('744e888350d5c759f067d58380f6874e', 0, 0, '', '', 1243567441)

And examples for updating a session:

UPDATE sessions SET uid = 0, cache = 0, hostname = '', session = '', timestamp = 1243567406 WHERE sid = '74db42a7f35d1d54fc6b274ce840736e'
UPDATE sessions SET uid = 0, cache = 0, hostname = '', session = '', timestamp = 1243567429 WHERE sid = 'cf9c94337f2cabc4e7aec5afcfbf44d2'

Note the uid = 0 in all the above cases.

Because such operations are performed way to frequently on a busy site, there can be contention on the sessions table, even after converting that table to InnoDB.

Drupal 7.x now has in core the ability to support disabling of anonymous user sessions. This is good news for sure, but it does not exist on Drupal 6.x, so not immediately usable for live sites. Even though a port to 6.x is maintained by Four Kitchens, the the patch involved is too large and somewhat invasive. That makes it require constant updating as new point releases come out.

Some when Marco Carbone in a recent article, described a simpler approach of how to get rid of cookies for anonymous users, a light bulb lit up.

Although the motivation in Marco's case was user privacy for anonymous users (not storing any cookies on their browser), it was immediately obvious to us that this is an opportunity for performance optimization.

So, we ended up folding Marco's modifications into a module, which we called no_anon. Since this module contains the alternative modified file, it requires no patching at all, and hence it is usable by mere mortals.

The README.txt file included describes how to configure it, as well as some limitations.

As usual, without actually measuring, there can be no real quantification of any action you take.

On a large site that gets over 700,000 page views a day on a regular day, the effect on the number of slow queries MySQL had to handle is immediately visible from the 24th onwards:

And even memory usage seems to be more regular than before, looking at the green portion (application usage):

You can download the module from the following link. If enough people think it is worth having its own project on, please let me know.

Update: May 29, 2009: The module is now on at No Anonymous Sessions. A release should appear there in a day.

Binary Data no_anon.tar_.gz3.54 KB



Is your Drupal or Backdrop CMS site slow?
Is it suffering from server resources shortages?
Is it experiencing outages?
Contact us for Drupal or Backdrop CMS Performance Optimization and Tuning Consulting