Mechanismus zum Recycling von PHP-Sitzungen

Aufgrund des Arbeitsmechanismus von PHP verfügt es nicht über einen Daemon-Thread, um Sitzungsinformationen regelmäßig zu scannen und festzustellen, ob sie ungültig sind. Wenn eine gültige Anfrage auftritt, entscheidet PHP basierend auf dem Wert der globalen Variablen session.gc_probability/session.gc_divisor (die auch über die Funktion php.ini oder ini_set() geändert werden kann) ob ein GC (Garbage Collector) gestartet wird. . Standardmäßig ist session.gc_probability = 1, session.gc_divisor = 100, was bedeutet, dass die Wahrscheinlichkeit, dass GC gestartet wird, bei 1 % liegt.

Die Aufgabe von GC besteht darin, alle Sitzungsinformationen zu scannen, die letzte Änderungszeit (Änderungsdatum) der Sitzung von der aktuellen Zeit zu subtrahieren und sie mit dem Parameter session.gc_maxlifetime zu vergleichen, wenn die Überlebenszeit überschritten wurde gc_maxlifetime, die Sitzung wird gelöscht.

Warum wird gc_maxlifetime dann ungültig?

Standardmäßig werden Sitzungsinformationen in Form von Textdateien im temporären Dateiverzeichnis des Systems gespeichert. Unter Linux ist dieser Pfad normalerweise tmp und unter Windows normalerweise C:WindowsTemp. Wenn mehrere PHP-Anwendungen auf dem Server vorhanden sind, speichern diese ihre Sitzungsdateien im selben Verzeichnis. Ebenso starten diese PHP-Anwendungen mit einer bestimmten Wahrscheinlichkeit auch GC und scannen alle Sitzungsdateien.

Das Problem besteht darin, dass der GC bei laufendem Betrieb nicht zwischen Sitzungen auf verschiedenen Websites unterscheidet. Beispielsweise ist gc_maxlifetime für Standort A auf 2 Stunden und gc_maxlifetime für Standort B auf den Standardwert von 24 Minuten festgelegt. Wenn der GC von Site B startet, scannt er das öffentliche temporäre Dateiverzeichnis und löscht alle Sitzungsdateien, die älter als 24 Minuten sind, unabhängig davon, ob sie von Site A oder B stammen. Auf diese Weise ist die gc_maxlifetime-Einstellung von Site A nutzlos.

Es ist einfach, das Problem zu finden und zu lösen. Ändern Sie den Parameter session.save_path oder verwenden Sie die Funktion session_save_path(), um das Verzeichnis, in dem die Sitzung gespeichert wird, auf ein dediziertes Verzeichnis zu verweisen. Der Parameter gc_maxlifetime funktioniert normal.

Ein weiteres Problem besteht darin, dass gc_maxlifetime nur die kürzeste Überlebenszeit der Sitzung garantieren kann und nicht gespeichert werden kann. Nach dieser Zeit werden die Sitzungsinformationen sofort gelöscht. Da GC auf Wahrscheinlichkeitsbasis gestartet wird und möglicherweise über einen längeren Zeitraum nicht gestartet wird, ist eine große Anzahl von Sitzungen auch nach Überschreiten von gc_maxlifetime noch gültig. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, die Wahrscheinlichkeit von session.gc_probability/session.gc_divisor zu erhöhen. Wenn sie auf 100 % erhöht wird, wird dieses Problem vollständig gelöst, aber es wird offensichtlich schwerwiegende Auswirkungen auf die Leistung haben. Eine andere Methode besteht darin, die Lebensdauer der aktuellen Sitzung in Ihrem Code zu bestimmen. Wenn sie gc_maxlifetime überschreitet, löschen Sie die aktuelle Sitzung.

Die PHP-Sitzungs-GC-Funktion ist Garbage Collector. Wenn dieser GC startet, werden die Sitzungen gelöscht, bei denen eine Zeitüberschreitung aufgetreten ist. Das funktioniert so:

Der Benutzer greift auf die Website zu und meldet sich an. Zu diesem Zeitpunkt ruft der Hintergrund session_start auf, um zu versuchen, eine Sitzung zu generieren (wenn bereits eine Sitzung vorhanden ist, entspricht dies einer gültigen Sitzung). Sitzungsanforderung)

Für jede solche gültige Sitzungsanforderung (Anfrage) berechnet das PHP-Modul von Apache die Wahrscheinlichkeit, GC zu starten, basierend auf der sitzungsbezogenen globalen Variablen gc_probability/gc_divisor => und verwendet diese Wahrscheinlichkeit, um zu entscheiden, ob Es sollte in dieser Anfrage verwendet werden. Starten Sie den GC. Wenn beispielsweise der Standardwert von session.gc_probability 1 und der Standardwert von session.gc_divisor 100 beträgt, beträgt die Wahrscheinlichkeit, mit der „Garbage Collection“ zu beginnen, 1 %, was bedeutet, dass alle 100 Anforderungen vorhanden sind Es ist möglich, eine abgelaufene Sitzung zu bereinigen

