Datenbank Session Handler schneller als Standard PHP Sessionverwaltung?

K

klausschreiber

Well-known member
ID: 162475
L
6 Mai 2006
247
8
Hallo,

ich habe in einem Forum, wo jemand ein Mod verkauft, das die Sessions in einer MySQL Datenbank speichert, gelesen, dass die Standard Sessionverwaltungin PHP normalerweise langsamer ist als die Verwaltung in einer Datenbank ("I/O is usually slower than database queries." siehe: https://www.phplinkdirectory.com/forum/showthread.php?t=29203).
Aber auch Datenbanken sind ja als Dateien gespeichert. Das kann doch gar nicht schneller sein, oder?

Gruß,
Klaus
 
Natürlich sind Datenbanken auch Dateien, aber Datenbanken verwenden den RAM als Cache für oft benötigte Informationen.
 
Und wo führt der Nutzer einen Beweis auf, dass dem wirklich so ist?
Ich kann auch viele Thesen aufstellen.

Nebenbei bemerkt: wenn das Script den MySQL-Datensatz mit der Session nicht locked, während diese aktiv ist (was das file backend macht), können race conditions bei gleichzeitigen Zugriffen stehen.
 
danke für eure Antworten. Wieder etwas Neues dazugelernt:).
Die Memory Tabelle kannte ich noch nicht. Das wäre ja eine sehr gute Lösung (bin mir nur nicht sicher, ob die nicht bei manchen Hostern eventuell sehr beschränkt ist in der Größe? Wobei sie so arg groß ja nicht werden sollte). Ich habe allerdings schon auch Daten, die ich dauerhaft aufheben will (z.B. letzte Aktivität). Allerdings könnte ich die dauerhaften Daten ja beim Ausloggen oder bei aktiv werden des Carbage Collectors in einer dauerhaften Tabelle speichern (wenn statistische Daten mal verloren gehen, ist das ja kein Beinbruch).

@ice-breaker:
deswegen frage ich ja, weil schreiben kann er ja viel;). Geht mir in diesem Fall auch nicht nur darum, ob es sich lohnt, das Mod zu kaufen, sondern vor allem, ob es sich lohnt, bei selbstprogrammierten Projekten einen eigenen Session Handler zu schreiben. Race conditions sind zwar möglich, aber bei Session Daten sehe ich da jetzt eigentlich kein Problem, oder übersehe ich etwas?


Gruß,
Klaus
 
klausschreiber schrieb:
Race conditions sind zwar möglich, aber bei Session Daten sehe ich da jetzt eigentlich kein Problem, oder übersehe ich etwas?
Zum Vergrößern anklicken....
Naja, wenn du z.B. n Shop programmierst und hast n Besucher, der per Tabbed-Browsing einkauft (was wohl an Gesichts der heutigen Browser 99,9% ausmacht), kann es passieren, dass wenn zwei Requests gleichzeitig am Warenkorb werkeln wollen und der eben in der Session is, dass der Warenkorb danach korrumpiert is.

Könnte im Worst-Case den Kunden kosten, der dann woanders einkauft, wo die Webseite aus seiner Sicht ordentlich funktioniert.

Es kommt halt immer drauf an, was du in die Session reinschreibst.
 
also zur Zeit baue ich keinen Shop oder etwas Vergleichbares.
Aber trotzdem mal zu deinem Beispiel. Kann es wirklich in diesem Fall zu einer race condition kommen, ohne, dass der Server überlastet ist oder der Kunde es darauf anlegt? Selbst wenn er recht schnell voran geht und die Produkte nicht vorher nochmal anschauen muss, muss er doch immerhin den Tab wechseln und den "in den Einkaufswagen" Button suchen. Bis dahin sollte doch im Normalfall der vorherige Request schon längst verarbeitet worden sein, oder?

edit: Mir fällt grad auf, normale Seitenwechsel können ja auch dazu führen, dass Sessiondaten geändert werden. Aber auch dann sollte es doch im Normalfall zu keiner unbeabsichtigten race condition kommen, oder?
 
