PHPsession garbage collection mechanism
Overview
Due to the working mechanism of PHP, zookeeper does not have a daemon thread. it periodically scans session information and determines whether the session 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.
Invalid gc_maxlifetime
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.
Working Principle of gc
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.
Understanding
- Session_id is saved in the cookie of the browser (client). disabling the cookie saving sessiond_id in the browser becomes invalid. in this case, the original session file cannot be accessed. The session file on the server may exist and has not been deleted.
- When a user does not perform any operations within 24 minutes (send a request to the server and open the browser), the session file may be garbage collected by gc and accessed within 24 minutes, A new session file with the same original session_id will be created, and the content of the original session file will no longer exist.
- Automatic logon is a cookie that saves logon information (such as user name and password) on the browser, instead of setting the cookie validity period for session_id.
- The validity period of a session_id ends when the browser is closed. when the browser is opened again, a new session_id (New session file) is generated ).
- Check whether the session file is invalid (deleted) on the server side. the current time is-the file modification time> gc_maxlifetime.
- The file modification time is modified every time the script is executed.
Original
Http://blog.csdn.net/21aspnet/article/details/7218923