Enterprise PHP sessions (open letter to Mark Woodward)

[markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org (Mark Woodward)]

ref wrote:
> Hi Mark,
>
> I have been a member of BLU for almost two years now, and a small time
> contributor (ref<tbs-Gb/NUjX2UK8 at public.gmane.org> is my account email), and recognized your
> name when I found Mcache. I hope you dont mind if I ask you some
> questions about it as I see you wrote it and I need a really good PHP
> session management system. I am also opening this up to the list as it
> may help the community ... If it needs to go off-list that is cool too.
>   
First, I'll respond to the group and maybe they'll have some input, but 
if asked, we should go off line.

A "really good" session system?

Well, I have a number of sites that use MCache including my own. 
Personally I wish I had some real pressing need and/or perspective cash 
flow from it as I think it is the *right* solution for PHP sessions and 
should be the default handler, even over the file based session system. 
I have been using it for about 8 years in various forms, the initial 
project was msession. I can't justify any work on it at this point 
without some sort of way to monetize it. I haven't made a dime from it 
nor do I have any contributors. The great philosophical question of our 
age: "If an open source project gets written and no body uses it, does 
it even exist?"
> I have a web farm that serves ~10 million page views a month (over
> mobile), across 5 web servers. I currently store all session data on an
> NFS mounted NAS. The NAS is on an independent network sub domain so as
> not to affect web traffic.
> We store peoples voluntarily given location in sessions, and a fair
> amount of other data that will change as the user goes through their
> experience with our site. Due to 'biz logic' requirements, the sessions
> must remain live for a total of 10 years, although if they remain
> untouched for 6 months, they can die.
>   
Depending on the data size of a session, I have managed a sustained 3000 
session dialogs (get, modify, update) per second on a SMP machine a few 
years ago. With faster networks and CPUs, that's probably slow.
The system clears out sessions from RAM and flushes them to the disk in 
a configurable hashed directory structure that can accommodate a large 
number of files. There are two settings on sessions, when they are 
"flushed" and when they "expire." A session is flushed out of memory 
when it hasn't been used within a period of time. A session is "expired" 
(deleted) when it hasn't been used within a different period of time. On 
a periodic basis you would run a utility, mfsvacuum, that cleans out the 
directory of dead sessions. If you use a database, you'd have to write a 
delete from query.

The real performance issue breaks down to these data points:
(1) How many active users are on the site at any one time? (peak)
(2) How large is the session data? (max)
(3) How long does a user session typically stay active? (average)

This will give us an idea of how much RAM will be used by mcache and how 
many sessions it will have to manage at any one point. The number of 
active sessions isn't a big deal except they have to be scanned every 
few minutes for garbage collection.
> We are now experiencing bottlenecking with the NAS and are looking for
> other solutions. While googling I found your Mcache and was wondering
> how far you had pushed it and if it could be a good solution for us ?
>   
It is not an off the shelf solution for anyone right now, but in theory 
it could fit your needs.
> We are currently adding somewhere in the region of 2 million session
> files a month, though 90% of that is 'fly by' and they will never
> revisit. The other 10% will typically view 10 pages per user session.
> Can Mcache/php sesison management handle that kind of traffic, or would
> you steer me to other solutions ?
>   
The 2 million sessions a month (times 10 page views) is not a big deal 
-- dare I say trivial?  Given your usage, that's about 10 sessions 
dialogs per second on average? 20 to 100 per second during peak loads? 
The hashed directory structure may work with a lot of small files. Too 
bad ReiserFS is dead as that is the perfect file system for that sort of 
thing.
> I not in favor of using a straight up DB solution if I can help it as
> mySQL tends to suck at updates and we do a lot of session interaction
> during a users view session. I am no that familiar with postgreSQL so
> cannot comment on its ability either ...
>   

Well the whole reason why Msession/MCache was written in the first place 
was that databases really suck at session handling. Now the important 
thing to understand about mcache is that it is NOT a guaranteed storage 
system like a database. There is no transactional integrity nor 
guaranteed commit to disk. It is a cache and if it crashes before it 
saves to disk, you lose data. Since you are using NFS, this is probably 
not an issue.

MCache can be configured to save to disk after each update, but that is 
much slower. It is probably still faster than your needs.  I suggest you 
look at the handbook: http://www.mohawksoft.org/?q=node/8 and let me 
know what your think.

>  thanks for your time,
>
> Richard
>
>
>
>