Is setting session.gc_probability and session.gc_divisor equal to 100% a bad idea? Is setting session.gc_probability and session.gc_divisor equal to 100% a bad idea? symfony symfony

Is setting session.gc_probability and session.gc_divisor equal to 100% a bad idea?


The gc_probability and gc_divisor are there to let you define the "probability" of firing up the garbage collection (GC).

Since GC (as everything) comes with a cost, you wouldn't usually want it to run on each and every web request processed by your server - that would mean that every page opening or every AJAX request served from PHP would cause the GC to run.

So, depending on the actual server load and usage, the admin is expected to do an educated guess on how often should GC be run: once in 100, 1/10000 or 1 in million requests.

But, there's a problematic flaw in the OP's original reasoning - that garbage collection will occur on any idle session. The way I read the manual, the garbage collection will occur on ANY session, not just idle ones:

session.gc_maxlifetime integer: specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up.

So, the session (idle or not) lifetime is decided with gc_maxlifetime, while the moment of the GC being started (as said in the docs: "potentially") is really decided with gc_probability and gc_divisor.

To resume, my late answer to the question would be - I would not under normal condition have GC running at each and every request (the 1/1 scenario you mentioned), because

  1. that seems like a serious overkill. On some level, you would probably end up with thousands (if not worse) of IFs and only once going into its THEN
  2. you would log out ANY user on your system after 60mins, not just the idle ones.


There are much better ways of doing this.

If this isn't for something particularly secure, you can set an expiration date/length for the session cookies on the client-side. A technically minded user could tweak the expiration in this case, so you wouldn't want to use this on a bank site.

If you need something more secure, just store an expiration time along with the other session data and check against it. If it's exceeded, destroy their session and force them to log back in.