Session validity in PHP

Session validity in PHP-Linux Enterprise Application-Linux server application information. For details, refer to the following section. The default session validity period in PHP is 1440 seconds (24 minutes). That is to say, if the client does not Refresh after 24 minutes, the current session will become invalid. Obviously, this cannot meet the needs.

I have encountered this problem in the past few years. I found it on the Internet and the results are amazing. Some say they want to set "session_life_time" (I have not found this parameter), some say they want to call session_set_cookie_params, some say they want to set session. cookie_lifetime, and some say they want to call session_cache_expire. However, these methods do not work.

A known method is to use session_set_save_handler to take over all session management tasks. Generally, session information is stored in the database, so that all expired sessions can be deleted through SQL statements, precisely control the validity period of the session. This is also a common PHP-based method for large websites. However, small websites do not seem to have to work hard.

The PHP document clearly states that the parameter for setting the session validity period is session. gc_maxlifetime. You can modify this parameter in the php. ini file or through the ini_set () function. The problem is that after multiple tests, modifying this parameter does not work, and the session validity period remains the default value for 24 minutes.

Since this issue was not particularly important, I did not continue to study it. It was not long ago that I had completely understood it.

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_divisor (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_divisor = 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.

So far, everything works normally. 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 problem is that GC does not differentiate sessions of different sites during operation. 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 the GC of Site B is started, It scans the public temporary file directory and deletes 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.

Strictly speaking, is this a PHP bug?

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_divisor increases. If we mention 100%, 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.