Arthur Sherman wrote:
>> 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?..
You have 5000 people connected to your site at any given point? I should
hope you have a decent round robin system setup between at least another
server... but I digress.
If you are using mod_php, then apache will actually cache the session
data in memory so you really won't be saving that much disk I/O. Since
PHP 4.2.3, mtime is used for expiring sessions so if your session is
constantly changing with a ping type msg in an AJAXy type script. You're
wasting a lot more bandwidth and disk I/O because of your poor site
design then a file system choice for /tmp.
As far as the algorithm goes for removing sessions, the default is
1/100... so every 1 out of 100 times that session_start() is called, it
will actually delete expired sessions.
>> 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. :)
> Arthur Sherman