[php] Re2: session_set_save_handler() + SQL MEMORY-Tabelle vs. mount tmpfs + session_save_path()

[Thomas Koudela]

Am Montag, den 12.01.2009, 08:30 +0100 schrieb Sebastian Mendel:
> On 2009-01-09 12:47, Thomas Koudela wrote:
> > Hallo,
> >
> > ich arbeite gerade an einer Autorisierungsklasse und überlege wie
> > Sessions optimal (bzgl. der Performance) eingebunden werden können. Die
> > klassische Speicherung der serialisierten Session auf der Festplatte
> > erscheint mir dabei suboptimal.
> 
> hast du dir schonmal memcached angeschaut?
> 
> http://www.danga.com/memcached/
> http://php.net/memcache

Sehr nett. Insbesondere für Datenbankanwendungen mit häufigen Lese- und
wenigen Schreibzugriffen. Da sich in der Session auch mehrere Variablen
wiederfinden werden, die sich fast bei jedem Aufruf ändern (und sich
damit die serialisierte Streamvariable ändert), werde ich hierfür
allerdings eine andere Möglichkeit vorziehen.

> oder APC
> 
> http://de.php.net/manual/en/function.apc-add.php

Will ich auf dem Server installieren, jedoch hätte ich ohne Deinen
Hinweis, diese interessante Funktion übersehen. Danke für den
Hinweis. :-)

Daraus ließe sich in der Tat ein Cache-Sessionmanagement basteln. In
anbetracht der Tatsache, dass ich schon zwei andere vergleichbare
Möglichkeiten ins Auge gefasst habe, werde ich dies lediglich im
Hinterkopf behalten.

> oder Sessions mit mm
> 
> http://php.net/manual/en/session.requirements.php

Hatte ich mir früher schon mal angesehen. Die Dokumentation ist sehr
dürftig. Bzgl. der von mir gestellten Fragen müsste ich mich
_zusätzlich_ noch durch den Quellcode wühlen. Und ich bezweifle, dass
meine C-Kenntnisse und Erfahrungen ausreichend sind, um die Vor- und
Nachteile dieser Erweiterung richtig abschätzen zu können.

"On the first layer it hides all platform dependent implementation
details (allocation and locking) when dealing with shared memory
segments and on the second layer it provides a high-level
malloc(3)-style API for a convenient and well known way to work with
data structures inside those shared memory segments."

Dieser Auszug aus dem Abstract heißt für mich im Klartext: Wir opfern
die Vorteile, das Richtige in der richtigen Schicht des Systems zu tun,
um mehr Plattformen bedienen zu können und bügeln die dadurch bedingten
Nachteile so gut wie möglich aus. Nicht unbedingt das wonach ich
suche. :-)

> "Note: Optionally you can use shared memory allocation (mm), developed 
> by Ralf S. Engelschall, for session storage. You have to download » mm 
> and install it. This option is not available for Windows platforms. Note 
> that the session storage module for mm does not guarantee that 
> concurrent accesses to the same session are properly locked. It might be 
> more appropriate to use a shared memory based filesystem (such as tmpfs 
> on Solaris/Linux, or /dev/md on BSD) to store sessions in files, because 
> they are properly locked. Session data is stored in memory thus web 
> server restart deletes it."

php.net empfielt anscheinend dann auch eher die angesprochene mount
tmpfs + session_save_path() Variante.

> also da gibt es schon einige fertige Lösungen die das was du willst 
> bereits umsetzen

??? Im meinem Post habe ich doch auf "fertige Lösungen" gesetzt. Wobei
man sich jetzt streiten könnte wie weit der Begriff "fertige Lösungen"
ausgelegt werden kann. :-)

> Sebastian Mendel

Danke für Deine Antwort. Auch wenn meine Fragen unbeantwortet blieben,
waren die Anregungen (insbesondere memcache und apc_add([...])) sehr
interessant.

Ich denke mittlerweile für das Sessionhandling ist die performanteste
Lösung mount tmpfs + session_save_path(), schließlich läuft dabei die
Speicherung im Cache direkt auf Betriebssystemebene ab. Die Datenbank
benötigt zumindest durch das Parsen der Anfrage einen kleinen Overhead.

Gruß, Thomas K.