Session-Verwaltung optimieren

Wer auf seiner Seite einen Login hat, verwaltet die Autentifizierung der User üblicherweise per Cookies oder Sessions. Letzteres ist dabei praktikabler, da Cookies deaktiviert werden können und Sessions dann immernoch über GET-Parameter an der URL die Autentifizierung gewährleisten. Wenn aber Sessions genutzt werden, werden die Daten der Session auch auf dem Server gespeichert. Wer hier nicht aufpasst, kann sich schnell seinen Server vollfrummeln. Deshalb gibt es in diesem Beitrag einige Tipps zur effektiven Verwaltung von Sessions.

Session nur starten, wenn es nötig ist
Wenn es nicht nötig ist eine Session zu starten, sollte man es auch nicht tun. Das bedeutet, wenn jemand Hilfeseiten oder das Impressum ansieht und nicht gleichzeitig auf dieser Seite sein Benutzername angezeigt werden soll, braucht man auch keine Session starten. Denn jedes session_start() legt eine 0-Byte-Datei an, auch wenn man keine Session-Variable mit Inhalt füllt. Das können schnell sehr viele solcher Dateien sein – unnötiger Ballast fürs Dateisystem. Da jedoch der User meist irgendwo seinen Nutzernamen sehen soll, um ihm mitzuteilen, dass er noch eingeloggt ist, wird meist auf jeder Seite die Session per session_start() gestartet. Das ist also noch nicht ganz so tragisch …

Tragisch wird es erst, wenn…
In der php.ini kann per session.save_path das Verzeichnis gesetzt werden, in dem die Session-Dateien gespeichert werden sollen. Da dort ein absoluter Pfad angegeben werden muss, hat man völlige Freiheit, wo man das tut. Standardmäßig ist /tmp dort angegeben. Eine Session hat ja aber eine bestimmte Laufzeit (session.cookie_lifetime und session.gc_maxlifetime). Nach dieser Laufzeit soll die Session als abgelaufen betrachtet werden (Standard sind 24 Minuten).
Und jetzt kommt das Problematische: PHP ermittelt bei jeder Anfrage eine Wahrscheinlichkeit, jetzt eine Garbage Collection durchzuführen (einstellbar mit session.gc_probability und session.gc_divisor). Wenn die Garbage Collection durchgeführt wird, werden alle Session-Dateien, die älter als session.gc_maxlifetime sind, gelöscht. Doof nur, wenn PHP keine Rechte hat Dateien aus /tmp zu löschen. Denn dann läuft dieses Verzeichnis in aller Seelenruhe voll und wenn man Pech hat, merkt man es erst, wenn man mal eine aufwändige Operation mit vielen temporären Daten hat. Dann ist die Platte einfach voll und Feierabend. Mir ist das ganze mal mit einem OPTIMIZE TABLE passiert. Je nach Tabellengröße können dabei viele temporäre Dateien entstehen, die eventuell auch nach /tmp geschrieben werden. Aber wenn voll, dann voll – Tabelle gecrasht und musste repariert werden.

Also lieber ein eigenes Verzeichnis für die Sessions anlegen, wo sich PHP auch von den Rechten her austoben darf. Dieses sollte aber nicht öffentlich zugänglich sein und noch viel weniger darf ein DirectoryListing möglich sein, denn sonst können Sessions gehijacked werden.

Wahrscheinlichkeit der Garbage Collection
Je nach Besucheranzahl sollte die Wahrscheinlichkeit, dass die Garbage Collection durchgeführt wird, nicht zu hoch gewählt werden. Standardmäßig steht die auf 0,1% (session.gc_probability = 1 und session.gc_divisor = 1000). Wer täglich mehrere Tausend Zugriffe hat, darf das aber ruhig herabsetzen. session.gc_divisor auf 10000 ist ein guter wert für große Seiten. Oder man kümmert sich einfach selbst um die Garbage Collection, indem man in der Zeit, wenn die wenigsten Besucher kommen per Cronjob das Session-Verzeichnis durchläuft und das Alter der Dateien überprüft. Was zu alt ist, wird gelöscht (huch, das klingt jetzt ungewollt politisch – wirklich nicht beabsichtigt).

Also wer mit Sessions arbeitet, sollte diese Tipps beherzigen. Wenn ihr noch weitere Tipps habt, freue ich mich über eure Kommentare.