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