nicht angemeldet
Performance: Datei oder Session
Hallo,
ich habe eine stark frequentiertes Forum am Laufen, mit vielleicht 1000 Zugriffen/Minute zu Spitzenzeiten am Tag. Durch die hohe Zugriffszahl der User geht der Server ziemlich ans Limit (Core2 Quad 2.4GHz bei ~80% Dauerauslastung und 4GB RAM) und darunter leidet der Seitenaufbau. Habe schon nginx gegen den Apachen getauscht, hat mir auch etwas Luft verschafft, aber eben noch nicht genug. Das Forum ist optimiert (PHP/MySQL), keine Notices/Warnings etc, und die Queries sind alle optimal. Leider bekomme ich memcache auf dem Server nicht zum laufen (Kernel ungeeignet), und bevor ich den Server wechsel, möchte ich mich erst einmal nach Alternativen umschauen. Daher habe ich mir überlegt fast statische Elemente (also Teile einer Seite mit DB Daten, welche sich fast nie ändern) auszulagern. Nun weiß ich allerdings nicht, ob es besser wäre den Part in eine Datei auszulagern und diese bei jedem Zugriff einzulesen, oder den Part in die Session des Users zu schreiben.
Was ist schneller? Eine Anfrage an die MySQL DB oder das auslesen einer Datei? Ich finde dazu keine definitiven Aussagen bei Google, und eigene Tests haben mich nur noch mehr verunsichert. Mal liegt die Abfrage vorn, dann mal wieder die Datei.
Hat wer von euch Erfahrung damit gemacht, und kann mir einen Rat geben?
MFG
Lars
-
Moin!
Nun weiß ich allerdings nicht, ob es besser wäre den Part in eine Datei auszulagern und diese bei jedem Zugriff einzulesen, oder den Part in die Session des Users zu schreiben.
Hast du mal recherchiert, wie PHP Sessions realisiert? Überraschung: PHP schreibt die Daten in eine Datei!
Dein "oder" ist also keine wirkliche Alternative, weil "schreibe ich's manuell in eine Datei oder schreibe ich's mit Sessions in eine Datei" keinen wirklichen Unterschied in der Geschwindigkeit macht... außer in einem relativ wichtigen Detail: Session-Nutzung nutzt intensiv Datei-Locks, d.h. dein einer User wird seine eigene Session-Datei niemals parallel in PHP-Skriptaufrufen nur "lesen" können, denn Session-Daten werden grundsätzlich am Skriptende (oder wenn man das früher veranlasst) auch wieder weggeschrieben.
Insofern sind Sessions durchaus performancebelastender, andererseits ist das Caching in eine Datei halt auch nicht zum Nulltarif zu bekommen. Und obendrein wäre die Frage, ob deine Probleme sich durch das Caching verringern lassen, denn das übliche Problem bei intensiv die DB nutzenden Seiten ist eigentlich eher, dass parallel ablaufende Datenbankabfragen schreiben und lesen und sich deshalb gegenseitig mit Locks aussperren.
Die simpelste Methode wäre daher, dieses Locking zunächst bestmöglich wegzukonfigurieren (Welche Storage-Engine benutzt du? MyISAM ist ganz schlecht, InnoDB definitiv ratsam.), als nächstes dann den MySQL-Query-Cache bestmöglich auszunutzen (Hat der genug RAM verfügbar für diese ganzen "unveränderlichen" Abfragen?), und erst dann über ein geeignetes Caching nachzudenken.
Was ist schneller? Eine Anfrage an die MySQL DB oder das auslesen einer Datei? Ich finde dazu keine definitiven Aussagen bei Google, und eigene Tests haben mich nur noch mehr verunsichert. Mal liegt die Abfrage vorn, dann mal wieder die Datei.
Dann ist die Antwort offensichtlich ein "hängt von diversen Randfaktoren ab und ist nicht allgemein aussagbar", sprich: Deine Tests haben dir gesagt, dass dein derzeitiger Ansatz zur Optimierung im Moment keinen wirklichen Vorteil liefert.
- Sven Rautenberg
-
Moin Sven,
man könnte die Session- bzw. Cache-Dateien in einem tmpfs-Mount lagern. Das liegt auch ausschließlich im RAM (bzw. Swap, wenn zu wenig RAM da ist). Das wäre dann, je nach Implementation, vergleichbar mit memcached.
[…] (Welche Storage-Engine benutzt du? MyISAM ist ganz schlecht, InnoDB definitiv ratsam.)
InnoDB halte ich für problematisch. Im Prinzip würde ich dir zustimmen, aber wenn sich im letzten Jahr oder so nicht grundlegend etwas geändert hat, gibt es keine Repair-Tools für InnoDB.
Ich hatte zwischendurch eine Anwendung, die exzessiv Transaktionen nutzte, mit MySQL als DBMS und InnoDB als Storage Engine. Irgendwann ist mir die Datenbank um die Ohren geflogen, die Datei war beschädigt. Kann schonmal vorkommen, was mir allerdings das Genick gebrochen hat: ich konnte die Datei nicht reparieren. Es gab einfach keine Möglichkeit und keine Tools, um an die Daten heran zu kommen. Mir blieb nichts anderes übrig, als ein Backup der letzten Nacht einzuspielen. Danach bin ich sehr schnell zu PostGreSQL gewechselt und bin da sehr zufrieden.
LG,
CK-
man könnte die Session- bzw. Cache-Dateien in einem tmpfs-Mount lagern. Das liegt auch ausschließlich im RAM (bzw. Swap, wenn zu wenig RAM da ist). Das wäre dann, je nach Implementation, vergleichbar mit memcached.
Das wäre eine Idee...
[…] (Welche Storage-Engine benutzt du? MyISAM ist ganz schlecht, InnoDB definitiv ratsam.)
Also ich nutze MyISAM, da ich meine das MyISAM flotter ist als Inno, v.a. wenn es um Datenbesände geht, die ständig verändert werden.
-
Moin Lars,
Also ich nutze MyISAM, da ich meine das MyISAM flotter ist als Inno, v.a. wenn es um Datenbesände geht, die ständig verändert werden.
Das hängt davon ab, wie deine Schreibzugriffe genau aussehen. So ist das zu pauschal.
LG,
CK -
Moin!
[…] (Welche Storage-Engine benutzt du? MyISAM ist ganz schlecht, InnoDB definitiv ratsam.)
Also ich nutze MyISAM, da ich meine das MyISAM flotter ist als Inno, v.a. wenn es um Datenbesände geht, die ständig verändert werden.
Da würde ich pauschal erstmal widersprechen wollen. MyISAM muss die gesamte Tabelle für Lesezugriffe sperren, wenn geschrieben werden soll. InnoDB sperrt nur den jeweiligen Datensatz, der geschrieben wird, Lesezugriffe auf den Rest der Daten sind parallel möglich.
- Sven Rautenberg
-
Hello,
Also ich nutze MyISAM, da ich meine das MyISAM flotter ist als Inno, v.a. wenn es um Datenbesände geht, die ständig verändert werden.
Wie flott MyISAM ist, hängt u.a. auch von der Einrichtung des DB-Serves ein. Je nachdem, wieviel Speicher er wofür nutzen darf, kann er einschlafen oder abflitzen wie Schmidts Katze :-)
Und dann ist es wichtig, wieviele Indexe bei jedem Schreibvorgang erneuert werden müssen. Das ist das Thema "Optimierung" bei den Tabellen. Es ist kontraproduktiv, auf jede nur erdenkliche Spalte einen Index zu legen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
Hast du mal recherchiert, wie PHP Sessions realisiert? Überraschung: PHP schreibt die Daten in eine Datei!
Ja gut, das ist mir schon klar. Nur habe ich nichts gefunden, ob dieser Schreibvorgang flotter vonstatten geht, als ein fwrite. Weiß ja nicht wie das intern gehandabt wird.
Insofern sind Sessions durchaus performancebelastender, andererseits ist das Caching in eine Datei halt auch nicht zum Nulltarif zu bekommen. Und obendrein wäre die Frage, ob deine Probleme sich durch das Caching verringern lassen
Naja deswegen der Post hier. Es ist halt nur die Frage ob eine Datei für alle User, oder ob ich die $_SESSION nutzen soll. Erstelle ich die Datei selber, wird der Query/die Queries halt nur einmal ausgeführt. Bei den Sessions halt für jeden User. Und da Frage ich mich nun, welches von der Performance besser wäre. Also ob PHP die Session Datei wesentlich schneller lesen kann, als eine manuell angelegte.
-
-
Habe schon nginx gegen den Apachen getauscht, hat mir auch etwas Luft verschafft, aber eben noch nicht genug.
Ich ging bisher davon aus, dass nginx oder lighttpd wesentlich schneller als Apache wären :)
-
Ich ging bisher davon aus, dass nginx oder lighttpd wesentlich schneller als Apache wären :)
Hehe, war nen Dreher ;) Also nginx läuft
-