PHP session recovery mechanism (GO)

because of PHP's working mechanism, it does not have a daemon thread to periodically scan the session information and determine if it is invalid. When a valid request occurs, PHP session.gc_probability/session.gc_divisor the value of the global variable (which can also be modified by the php.ini or Ini_set () function). To decide whether to start a GC (garbage Collector). By default, session.gc_probability = 1,session.gc_divisor = 100, which means that there is a 1% possibility to start the GC.

The GC's job is to scan all session information, subtracting the last modification time of the session (modified date) with the current time, and comparing it with the Session.gc_maxlifetime parameter if the lifetime has exceeded GC_ Maxlifetime, delete the session.

Then why does it happen that Gc_maxlifetime is invalid?

By default, session information is saved in the temporary file directory of the system as a text file. Under Linux, this path is typically \tmp, which is typically C:\Windows\Temp under Windows. When there are multiple PHP applications on the server, they will keep their session files in the same directory. Similarly, these PHP applications will launch the GC at a certain probability, scanning all session files.

The problem is that when the GC is working, it does not differentiate between sessions at different sites. For example, site A's gc_maxlifetime is set to 2 hours, and Site B's gc_maxlifetime is set to the default of 24 minutes. When the GC of Site B starts, it scans the common temporary files directory and removes all session files that are more than 24 minutes, regardless of whether they come from site A or B. In this way, site A's gc_maxlifetime setting is no more than a dummy.

Finding the problem is a simple solution. Modify the Session.save_path parameter, or use the Session_save_path () function to point the directory where the session is saved to a dedicated directory, and the Gc_maxlifetime parameter is working properly.

Another problem is that gc_maxlifetime can only guarantee the shortest time that the session will survive, and not be able to save the session information immediately after it has been deleted. Because the GC is started by chance and may not be started for a long period of time, a large number of sessions will still be valid after more than Gc_maxlifetime. One way to solve this problem is to increase the odds of session.gc_probability/session.gc_divisor, and if you mention 100%, it will solve the problem completely, but it will obviously have a serious impact on performance. Another way is to judge the current session's lifetime in code and empty the current session if the gc_maxlifetime is exceeded.

PHP session GC function, is garbage Collector. When this GC starts, it clears the " timed out " session. It works like this:

1. When a user accesses and logs into a Web site, the backend invokes Session_Start to attempt to generate a session (equivalent to a valid session request if there is already a session)
2. For each of these valid session requests (request), the Apache PHP module calculates the probability of starting the GC based on the session-related global variable gc_probability/gc_divisor = =. And this probability determines whether the GCshould be started in this request. For example, the default value of 1,session.gc_divisor for session.gc_probability is 100, the probability of starting the garbage collector is 1%, which means that in every 100 requests, it is possible to clean up an expired session
3. If the GC starts, the GC scans all session files under the path (Session.save_path) of the current session , and according to another global variable session.gc_ Maxlifetime how much to determine which session has expired (the difference between the "current time" and "atime or Mtime of the session file is greater than Gc_maxlifetime: expired), and delete these expired session
4. If you start a session after a long time without any interaction (for example, keep the code word, not submitted or saved as a draft), then your saved in the background of the session file will not be modified or accessed, in gc_ Maxlifetime (the default value of 1440 seconds = 24 minutes) After the time, it may be failed to be cleaned up, after you submit again, will be due to session failure and error

This shows that the gc_maxlifetime set to 24 minutes, for writing some articles is not enough. This is a reason, in addition, the default path for Session.save_path is/tmp on Linux, and very few programs modify this setting. If there are multiple virtual hosts on this server, then the/tmp directory will hold many different session_name session files. Unfortunately, the PHP GC does not differentiate between session attribution, and it cleans up all expired session files in this directory based on the gc_maxlifetime it obtains.

According to the above analysis, the solution is: Utblog added a statement within the. htaccess file, extending the local value of Session.gc_maxlifetime to 14400 (4 hours), At the same time in the background set Session.save_path to/tmp/utblog, so that utblog session files are not affected by other sites, and 4 hours of failure time, I think, anyway should be enough.

Test it down, everything as I wish.

Alternatively, if you change the/etc/php.ini directly, you can of course. If you do not have permission to change php.ini, and do not have permission to change the Apache conf file,. htaccess is forbidden, then directly modify Plog sessionmanager.class.php file, add Session_Start before Ini_ line Alter ("Session.gc_maxlifetime", 14400) also. Plog structure is good, only this one place call Session_Start, so only this place need to modify. I have been tested locally and can work.

--------------------------------------------------------------------------

session.gc_probability integer

session.gc_probability and Session.gc_divisor together to manage the probability that the GC (garbage collection garbage collection) process starts. The default is 1. See Session.gc_divisor.

Session.gc_divisor integer

session.gc_divisor and session.gc_probability together define the probability of starting the GC (garbage collection garbage collection) process at each session initialization. This probability is calculated by Gc_probability/gc_divisor. For example, 1/100 means that there is a 1% probability of starting the GC process in each request. The default is session.gc_divisor .

Session.gc_maxlifetime integer

Session.gc_maxlifetime Specifies the number of seconds after which the data is considered "junk" and cleared.

Note:

If different scripts have different session.gc_maxlifetime values but share the same place to store session data, the script with the smallest number cleans up the data. In this case, use this directive with Session.save_path.

Note: If you use the default file-based session processor, the file system must keep track of access time (Atime). The Windows FAT file system does not work, so if you have to use the FAT file system or other file systems that cannot track atime, then you have to think of another way to handle the garbage collection of session data. Since PHP 4.2.3 Mtime (modified time) to replace the atime. So there's no problem with file systems that can't track atime.

--------------------------------------------------------

From:

http://www.php.net/manual/zh/session.configuration.php

http://ydirone.blog.163.com/blog/static/30414895201141711524253/

http://www.utblog.com/plog/1/article/463

Http://www.laruence.com/2012/01/10/2469.html

PHP session recovery mechanism (GO)