Nach dem Update auf PHP 8.2 brachen Seiten zufällig nach 30 Sekunden ab. Schuld war die Sperre der Sitzungsdatei, nicht PHP 8

Unter Linux lässt sich der Fehler nicht nachstellen

Unter Linux zählt max_execution_time die Rechenzeit des Skripts, und das Warten auf eine Sperre verbraucht keine. Unter Windows ist die gemessene Zeit die echte Zeit, so steht es auch im PHP-Handbuch. Deshalb haben wir unter Linux die echte Dauer der Aufrufe gemessen und alles über 30 Sekunden als Abbruch in der Produktion gewertet.

PHP 8 hat die Sperre nicht geändert, PHP 7.4.22 aber flock() unter Windows

Die Korrektur des Bugs #81223 (öffnet in einem neuen Fenster) vom Juli 2021 sperrt unter Windows die ganze Datei statt des ersten Bytes. Der Kunde kam von PHP 7.4.9, für ihn war das ein echter Unterschied, nur nicht durch PHP 8. Weil Sperren unter Windows verbindlich sind, stört seitdem jeder andere Prozess, der Sitzungsdateien liest, etwa ein Virenscanner oder ein Indexdienst. Den Ordner der Sitzungen nehmen wir deshalb vom Scannen aus.

Ungleichmäßig, weil die Reihenfolge des Aufweckens offen ist

Wer auf die Sperre wartet, kommt nicht in der Reihenfolge der Anfragen dran. Bei identischer Last wartete die Startseite einmal 0 und einmal 4,5 Sekunden. Daher der Eindruck „mal geht es, mal nicht“.

Die Garbage Collection der Sitzungen läuft unter der Sperre

Sie startet zufällig in session_start(), nach dem Setzen der Sperre, und durchsucht den ganzen Ordner der Sitzungen. Bei 100 000 Dateien dauerte das unter Linux 0,3 Sekunden, auf NTFS mit Virenscanner deutlich länger. Ohne php.ini gilt eine Wahrscheinlichkeit von 1 zu 100 je Aufruf, nicht 1 zu 1000 wie in php.ini-production; bei 20 Aufrufen je Seite trifft das einen spürbaren Teil der Seitenaufrufe.

session_write_close() ändert die Regeln, ohne Fehlermeldung

Ein Schreiben in $_SESSION nach dem Schließen meldet keinen Fehler und speichert nichts. Ein erneutes session_start() wartet wieder auf die Sperre und ersetzt $_SESSION durch den Inhalt der Datei, Werte dazwischen gehen verloren. Nach gesendeten Headern scheitert der Neustart mit einer Warnung. Jedes dieser Verhalten haben wir in beiden Versionen bestätigt.

Eine Sitzung ohne Sperre ist keine Lösung

Ein Handler ohne Sperre ist möglich, kostet aber Schreibzugriffe: Im Test überschrieb ein langsamerer Aufruf mit seiner veralteten Kopie die Daten, die ein schnellerer parallel gespeichert hatte. In einer Anwendung, die bei jedem Aufruf in die Sitzung schreibt, wären das zufällige Abmeldungen und verschwundene Einstellungen. Auch Opcache beschleunigt nur: Ein Aufruf brauchte 0,5 statt 1,9 ms, die Sperre blieb bei 30 Sekunden.

Statt session_write_close() in jedes AJAX-Skript einzeln zu schreiben, bekam die gemeinsame Startdatei einen Schalter. Ein Skript, das die Sitzung nur liest, erklärt das vor dem Einbinden:

define('SESSION_READONLY', true);

Die Startdatei macht das Bisherige und gibt die Sperre gleich nach dem Lesen frei:

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

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

if ($bSessionReadOnly) {
    session_write_close();
}

$_SESSION bleibt bis zum Ende lesbar, die Sperre dauert Bruchteile einer Millisekunde. Muss ein solches Skript selten doch schreiben, gilt: erst rechnen, dann ein kurzes Fenster öffnen, schreiben, schließen, vor jeder Ausgabe.

Dazu kamen Einstellungen ohne Änderung am Code: Opcache mit file_cache als Rückfall unter Windows, ein eigener Ordner für Sitzungen ohne Virenscan, mit Kontrolle der Dateizahl und ausdrücklich gesetztem session.gc_divisor. Der Kunde erhielt ein Messwerkzeug in PHP auf Basis von curl_multi, das auf dem Windows-Server einen einzelnen Aufruf und 21 parallele Aufrufe vor und nach der Änderung misst: Dauern die parallelen etwa 20-mal so lange wie einer, laufen sie nacheinander.

• „Nach dem Update“ heißt nicht Rückschritt. Hier hat das Update eine Schwäche sichtbar gemacht, die seit Jahren bestand.
• Zwei Versionen nebeneinander unter gleicher Last klären den Streit um die Ursache schneller als jede Diskussion.
• Im Zweifel die Quellen lesen. Einige Dutzend Zeilen in mod_files.c und flock_compat.c haben die Frage „wartet PHP 8 auf die Sitzung?“ beantwortet.
• Plattformen unterscheiden sich. Derselbe Code bricht unter Windows ab und läuft unter Linux, nur wegen der Definition des Zeitlimits.
• Die beste Korrektur ändert am wenigsten. Ein Schalter dort, wo das Team bei Problemen mit Sitzungen ohnehin nachsieht, statt einer neuen Anwendung oder Sitzungen ohne Sperre auf Kosten der Datenkonsistenz.

Quellen

• PHP: session_write_close() (öffnet in einem neuen Fenster)
• PHP: session_start() und die Option read_and_close (öffnet in einem neuen Fenster)
• PHP: set_time_limit(), Hinweis zu Windows (öffnet in einem neuen Fenster)
• PHP 7.4.22: Korrektur von Bug #81223, flock() sperrte nur das erste Byte (öffnet in einem neuen Fenster)