On 15 Sep 2008, at 18:10, Dan Joseph wrote:
On Mon, Sep 15, 2008 at 1:06 PM, Stut <stuttle@xxxxxxxxx> wrote:
On 15 Sep 2008, at 17:14, Thodoris wrote:
Thanks I have already started working on that. I suppose that I
should run the garbage collector every now and then to see if the
session has expired. I guess this is the basic difference between
the normal sessions and database oriented. The fact that you need
to create a way to check the sessions that are expiring.
Not at all. The garbage collector is run by the session extension
according to rules set out in php.ini. It does it for you. Doesn't
matter whether it's OO or not.
-Stut
You're right I've noticed that every time you run session_start or
it's done automatically (if you set session.auto_start) then gc is
also running. In case you have defined a custom function using
session_set_save_handler then it runs this function instead of the
built-in that cleans the database of the unneeded expired sessions.
Do I get this right or there is something that I am missing?
Not quite. The rules around when the garbage collector is run are
not that simple, but in most cases you don't need to worry about
it. Implement the handler and you can rest assured that it will be
called as often as the default session GC would be called. You can
optionally take the lifetime parameter it gets passed into account
but I personally don't.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Stut, something I noticed you do is run the GC 10% of the time. I
am currently running mine with the session.gc_probability = 50.
Do you find that 10% is enough? Or was that really just for example?
It's really just an example, and it's worth noting that your custom
session handler doesn't need to call the GC explicitly at all since
the session extension will do it for you.
The history behind this code is that it was designed for a high
traffic site with a high repeat visitor ratio. The 10% of the time
was actually 0.1% on the site when it launched and it worked really
well, but it was a very specific set of circumstances. At 10% the DB
was spending most of its time cleaning up the session table. I should
also probably say that I removed a large chunk of code before posting
it (which lead to the errors Jim spotted). It was doing analysis on
the sessions before deciding which to clean up, based mainly on the
activity level of each user. But like I said, this was a very
specific set of circumstances.
A lot will depend on the performance of your database, how often
visitors come back, what your desired session lifetime is and a
number of other factors - every site is different. I've found 10% to
work well for smaller sites but it really is a balancing act that can
only be mastered through trial and error.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
