PHP Session Speicher hochperformant und skalierbar
Kommentare

Johannes Schlüter hat der Community wieder einmal einen lesenwerten Artikel über PHP Sessions beschert. Da das HTTP-Protokoll neben dem Status Code 418 zustandslos ist, muss der Webserver keine Informationen

Johannes Schlüter hat der Community wieder einmal einen lesenwerten Artikel über PHP Sessions beschert. Da das HTTP-Protokoll neben dem Status Code 418 zustandslos ist, muss der Webserver keine Informationen über den Nutzer speichern oder Ressourcen zuweisen, nachdem ein individueller Request erfolgt ist. Aktuell besteht das Web aber nicht mehr ausschließlich aus statischen Dokumenten, sondern eben auch aus Webanwendungen, die häufig einen Zustand benötigen. Die banalste Information, die diesbezüglich benötigt wird, ist der aktuelle Nutzer.

HTTP bietet trotz seiner zustandslosen Natur eine Möglichkeit zur Authentifizierung beispielsweise über einen zufälligen Identifier in einem Cookie. Damit sind alle Session-Daten geschützt, und nur der Nutzer, der den zufälligen Identifier kennt, ist auch authentifiziert. Mit einem gut gewählten Identifier funktioniert das ganz ordentlich, noch effizienter geht´s allerdings Schlüters Meinung nach mit dem PHP Session Modul.

Das mit PHP 4 eingeführte Modul speichert in der Default-Config den Session State im Dateisystem des Webservers – jeweils in einer eigenen Datei in serialisierter Form. Verwendet das Filesystem Caching oder eine RAM-Disk, kann das ziemlich effizient sein. Aber haben wir plötzlich einen Zustand, den der Webserver verarbeiten soll, zum Beispiel durch das Hinzufügen eines weiteren Servers, zu dem die aktuelle Nutzer-Session geroutet werden soll, haben wir ein Problem: Denn dort gibt es keine Daten über die aktuellen Sessions. Aktuell wird dieses Problem damit umgangen, dass Loadbalancer so konfiguriert werden, dass alle Requests des selben Nutzers auch zum selben Webserver geroutet werden. Das kann funktionieren, muss aber nicht – besonders in Fällen, wenn Server aufgrund von Wartungsarbeiten heruntergefahren werden müssen. Schlüter schlägt hier als elegante Lösung vor, alle Sitzungen in einem zentralen Repository zu speichern. In einem vorhergehenden Blogpost hatte er diesbezüglich die Verwendung von MySQL 5.6 und der Memcached API diskutiert. Aber auch solche Systeme haben Grenzen und Replikation ist hier keine Lösung. Das Clustern von Maschinen allerdings schon: Dadurch wird ein schneller Zugriff auf Session-Daten von allen Webservern und Lese- und Schreibezugriff auf das Cluster möglich. Schlüter empfiehlt für die Installation und Initial-Konfiguration eines Cluster-Testsystems den Post von Andrew Morgan zu lesen und zeigt, wie er das SQL-Cluster über einen SQL-Knoten und Memcache zum Laufen bringt. Great Posts! Vielen Dank!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -