After the upgrade to PHP 8.2, pages failed at random after 30 seconds. The cause was the lock on the session file, not PHP 8

On Linux the error cannot be reproduced

On Linux, max_execution_time counts the CPU time of the script, and waiting for a lock uses none. On Windows the measured time is real time, as the PHP manual states. On Linux we therefore measured the real duration of the calls and counted anything above 30 seconds as a failure in production.

PHP 8 did not change the lock, but PHP 7.4.22 changed flock() on Windows

The fix for bug #81223 (opens in a new window) of July 2021 locks the whole file on Windows instead of the first byte. The client came from PHP 7.4.9, so for them this was a real difference, just not one of PHP 8. Because locks on Windows are mandatory, since then any other process reading session files, such as a virus scanner or an indexing service, gets in the way. We therefore exclude the session folder from scanning.

Uneven, because the order of waking up is open

Whoever waits for the lock is not served in the order of the requests. Under identical load the home page waited 0 seconds once and 4.5 seconds another time. Hence the impression "sometimes it works, sometimes it does not".

Session garbage collection runs under the lock

It starts at random in session_start(), after the lock is taken, and scans the whole session folder. With 100,000 files this took 0.3 seconds on Linux, much longer on NTFS with a virus scanner. Without php.ini the probability is 1 in 100 per call, not 1 in 1000 as in php.ini-production; with 20 calls per page this hits a noticeable share of page views.

session_write_close() changes the rules without an error

Writing to $_SESSION after closing raises no error and saves nothing. Another session_start() waits for the lock again and replaces $_SESSION with the content of the file, so values set in between are lost. After headers have been sent, the restart fails with a warning. We confirmed each of these behaviours in both versions.

A session without a lock is not a solution

A handler without a lock is possible, but it costs writes: in the test, a slower call overwrote the data that a faster one had saved in parallel with its stale copy. In an application that writes to the session on every call, that means random logouts and vanishing settings. Opcache only speeds things up: a call took 0.5 instead of 1.9 ms, the lock stayed at 30 seconds.

Instead of adding session_write_close() to every AJAX script separately, the shared bootstrap file got a switch. A script that only reads the session declares this before the include:

define('SESSION_READONLY', true);

The bootstrap file does what it did before and releases the lock right after reading:

$bSessionReadOnly = defined('SESSION_READONLY') && SESSION_READONLY;

session_start();
$_SESSION['marker'] = 0;

if ($bSessionReadOnly) {
    session_write_close();
}

$_SESSION stays readable to the end, the lock lasts a fraction of a millisecond. If such a script rarely does need to write: compute first, then open a short window, write, close, before any output.

Settings without code changes came on top: opcache with file_cache as a fallback on Windows, a dedicated session folder excluded from virus scanning, with a check of the file count and an explicitly set session.gc_divisor. The client received a measuring tool in PHP based on curl_multi that measures a single call and 21 parallel calls on the Windows server before and after the change: if the parallel calls take about 20 times as long as one, they run one after another.

• "After the upgrade" does not mean regression. Here the upgrade exposed a weakness that had existed for years.
• Two versions side by side under the same load settle the argument about the cause faster than any discussion.
• When in doubt, read the sources. A few dozen lines in mod_files.c and flock_compat.c answered "does PHP 8 wait for the session?".
• Platforms differ. The same code fails on Windows and runs on Linux, only because of how the time limit is defined.
• The best fix changes the least. One switch where the team looks anyway when sessions cause trouble, instead of a new application or sessions without a lock at the cost of data consistency.

Sources

• PHP: session_write_close() (opens in a new window)
• PHP: session_start() and the read_and_close option (opens in a new window)
• PHP: set_time_limit(), the note on Windows (opens in a new window)
• PHP 7.4.22: fix of bug #81223, flock() only locked the first byte (opens in a new window)