This is precisely why I didn't want to use sessions for managing authentication state...

I started to notice my webserver getting really slloooooooow. Sometimes it would time out completely (I've got it setup with 60 seconds max execution time per page). How could this be? I designed the pages for maximum SQL performance. Why is it taking so long to get the database open?

Then I looked closer at the timeout message. Timeout on line 3. Line 3 hasn't even touched a database yet. It belongs to a function called 'session_open()'. Gak.

By default, PHP stores its session data in the /tmp directory. One file per session. I bop over to the session directory and do an 'ls'. It takes about fifteen minutes to list all the session files. I can't even easily count them because the shell chokes on the wildcard expansion. On a Unix filesystem, anything more than 1000 files in a single directory is bad news. It's gotten better over the years, but if you're talking about say 20,000 or 100,000 files, the operating system can't deal with it, plain and simple.

I shortened the session expiration time and made a mental note that this is going to have to be fixed. A couple of days later, timeouts again. This is right after google did a deep scan of my site. OK, something's got to give. So I look at alternatives. PHP can also use 'memory mapped' sessions. No files. OK. That sound like a winner. This is a small site, I shouldn't need that much memory. I recompile php with the necessary configuration and run it. Great. At least it works...

Then I make a mental note that I really need to figure out a way to measure the memory use because running out of memory is not a good thing. And I let it run. I figure about 100 bytes per session. The problem is that I don't know how much memory the mapper reserves for itself and what its built-in limits are. Might be 100 megabytes (roughly a million sessions). Might be a megabyte (roughly 10,000 sessions). I've got about 50 megs free. If it's well written, I should be able to manage a half a million sessions. But I didn't take the time to review the source and find the answers. I just wanted to get it working - pronto. 

Big mistake. I come back the next day and I've got a blank screen. Boy this memory manager doesn't degrade gracefully. When the 'files' driver filled up, the program just hung up for a while. Using the memory driver, the page actually comes up, but there's nothing on it. The dreaded White Screen of Death. At least I now know it's reserving something considerably less than a megabyte - and not asking for more.

OK - now it's done gone and made me mad. Time to write an SQL session driver. Yeah, I know how to do it. I didn't think I'd need it, but it turns out I do. Took about twenty minutes to get it running.

 The lesson here is that you can't use the built-in PHP session drivers even on a small site these days with all the crawlers running around. A few years back you might get a few hundred hits a day if you were lucky. Now it's in the  thousands and tens of thousands.  If you've got a weblog that pings one of the pinging services, you're guaranteed another 500-1000 hits every time you change a page. Since these are all coming from robots and aren't storing cookies, each page is going to get a new session.

So all you developers out there, if you want to use PHP sessions - hack, beg, borrow, or steal a database session driver and figure out how to use it. 

Attached is a little driver I found on the web a couple years back. It's a good starting point if you've never dealt with session drivers before.