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


Fri, 2009/05/29 - 01:25

It'd be nice to have it as a project, for the simple fact that there may be more exposure, and it would feel more 'legit.'

Would this help a site getting maybe 10-15,000 anonymous sessions a day?

Fri, 2009/05/29 - 02:38

If it is useful to a lot of users it would be adequate to release it via

Fri, 2009/05/29 - 03:27

Hi, in the README.txt file i read that the Throttle module will not work anymore when this "no_anon" module is enabled.
So: do you not use this module (throttle) in your client's site ?

Tnx for all.


Fri, 2009/05/29 - 19:14

No, I don't use throttle on most client sites.

Short version: it reduces functionality for sites under load.

Long version: We have seen some side effects, for example, blocks in the content area were throttled, then high traffic caused pages to be displayed without some crucial blocks, and they ended up in the cache, and the pages were messed up.

Also, we did not need to do that, because other techniques provide the scalability we need.

Fri, 2009/05/29 - 20:27

No. From reading and watching the issue queue, I get the feeling that memcache for session is not very mature or production worthy yet.

By the way, the number of rows in the sessions table for that client is now a mere 1,117! A far cry from what it was before.

Here is a comparable client that does not yet need the above module.

Total sessions: 1,104,499
Authenticated: 6,319
Anonymous: 1,098,184

My initial concern about storing all that in memcache was unfounded:

SELECT SUM(LENGTH(CONCAT(uid, sid, hostname, timestamp, cache, session))) AS size FROM sessions;


So, 70MB, not much. Can be stored for sure.


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