A new module that helps with busy sites has been released.
This is the session expire module.
Problem
On busy sites, the number of rows in Drupal's sessions table can be really high. We saw sites with 1.7 million rows in it!
Drupal's core relies on PHP garbage collection to do this cleanup, but the options are sometimes not set correctly in php.ini, and vary from distro to distro, so the cleanup may not kick in at all. Moreover, the cleanup can be triggered by normal page views.
Solution
This module makes session cleanup more predictable and consistent, and also more configurable. By using Drupal's hook_cron, we avoid the uncertainity of PHP's garbage collection and its susceptibility to option settings.
Options are provided for : how often should the cleanup be attempted, the age of the sessions to be expired, and whether to expire only anonymous sessions or both anonymous and authenticated sessions.
A watchdog message notice is logged with the number of rows deleted from the sessions table.
Download
You can download the module from the session expire module project page on Drupal.org.
Sponsors
Screenshot
This screenshot shows the options available in the module:
Comments
Visitor (not verified)
Thank you!
Mon, 2007/11/05 - 20:05Thank you for the writeup and sharing this module! We had been running into the same problem (450,000 sessions every 24 hours) and were doing a scheduled cleanup with cron, but it's much better being integrated with Drupal as such :)
Would it make sense to add a feature to the module where it prunes the sessions once they get over a certain number? That way if you get a ton of extra traffic from Digg, etc. within a short amount of time, the sessions can be pruned before the performance starts to suffer. Or is there a reason you wouldn't take that approach?
Chris
Khalid
Actuall, tried to push it in core
Mon, 2007/11/05 - 22:35I actually tried to push this functionality into Drupal core, as per #72856. It was not well received, so I created this module.
Perhaps someone will see the light, and this can be pushed into Drupal 6, replacing the PHP garbage collection stuff. If others think this is a good idea, I can create a patch for this, removing the stuff in session.inc and .htaccess too.
Adding an option for number of rows is more involved. We can know how many are there in the table using a COUNT(*), but how do prune in a way that would say "delete X rows"?
--
2bits -- Drupal and Backdrop CMS consulting
Visitor (not verified)
DELETE and locking sessions table
Tue, 2008/12/16 - 02:54Chris, there's a consideration with that approach: the DELETE locks the sessions table, which is exactly what you DON'T want when you've been Dugg.
When we first installed this module, the next cron run stopped the site dead. The delete was slow (because it was large) and this meant that each user viewing a page had to wait for the delete to complete before Drupal could load their session.
There is an alternative fix, which involves changing your settings.php to re-enable PHP's session gc(), but you do NOT want to take this approach if you still have an overloaded sessions table. That too will stop the site dead.
This module will keep the pounds off, but it doesn't make for a gentle diet. On any busy site, I'd recommend making sure your sessions table is clean before installing this module
Thanks to https://2bits.com for providing it - great module!
Khalid
First time only
Tue, 2008/12/16 - 10:49What you said about the drawbacks of this module is true only on the first time it runs via cron, and only if you have a large sessions table that has not been pruned for a while.
After that, it is not heavy at all.
So, the best way is to run it the first time during off hours or on a weekend and watch MySQL's processlist until it finishes. Should not be an issue after that one time.