klausschreiber schrieb:
Aber auch dann sollte es doch im Normalfall zu keiner unbeabsichtigten race condition kommen, oder?
Zum Vergrößern anklicken....
Race Conditions sind immer unbeabsichtigt ;) :mrgreen:

Auch, wenn der Benutzer 2 Sekunden braucht, um die Tabs anzuklicken, so kannst du niemals garantieren, dass die Requests nicht so gleichzeitig bei dir reinkommen, dass grade in dem Moment beide PHP-Instanzen auf dieselbe Datenbank-Zeile zugreifen.

Wenn du mit der Session arbeiten willst, musst du sie einmal lesen (SELECT), dann was machen und sie schließlich wieder schreiben (UPDATE).

Wenn die Reihenfolge jetzt aber nicht SELECT[sub]1[/sub], UPDATE[sub]1[/sub], SELECT[sub]2[/sub], UPDATE[sub]2[/sub] is, sondern SELECT[sub]1[/sub], SELECT[sub]2[/sub], UPDATE[sub]1[/sub], UPDATE[sub]2[/sub], dann is der Update des ersten Threads futsch, da der zweite Thread diese Daten niemals zu Gesicht bekommen hat, sondern sie einfach nur überschrieben hat.
 
klausschreiber schrieb:
deswegen frage ich ja, weil schreiben kann er ja viel;). Geht mir in diesem Fall auch nicht nur darum, ob es sich lohnt, das Mod zu kaufen, sondern vor allem, ob es sich lohnt, bei selbstprogrammierten Projekten einen eigenen Session Handler zu schreiben.
Zum Vergrößern anklicken....
hast du Performance-Probleme mit Sessions in Dateien? Wenn nein, dann bleib dabei.
Läuft deine Anwendung auf einem Cluster an Servern und der Nutzer kann mit jedem Request an einem anderen Server herauskommen (stateless Loadbalancer)? Wenn nein, dann bleib bei dabei.
Warum sollte man versuchen Probleme zu lösen, die man nicht hat und ziemlich sicher auch nicht haben wird? In jeder Datenbank, die ich gesehen habe, steckten viel größere Fehler als ein Db-SessionSaveHandler Wett machen kann.

klausschreiber schrieb:
Aber trotzdem mal zu deinem Beispiel. Kann es wirklich in diesem Fall zu einer race condition kommen, ohne, dass der Server überlastet ist oder der Kunde es darauf anlegt?
Zum Vergrößern anklicken....
Tabbed browsing und ajax, da ist es dann nicht mehr so unrealistisch, dass sich 2 Requests überschneiden ;)
 
Race Conditions können doch genau so leicht beim normalen Session-Handler auftreten?
Wenn man im Code zu Beginn einen Wert ausliest, damit arbeitet und dann am Ende einen neuen abspeichert ist es doch ganz egal ob dieser nun mittels dem normalen Session-Handler bearbeitet wird oder von einem eigenen, per DB gesteuerten. :-?
 
Also wenn man das ganze als reines gedankenspiel durchgehen will dann kannst du deine gesamte Seite (mit Session fetching und update) in eine Transaction wickeln, damit sollten race conditions zumindest aufspuerbar werden (transaction fail on update).
Aber wie gesagt der einzige Grund wieso man so etwas machen sollte is ein stateless load balancer, und selbst da wuerde ich memcached mit entry locking vorziehen, denn da muss man nicht extra noch den ganzen Query parsing, execution plan, ... kram in kauf nehmen:
PHP: 
while(cache->add("lock:session".sessId, "1", time() + 10)){} // spin lock
$session = cache->get("session".sessId);
// Whatever you want
$cache->set("session".sessId, $session);
$cache->delete("lock:session".sessId);
(Never ever use this code, es benutzt Spin locks die teuer werden...)
Damit sollte man ein verteiltes Session management hinbekommen, aber es sollte einiges brauchen bis man wirklich auf Stateless loadbalancer umstellt, und bei statefull loadbalancern kann man immer noch mit file sessions arbeiten ^^
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben