CoolATIGuy
asked on
PHP Session gc_maxlifetime?
I'm wondering, what good is php_value session.gc_maxlifetim? Why not just have a session expire upon not being accessed for x amount of time, then delete them...why keep them around for any longer with maxlifttime?
CoolATIGuy
Example:
php_value session.cache_expire 25 <--- mins how long a session is alive
php_value session.gc_probability 20 <--- percentage of time old sessions are deleted
php_value session.gc_maxlifetime 1500 <-- sec how long an expired session is considered trash
CoolATIGuy
Example:
php_value session.cache_expire 25 <--- mins how long a session is alive
php_value session.gc_probability 20 <--- percentage of time old sessions are deleted
php_value session.gc_maxlifetime 1500 <-- sec how long an expired session is considered trash
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm not understanding your explanations for the different variables...what do you mean by "how long this document is valid before the browser needs to recheck the page"?
CoolATIGuy
CoolATIGuy
ASKER
hernst42,
I'd really like to figure this out and get it closed....does anyone have any ideas?
CoolATIGuy
I'd really like to figure this out and get it closed....does anyone have any ideas?
CoolATIGuy
The cache_expire gives the validty of the html docment in the cache or in a proxy. If the user does not do a reload of the html-page is taken from the cache/proxy and there is no request send to the webserver.
The setting is only relevant if you also use none for session.cache_limiter
The setting is only relevant if you also use none for session.cache_limiter
ASKER
Found this: http://www.zend.com/manual/function.session-cache-expire.php
So basically the cache_expire says that if the user logs in, then doesn't do anything for xx minutes (defaults to 180 minutes), then they have to log in to access session-secure info.
The gc_probability determines how often the expired sessions get deleted.
And gc_maxlifetime will allow the user to be logged out, but leave the session behind for awhile, so the user can see a message saying that they timed out, etc.
Sound right?
CoolATIGuy
So basically the cache_expire says that if the user logs in, then doesn't do anything for xx minutes (defaults to 180 minutes), then they have to log in to access session-secure info.
The gc_probability determines how often the expired sessions get deleted.
And gc_maxlifetime will allow the user to be logged out, but leave the session behind for awhile, so the user can see a message saying that they timed out, etc.
Sound right?
CoolATIGuy
No,
If gc_probability is set to 1 (default 1/100) then every (default about every 100) php-page request all stored session (of all users) are checked and those session that are older (have not been modified) since time() - gc_maxlifetime are deleted.
cache_expire will only work if cache_delimiter is set to a value != nocache. So if you use the default for cache_delimter (nocache) you can ignore cache_expire as it will not be used.
So depending on the value of cache_expire (here 60) and cache_delimiter = private the webserver generate the following in the HTTP-Headers:
Cache-Control: private, max-age=3600, pre-check=3600
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 for a detailed explanaition of caching for HTTP
In the link max-age is described as the following:
max-age
When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency.
However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response.
If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age.
If gc_probability is set to 1 (default 1/100) then every (default about every 100) php-page request all stored session (of all users) are checked and those session that are older (have not been modified) since time() - gc_maxlifetime are deleted.
cache_expire will only work if cache_delimiter is set to a value != nocache. So if you use the default for cache_delimter (nocache) you can ignore cache_expire as it will not be used.
So depending on the value of cache_expire (here 60) and cache_delimiter = private the webserver generate the following in the HTTP-Headers:
Cache-Control: private, max-age=3600, pre-check=3600
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 for a detailed explanaition of caching for HTTP
In the link max-age is described as the following:
max-age
When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency.
However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response.
If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age.
ASKER
Can you give me fictional examples of those 3 variables being used, please?
CoolATIGuy
CoolATIGuy
here are the examples from the php.ini
; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process starts
; on each request.
session.gc_probability = 1
session.gc_divisor = 100
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
So if that garbage process is started all session stored in /tmp are deleted by PHP which are older than 24 minutes (gc_maxlifetime). A session is expired if the user with that session does not has accessed the server for 24 minutes. It could also happen that if there are very few accesses to the server that the session is still valid after 30 or 60 minutes, because the garbage collection of PHP hasn't be statred.
As the cache_delimiter is set to nocache the value of cache_expire is not used and has no effect on the session.
; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process starts
; on each request.
session.gc_probability = 1
session.gc_divisor = 100
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
So if that garbage process is started all session stored in /tmp are deleted by PHP which are older than 24 minutes (gc_maxlifetime). A session is expired if the user with that session does not has accessed the server for 24 minutes. It could also happen that if there are very few accesses to the server that the session is still valid after 30 or 60 minutes, because the garbage collection of PHP hasn't be statred.
As the cache_delimiter is set to nocache the value of cache_expire is not used and has no effect on the session.
ASKER
Thanks
CoolATIGuy
CoolATIGuy
ASKER
CoolATIGuy