LISTSERV mailing list manager LISTSERV 16.0

Help for LINUX-L Archives


LINUX-L Archives

LINUX-L Archives


LINUX-L@LISTS.UFL.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

LINUX-L Home

LINUX-L Home

LINUX-L  2007

LINUX-L 2007

Subject:

Re: storing php sessions in memory

From:

Doug Goldstein <[log in to unmask]>

Reply-To:

Platform Independent Linux List! <[log in to unmask]>

Date:

Tue, 13 Mar 2007 20:07:56 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (75 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
1997

ATOM RSS1 RSS2



LISTS.UFL.EDU

CataList Email List Search Powered by the LISTSERV Email List Manager