Apache::Session

Standardmäßig kommt RT mit Apache::Session daher, ein eher „suboptimales“ Modul, da es für die Updates die Datenbank Tabelle lockt, wer immer sich das ausgedacht hat, sollte bedenken, dass Locking die Aufgabe der DB und nicht eines Perl Modules ist. Vor allem eine Lock Zeit von 3600sek sind totaler Mist. Wie man recht gut sieht, braucht RT allein für den Login allein 10 Zugriffe auf die Sessions Tabelle, die dann jeweils gelockt ist, nicht gut, gar nicht gut!

Eine Alternative ist aber Apache::Session::MySQL::NoLock, welches die Updates wenigstens ohne ein DB Tabellen Locking macht. Weiter unten im großen, schwarzen Bild, ist recht gut zu sehen, warum auch das nicht optimal ist. Stellt Euch einfach vor, was passiert, wenn man etwa 20.000 User gleichzeitig auf dem System hat und davon, allein in Deutschland einige Tausend, sich typisch gegen 8 Uhr im System anmelden, dann macht die DB eigentlich nichts weiter als die User Sessions zu bewältigen. Weiterhin ist MySQL für diese Art der Nutzung nicht die beste DB.

Apache::Session::File

Eine temporäre Übergangslösung ist Apache::Session::File, also die Ablage der RT Sessions im Filesystem des Servers. Hier bietet sich ein geteiltes Verzeichnis zwischen den Webservern an, allerdings ist die Ablage dann viel zu langsam, da, wie man im Bild sieht, da durchaus sehr viele Dateien landen. Hier sind es aktuell etwa 550.000 Session Files. Wie man auch sieht, legen wir sie nicht in einem geteilten Verzeichnis ab, sondern in einem TempFS des jeweiligen Servers, einfach um die Masse an Abfragen bewältigen zu können. Der Nachteil: Wenn der User vom Loadbalancer auf einen anderen Webserver geschoben wird, muss er sich neu anmelden, sehr unbefriedigend!

Ein weiteres Problem, diese Sessions Files, können je nach User Einstellung verdammt groß werden. Hier sind die Größten zwar nur 2 MB, ich hatte aber auch schon welche gesehen, die 300-500MB groß waren.

Kommen wir nochmal zurück, zu dem Punkt, warum die Ablage der Sessions, in unserem Fall in einer Inmemory DB besser ist, als in der MySQL DB.

Wir verwenden einen Percona 3 Node Cluster, der seine Daten via iSCSI im SAN speichert. D.h. Ein schreibender Zugriff (Update, Insert) wird auf einem Node vorgenommen, dann auf die beiden anderen synchronisiert, dann jeweils im Storage gespeichert, dann gibt es erst ein „Hey, ich bin fertig, es kann weiter gehen“ vom Cluster. (grob vereinfacht erklärt). Wir sprechen hier, um es nochmal im Kopf zu behalten, von 20K Usern gleichzeitig, die diese Aktionen durchführen und jeweils für Bruchteile von Sekunden den Cluster beschäftigen, nur mit den Login Daten…..nicht optimal, da der eigentlich die Ticket Daten bereitstellen soll.

Apache::Session::Redis

Kommen wir nochmal auf das Bild von ganz Oben zurück:

Links sehen wir die MySQL Sessions, mit Speicherung der RT Sessions in der MySQL Tabelle, rot markiert darin die Queries, die nur für die RT Sessions gemacht werden. Links dann der gleiche Vorgang, allerdings ohne die RT Sessions, die jetzt in der Redis DB liegen. Wir ersparen uns 10 MySQL Queries pro User und Sitzung, also 10 x den Vorgang, wie weiter oben, im Cluster Teil beschrieben…!!! <- !!! (ich würde noch mehr !!!! verwenden wollen, aber dann werde ich wieder gedisst!)