Session Garbage Collection Frequency???

[Laxidasical]

Does anyone know how often PHP does garbage collection on sessions, or if there is even a set time interval? I know that you can set sessions to have a max time before they expire in php.ini, but how often will PHP actually go through and delete the expired sessions on it's own?

 

I ask because I recently started storing sessions in a database. I noticed that expired sessions that haven't been explicitly deleted (ie. exiting my site without clicking "Logout" which would delete the session) sit in the database for quite some time. I've only made the session to database change on a development machine, so there is almost no traffic. This leads me to believe it's done after so many calls to session_start(). Is this true?

 

If so, I'm thinking of calling the session garbage collection function at the end of the session close function in session_set_save_handler(). I'd like to avoid this extra query every time a session closes though.

 

???

[clown[NOR]]

i dont think that when the session itself is trashed that it will remove it from your database. it only cleans up the sessions nothing else. or am I way off here?

[PFMaBiSmAd]

Session garbage collection is fairly well explained in the manual -  http://www.php.net/manual/en/ref.session.php

 

Short version (confirmed by reading the source code) - Every session_start() a random decimal number in the range 0-1 is generated and multiplied by session.gc_divisor. The resulting number is compared with session.gc_probability. If it is less than or equal to session.gc_probability, the garbage collection code is called where any session data files/records that are older than session.gc_maxlifetime are deleted.

 

You can force garbage collection to run every session_start() by setting session.gc_divisor and session.gc_probability to the same values (1 for example.)

 

The only purpose of garbage collection (some people mistakenly use it to end sessions) is to clean up old data files/records. It is executed randomly so you don't end up executing it unnecessarily on a busy site. You should not really worry or care about the existence of old session data files/records.

[Laxidasical]

So lets say a site sits idle for 3 days with no visitors and there were sessions left in the table undeleted.  They would stay there until traffic started hitting the site again, correct?

 

I'm not going to put any more effort into it, this thread is more FMI than application...

[cooldude832]

you shouldn't have to alter the default configs on 90% of the web hosting php configs for session cleaning.  I don't even know why one would need to store sessions in a Database your sorta trying to paddle up river in that case because sessions for the most part are used to give a single "session" of user activity a direct connection to specific portions of the databases to provided them with enriched content.  Your trying to make a session into something more along the lines of a cookie I believe.

[Laxidasical]

you shouldn't have to alter the default configs on 90% of the web hosting php configs for session cleaning. I don't even know why one would need to store sessions in a Database your sorta trying to paddle up river in that case because sessions for the most part are used to give a single "session" of user activity a direct connection to specific portions of the databases to provided them with enriched content. Your trying to make a session into something more along the lines of a cookie I believe.

 

This is slightly off topic, but there are a couple of reasons for storing sessions in a database:

 

• SECURITY: If you are on a shared host, it may be possible for others who share your server to see your session files. Storing sessions in the database restricts access to only those with database privileges.
  
• SCALABILITY: If you website grows and requires additional servers to handle the traffic, file based sessions will break. When a session is generated, the session file is stored on the specific server that ran the initial session_start() function. There is no way to reliably re-route that specific user back to that specific server, at least without loosing the advantages of having several web servers behind a load balancer in the first place. By storing the sessions in a database, then having multiple web servers share that one database server, the sessions will remain available regardless of what web server the user hits.
  

 

There are a couple of other reasons, but these two are why most people who store sessions in the database do so. I'm sure these were the reasons the guys at PHP decided to make the session_set_save_handler() function as well. Also, this isn't related to cookies at all! Sessions HAVE to be saved somewhere in order to maintain a state. This is simply a way of storing the session in a different location, regardless of the cookie.

 

Oh yeah, and the purpose of sessions isn't to give users "a direct connection to specific portions of the databases". You can use sessions and provide completely static file based content. Sessions are used to maintain a state...no more, no less.

[PFMaBiSmAd]

Security on a shared server is solved by simply setting the session save path to be a private folder within your own account space. This also solves the problem of other scripts using a short session.gc_maxlifetime and deleting your session data files sooner than your own setting would have.

[Laxidasical]

Security on a shared server is solved by simply setting the session save path to be a private folder within your own account space. This also solves the problem of other scripts using a short session.gc_maxlifetime and deleting your session data files sooner than your own setting would have.

 

Thank you for mentioning the security point!  I meant to address that in my last post.

 

I remedied the session.gc_maxlifetime issues by storing my own expiration date in the session database table (as a UNIX timestamp).  The "expires" field is updated every time the session is written to.  You can set the variable used in the UPDATE or INSERT query to use the default time as such:

 

$expires = time() + get_cfg_var("session.gc_maxlifetime");

 

...or you can set your own time is seconds.  So if you wanted the max time to be 30 minutes:

 

$expires = time() + 1800;

 

I run a query in the garbage collection function that deletes sessions based on that field.  By the way, in case anyone reading this is completely clueless as to where I am setting these functions or about changing the location of where you store sessions (file or database), see session_set_save_handler().

[PFMaBiSmAd]

As long as you realize that using the session_set_save_handler with parsed/interpreted php code to perform each function that each session operation will be more than 20 times slower + the additional overhead of the mysql queries than using the complied code of the default file based handler.

[Laxidasical]

As long as you realize that using the session_set_save_handler with parsed/interpreted php code to perform each function that each session operation will be more than 20 times slower + the additional overhead of the mysql queries than using the complied code of the default file based handler.

 

I've used database stored sessions on both low and high traffic sites and have never seen a decrease in speed.  The largest of the 6 required functions is only 8 lines of code.

 

I've definitely seen an increase in speed when we scale servers though...