Wenn GC gestartet wird, scannt GC alle Sitzungsdateien unter dem Pfad der aktuellen Sitzung (session.save_path) und ermittelt anhand des Werts eines anderen globalen Parameters, welche Sitzungen abgelaufen sind Variable session.gc_maxlifetime. Abgelaufen (die Differenz zwischen „aktueller Zeit“ und „atime oder mtime der Sitzungsdatei“ ist größer als gc_maxlifetime: abgelaufen) und löschen Sie diese abgelaufenen Sitzungen

Wenn Sie eine Zeit lang keine Interaktion haben Lange Zeit nach dem Start einer Sitzung (z. B. ununterbrochenes Codieren, ohne Senden oder Speichern als Entwurf) kann Ihre im Hintergrund gespeicherte Sitzungsdatei während gc_maxlifetime (Standardwert 1440) nicht geändert oder darauf zugegriffen werden Sekunden = 24 Minuten) Anschließend wird es möglicherweise aufgrund einer Ungültigmachung bereinigt. Wenn Sie es in Zukunft erneut einreichen, wird ein Fehler aufgrund einer Sitzungsungültigmachung gemeldet

Es ist ersichtlich, dass gc_maxlifetime auf 24 Minuten eingestellt ist , was zum Schreiben einiger Artikel nicht ausreicht. Dies ist ein Grund dafür, dass der Standardpfad von session.save_path unter Linux /tmp ist und nur wenige Programme diese Einstellung ändern. Wenn auf diesem Server mehrere virtuelle Hosts vorhanden sind, werden viele Sitzungsdateien mit unterschiedlichen Sitzungsnamen im Verzeichnis /tmp gespeichert. Das Schlimme ist, dass der GC von PHP nicht zwischen Sitzungsbesitz unterscheidet. Er bereinigt alle abgelaufenen Sitzungsdateien in diesem Verzeichnis basierend auf der erhaltenen gc_maxlifetime.

Gemäß der obigen Analyse lautet die Lösung: UTBLOG fügt eine Anweisung in der .htaccess-Datei hinzu, erweitert den lokalen Wert von session.gc_maxlifetime auf 14400 (4 Stunden) und setzt session.save_path auf / im Hintergrund. tmp/utblog, damit die Sitzungsdatei von utblog nicht von anderen Websites beeinträchtigt wird, und die Ablaufzeit von 4 Stunden sollte meiner Meinung nach sowieso ausreichen.

Nachdem ich es getestet habe, ist alles so, wie ich es erwartet habe.

Außerdem ist es natürlich möglich, /etc/php.ini direkt zu ändern. Wenn Sie keine Berechtigung zum Ändern von php.ini oder der Conf-Datei von Apache haben und .htaccess verboten ist, ändern Sie direkt die Datei sessionmanager.class.php von plog und fügen Sie ini_alter("session.gc_maxlifetime", 14400) vor der Zeile session_start hinzu . Dürfen. Die Plog-Struktur ist gut, nur dieser Teil ruft session_start auf, sodass nur dieser Teil geändert werden muss. Ich habe es vor Ort getestet und es funktioniert.

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

session.gc_probability Ganzzahl

session.gc_probability vs. session.gc_divisor werden zusammen verwendet, um die Wahrscheinlichkeit des Starts des gc-Prozesses (Garbage Collection) zu verwalten. Der Standardwert ist 1. Weitere Informationen finden Sie unter session.gc_divisor.

session.gc_divisor integer

session.gc_divisor und session.gc_probability definieren zusammen die Wahrscheinlichkeit, mit der der gc-Prozess (Garbage Collection) gestartet wird, wenn jede Sitzung initialisiert wird. Diese Wahrscheinlichkeit wird mit gc_probability/gc_divisor berechnet. Beispielsweise bedeutet 1/100, dass bei jeder Anfrage eine Wahrscheinlichkeit von 1 % besteht, dass der GC-Prozess gestartet wird. session.gc_divisor ist standardmäßig 100.

session.gc_maxlifetime integer

session.gc_maxlifetime gibt die Anzahl der Sekunden an, nach denen die Daten als „Müll“ betrachtet und gelöscht werden.

Hinweis:

Wenn verschiedene Skripte unterschiedliche session.gc_maxlifetime-Werte haben, sich aber denselben Ort zum Speichern von Sitzungsdaten teilen, bereinigt das Skript mit dem kleinsten Wert die Daten. Verwenden Sie in diesem Fall diese Direktive zusammen mit session.save_path.

Hinweis: Wenn Sie den standardmäßigen dateibasierten Sitzungshandler verwenden, muss das Dateisystem die Zugriffszeit (atime) im Auge behalten. Das Windows-FAT-Dateisystem funktioniert nicht. Wenn Sie also ein FAT-Dateisystem oder ein anderes Dateisystem verwenden müssen, das die Zeit nicht verfolgen kann, müssen Sie eine andere Möglichkeit finden, mit der Speicherbereinigung von Sitzungsdaten umzugehen. Seit PHP 4.2.3 wird mtime (Änderungszeit) anstelle von atime verwendet. Daher ist es kein Problem für Dateisysteme, die die Zeit nicht verfolgen können.