Phpsession collection mechanism

Due to the working mechanism of PHP, it does not have a daemon thread to regularly scan session information and determine whether it is invalid. When a valid request occurs, PHP will use the global variable session. gc_probabilitysession.gc_divisor (you can also use php. ini or ini _... due to the working mechanism of PHP, it does not have a daemon thread to regularly scan session information and determine whether it is invalid. When a valid request occurs, PHP will use the global variable session. gc_probability/session. gc_pisor (you can also use php. ini or ini_set () function to modify) to determine whether to start a GC (Garbage Collector ). By default, session. gc_probability = 1, session. gc_pisor = 100, that is, there is a 1% possibility to start GC.

GC is used to scan all session information and subtract the last modification time (modified date) of the session from the current time. compare the gc_maxlifetime parameter. if the survival time exceeds gc_maxlifetime, delete the session.

Why is gc_maxlifetime invalid?

By default, session information is saved as a text file in the temporary file directory of the system. In Linux, this path is usually \ tmp, and in Windows it is usually C: \ Windows \ Temp. When there are multiple PHP applications on the server, they will save their session files in the same directory. Similarly, these PHP applications start GC and scan all session files at a certain rate.

The question is that GC does not differentiate sessions of different sites during work. For example, the gc_maxlifetime of site A is set to 2 hours, and the gc_maxlifetime of Site B is set to the default 24 minutes. When GC of Site B is started, it will scan the public temporary file directory and delete all session files that have exceeded 24 minutes, regardless of whether they are from site A or site B. In this way, the gc_maxlifetime setting of site A is virtually empty.

Locate the problem and solve it easily. Modify the session. save_path parameter, or use the session_save_path () function to direct the Directory of the session to a dedicated directory. the gc_maxlifetime parameter works properly.

Another problem is that gc_maxlifetime can only ensure the shortest time for session survival. it cannot be saved until this time expires and the session information will be deleted immediately. GC is started by chance and may not be started for a long time. Therefore, a large number of sessions will still be valid after gc_maxlifetime is exceeded. One way to solve this problem is to set the session. gc_probability/session. the probability of gc_pisor increases. if 100% is mentioned, this problem will be completely solved, but it will obviously have a serious impact on performance. Another method is to determine the survival time of the current session in the code. if the time exceeds gc_maxlifetime, the current session is cleared.

The php session GC function is Garbage Collector. When the GC is started, sessions that have timed out will be cleared. It works like this:

When a user accesses and logs on to the website, the background will call session_start to generate a session (if there is already a session, it is equivalent to a valid session request)

For every valid Request, the apache php module calculates the probability of starting GC based on the global variable gc_probability/gc_pisor => related to the session, the probability determines whether GC should be started in this request. For example, session. the default value of gc_probability is 1, session. if the default value of gc_pisor is 100, the probability of starting the "Garbage Collector" is 1%, which means that an expired session may be cleared in every 100 requests.

If GC starts, GC scans the path of the current session (session. all session files under save_path, and according to another global variable session. gc_maxlifetime to determine which sessions have expired (the difference between "Current Time" and "atime or mtime of session files is greater than gc_maxlifetime: expired), and delete these expired sessions

If you do not perform any interactive operations for a long time after a session is started (for example, you do not submit or save it as a draft without stopping the code word ), your session files stored in the background will not be modified or accessed. after gc_maxlifetime (default value: 1440 seconds = 24 minutes), it may be cleared due to invalidation, if you submit the statement later, an error will be reported because the session fails.

Therefore, gc_maxlifetime is set to 24 minutes, which is not enough for writing some articles. This is one reason. In addition, the default path of session. save_path is/tmp on linux, and few programs will modify this setting. If the server has multiple virtual hosts, many session files with different session_name will be stored in the/tmp directory. Worse, php GC does not differentiate session ownership. 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 in. A statement is added to the htaccess file to set the session. the local value of gc_maxlifetime is extended to 14400 (4 hours), and the session is added in the background. set save_path to/tmp/utblog. in this way, the utblog session file will not be disturbed by other websites, and the four-hour expiration time will be enough in any case.

After testing, everything is as expected.

In addition, you can also directly change/etc/php. ini. If you do not have the permission to modify php. ini, and you do not have the permission to modify the apache conf file ,. if htaccess is disabled, modify the sessionmanager of plog directly. class. php file, add ini_alter ("session. gc_maxlifetime ", 14400. The plog structure is good. only session_start is called here, so only this one needs to be modified. I have performed tests locally and can work.

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

Session. gc_probability integer

Session. gc_probability and session. gc_pisor are combined to manage the probability that gc (garbage collection) processes start. The default value is 1. For details, see session. gc_pisor.

Session. gc_pisor integer

Session. gc_pisor and session. gc_probability together define the probability of starting the gc (garbage collection) process during each session initialization. This probability is calculated using gc_probability/gc_pisor. For example, 1/100 means 1% of the probability of starting the gc process in each request. The default value of session. gc_pisor is 100.

Session. gc_maxlifetime integer

Session. gc_maxlifetime specifies how many seconds later the data will be treated as "junk" and cleared.

Note:

If different scripts have different session. gc_maxlifetime values but share session data stored in the same place, the script with the minimum value clears the data. In this case, use this command with session. save_path.

Note: If the default file-based session processor is used, the file system must keep track of access time (atime ). Windows FAT file system does not work, so if you must use a FAT file system or other file systems that cannot track atime, you have to find another way to handle session data garbage collection. Mtime (modification time) is used to replace atime since PHP 4.2.3. Therefore, it is okay for file systems that cannot track atime.