In some large client sites, we see many queries from the session handling code in drupal, mostly from the sess_write() function in includs/session.inc.
Examples of creating a new session:
INSERT INTO sessions (sid, uid, cache, hostname, session, timestamp) VALUES ('744e888350d5c759f067d58380f6874e', 0, 0, '10.1.1.1', '', 1243567441)
And examples for updating a session:
UPDATE sessions SET uid = 0, cache = 0, hostname = '10.1.1.2', session = '', timestamp = 1243567406 WHERE sid = '74db42a7f35d1d54fc6b274ce840736e'
UPDATE sessions SET uid = 0, cache = 0, hostname = '10.1.1.3', 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 session.inc 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 Drupal.org, please let me know.
Update: May 29, 2009: The module is now on Drupal.org at No Anonymous Sessions. A release should appear there in a day.
Attachment | Size |
---|---|
no_anon.tar_.gz | 3.54 KB |
Comments
Visitor (not verified)
Project Page
Fri, 2009/05/29 - 01:25It'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?
Visitor (not verified)
Vote from me
Fri, 2009/05/29 - 01:49This module would certainly be useful to me. So yes, a project page would be handy.
Visitor (not verified)
Make it "legit"
Fri, 2009/05/29 - 02:38If it is useful to a lot of users it would be adequate to release it via Drupal.org.
Visitor (not verified)
Do you not use "throttle" ?
Fri, 2009/05/29 - 03:27Hi, 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.
M.
Khalid
No
Fri, 2009/05/29 - 19:14No, 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.
Visitor (not verified)
Need Project!
Fri, 2009/05/29 - 03:56This module has to be in drupal CVS!!!
Please contrib it as project to drupal.org (Can help with maintaining)
Visitor (not verified)
I'll give a try
Fri, 2009/05/29 - 09:31Hi, nice module. I'll give a try in a site I have. This site isn't so heavy but performance improvements are always welcome.
Thankyou
Visitor (not verified)
Wow, pretty good performance
Fri, 2009/05/29 - 11:59Wow, pretty good performance gains! Thanks for wrapping it up in a module, it's nice to see other people run with one's work.
Visitor (not verified)
Memcache
Fri, 2009/05/29 - 20:12Hi Khalid,
Have you compared this with using memcache for sessions?
-N
Khalid
No
Fri, 2009/05/29 - 20:27No. 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:
So, 70MB, not much. Can be stored for sure.
Pages