Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Enterprise PHP sessions (open letter to Mark Woodward)



>  
> First, I'll respond to the group and maybe they'll have some input, but 
> if asked, we should go off line.

Mark, thanks for replying :)

> 
> 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?"

well, I am happy to use/tinker/play/hack with/on it, as I feel your
approach to be the right one, that being : keep the most current
sessions in RAM for really fast access, and use a DB/SQL backend to
store the data over longer periods of time. For me this strikes the
right balance between instant access, and long-term safe storage with
very little to no data-loss possibility.

<snip> .... </snip>
> 
> 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)
> 

Just gone through the metrics, as our traffic is very 'time of day'
based' :

1. Peak active sustained user load is around 2500 users. To be safe I
would architect for more than that. 7 to 9 pm is huge for us :) And you
are right, the rest of the time is trivial ... Though still causing the
NAS to be unable to even perform an 'ls' on the directory!

2. Average session data file is about 5K, largest is just under 10k

3. The average user is on the site for about 10 minutes a session, IF
they make it passed the first 20 seconds ... Then, if they haven't made
a page request in about 2 minutes we can consider that user session dead
and store the RAM session data safely in a 'storage place'.

example : 4000 sessions times 10k per session:
(4000 * 10) / 1024 = 38M total RAM required.  

> > 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.

As I said above, I believe it is the correct approach, so would be
willing to see how it played out ...

> > 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?  
:) yep, I would !

> 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.

Yeah, currently the NAS ,which is also used for storing other much
larger files, is using XFS, exactly the WRONG FS for millions of small
files :(

> > 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 ...
> >   
<snip>
> 
> 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.
> 
I read the handbook before I wrote the original email and was intrigued
enough to write to you :) I like the thought of being able to handle the
sessions like this :

User first arrives : get session from hard storage, and shove it in RAM
work in RAM until the user has been silent for a while, and when they
have been silent for a while write the session data back into the 'hard
storage', and dump from RAM. If they come back 10 minutes later, they
just get a one time slow 'first page' hit, and are back in RAM again.


So what would be the next step, download from PECL and try it ?


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







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org