In my previous companies we used to serve sessions from mysql via a custom made session handlers and to be honest we never really had any problems with it. I cant actually remember the traffics and concurrency rates but it was not that low. Currently the solution im working with uses memcached for sessions storage, the default build in session handler. I am a bit worried about the way it works with memcached.

Problems with memcached sessions in PHP

First of all memcached is a cache storge engine and it was not designed with sessions in mind. The way php extension uses memcache causes a few more problems in the long run. Here are my concerns:

• Memcached is not persistent - if anything happens to your server or memcache crashes you will loose all sessions. That might be a serious problem if you have people with items in their shopping carts or they are in the middle of some transaction!
• Memcached has limited storage - people do not realize that memcache has fixed amount of storage limited by RAM. Once you run out of RAM you will begin to evict oldest items. This exposes your site to a serious DOS attack threat. Anyone with botnet or at least a few machines should be able to create enough sessions (using ab) to fill out the memory of any servers pool. The bigger the session the bigger the problem.
• Memcached limits entry size to 1MB - if your session is over 1MB you are doing something wrong any way. But still .... i would prefer to have a few hours of lagging site than few hours of no-login if something goes wrong with new code release.
• PHP extension handling memcached sessions does not give you control over faults nor timeouts. Its fine if you have small setups locally but it becomes a problem if you are not able to monitor nor act upon connections being blocked or slow etc. Custom, hand made, session handler would be a solution here as you could control how connections are handled etc.
• PHP extension does not tell you if session was not found or did it fail to connect to the server (same as above)

Benefits of memcached sessions

• The good thing about memcached is that its really fast! if you run it locally you will be getting round trip times below 1ms for get/set operations. Because the hash map approach and fixed memory limitations as well as only in memory storage you have guarantee there will be no delays. The only delays you can get is the overload on the server of too many connections trying to get data at the same time. In mysql you can always get to the point that your db starts swapping parts of the data set to the drive, it also has to sync changes to the disk (even that it will heappen in bulks its still increasing load on the server).
• Another good thing is that memcache should scale up better than mysql, there are reports from serious companies who have tens of thousands of concurrent connections, which might be too much for mysql instance ;- )
• You dont have to care about collection of old sessions. You dont have to optimize tables nor rebuild indexes etc. Your sessions are bound to stay in memory. In mysql you would need another cron job removing old sessions. You would also need a check forcing old session to be removed or disabled if its accessed after expiration time but before cleanup cron execution. In memcached you dont have to do that.
• Both solutions would need some update on each click to make sure expiration does get updated. In memcache its lightning fast and there is no overhead related to update. In mysql you will have more and more garbage rows as updates will create new rows leaving old stuff in the data file till table is optimized.

Verdict

For huge sets of sessions you will need mysql or partitioned memcached solution with hand made sessions handler. I would not use the default one for anything more serious and big.

For setups where you need speed and dont care if users get disconnected .... use memcached.

For regular site with medium traffic and relatively important sessions (medium shops and apps) i think i would recommend myslq. It just seems like a bit safer way to go. You will need custom session handler and cleanup cron but you might feel a bit safer.

Please let me know if you have any interesting input about that issue, i am very interested in your experiences!