Print

Print


> based on the purpose of sessions and how they are used this
> wouldn't make much sense IMHO. what if the user returns in a week
> or doesn't return for a month? are you going to hold whatever it
> is you'd hold/save for the session in memory for a month?

After 24 min session is considered stale, by default.
Then, based on tricky algorythm which I am struggling to undestand, it calls
for Garbage Collector to clean up.
That's what PHP manual says about sessions. So, a guy after week(end) will
find its session expired. No problem here.

I calculated a memory load, based on average session size of 16K and 5000
concurrent sessions = ~80MB of RAM spent.
How many disk I/O saved?..



> if you're just worried about the current session... well, 
> it's possible
> i guess but if you still want that info available at a later date
> you will need to store it somewhere (ie. cookies/DB). so, again
> if sessions are client based (cookies) then it doesn't make much
> sense. if it's server side (DB) then it still doesn't make much sense.

That depends, I guess. With some file caching by apache, it sounds good
enough.
Imagine this: when server starts, or on first request, it caches site
content to RAM (not everything I believe, but maybe full index along with
part of content).
Then, session stored in RAM could use this shared memory segment for
reference, absolutely avoiding read/write to disk, but taking it to RAM
instead.
When session is expired/logged out/else, it writes ONCE  to some backend,
mysql in my case.
You see the advantage?


> just my $0.02.


Thanks! This is highly appreciated. I have no solid background in Linux but
have to run several production servers, so I have to ask to learn. :)



Best,

--
Arthur Sherman

+972-52-4878851
http://www.cpt.co.il/