Session-Verwaltung optimieren

Wer auf seiner Seite einen Login hat, verwaltet die Autentifizierung der User üblicherweise per Cookies oder Sessions. Letzteres ist dabei praktikabler, da Cookies deaktiviert werden können und Sessions dann immernoch über GET-Parameter an der URL die Autentifizierung gewährleisten. Wenn aber Sessions genutzt werden, werden die Daten der Session auch auf dem Server gespeichert. Wer hier nicht aufpasst, kann sich schnell seinen Server vollfrummeln. Deshalb gibt es in diesem Beitrag einige Tipps zur effektiven Verwaltung von Sessions.

Session nur starten, wenn es nötig ist
Wenn es nicht nötig ist eine Session zu starten, sollte man es auch nicht tun. Das bedeutet, wenn jemand Hilfeseiten oder das Impressum ansieht und nicht gleichzeitig auf dieser Seite sein Benutzername angezeigt werden soll, braucht man auch keine Session starten. Denn jedes session_start() legt eine 0-Byte-Datei an, auch wenn man keine Session-Variable mit Inhalt füllt. Das können schnell sehr viele solcher Dateien sein – unnötiger Ballast fürs Dateisystem. Da jedoch der User meist irgendwo seinen Nutzernamen sehen soll, um ihm mitzuteilen, dass er noch eingeloggt ist, wird meist auf jeder Seite die Session per session_start() gestartet. Das ist also noch nicht ganz so tragisch …

Tragisch wird es erst, wenn…
In der php.ini kann per session.save_path das Verzeichnis gesetzt werden, in dem die Session-Dateien gespeichert werden sollen. Da dort ein absoluter Pfad angegeben werden muss, hat man völlige Freiheit, wo man das tut. Standardmäßig ist /tmp dort angegeben. Eine Session hat ja aber eine bestimmte Laufzeit (session.cookie_lifetime und session.gc_maxlifetime). Nach dieser Laufzeit soll die Session als abgelaufen betrachtet werden (Standard sind 24 Minuten).
Und jetzt kommt das Problematische: PHP ermittelt bei jeder Anfrage eine Wahrscheinlichkeit, jetzt eine Garbage Collection durchzuführen (einstellbar mit session.gc_probability und session.gc_divisor). Wenn die Garbage Collection durchgeführt wird, werden alle Session-Dateien, die älter als session.gc_maxlifetime sind, gelöscht. Doof nur, wenn PHP keine Rechte hat Dateien aus /tmp zu löschen. Denn dann läuft dieses Verzeichnis in aller Seelenruhe voll und wenn man Pech hat, merkt man es erst, wenn man mal eine aufwändige Operation mit vielen temporären Daten hat. Dann ist die Platte einfach voll und Feierabend. Mir ist das ganze mal mit einem OPTIMIZE TABLE passiert. Je nach Tabellengröße können dabei viele temporäre Dateien entstehen, die eventuell auch nach /tmp geschrieben werden. Aber wenn voll, dann voll – Tabelle gecrasht und musste repariert werden.

Also lieber ein eigenes Verzeichnis für die Sessions anlegen, wo sich PHP auch von den Rechten her austoben darf. Dieses sollte aber nicht öffentlich zugänglich sein und noch viel weniger darf ein DirectoryListing möglich sein, denn sonst können Sessions gehijacked werden.

Wahrscheinlichkeit der Garbage Collection
Je nach Besucheranzahl sollte die Wahrscheinlichkeit, dass die Garbage Collection durchgeführt wird, nicht zu hoch gewählt werden. Standardmäßig steht die auf 0,1% (session.gc_probability = 1 und session.gc_divisor = 1000). Wer täglich mehrere Tausend Zugriffe hat, darf das aber ruhig herabsetzen. session.gc_divisor auf 10000 ist ein guter wert für große Seiten. Oder man kümmert sich einfach selbst um die Garbage Collection, indem man in der Zeit, wenn die wenigsten Besucher kommen per Cronjob das Session-Verzeichnis durchläuft und das Alter der Dateien überprüft. Was zu alt ist, wird gelöscht (huch, das klingt jetzt ungewollt politisch – wirklich nicht beabsichtigt).

Also wer mit Sessions arbeitet, sollte diese Tipps beherzigen. Wenn ihr noch weitere Tipps habt, freue ich mich über eure Kommentare.

Jan hat 152 Beiträge geschrieben

25 Kommentare zu “Session-Verwaltung optimieren

  1. Dirk sagt:

    Alternative: Sessions in der Datenbank verwalten. PHP lässt das recht einfach zu und beseitigt zudem noch eine Handvoll anderer Probleme.

  2. Jan sagt:

    @Dirk: Welche Probleme behebt denn die Speicherung der Sessions in der DB? Meist hat die DB doch eigentlich schon genug zu tun.

  3. Jan sagt:

    @GhostGambler: Dein Tipp ist echt super! Aber wieso $_REQUEST[session_id()]? Damit funktioniert es bei mir nicht, weil ja die ID nicht der Array-Index von $_COOKIE bzw. $_GET wird sondern ‚PHPSESSID‘.

    Oder hab ich was falsch verstanden / konfiguriert?

    Hab mir phpinfo() angesehen und da ist in $_COOKIE[‚PHPSESSID‘] meine Session-ID, der von Dir besagte Eintrag existiert nicht.

    PS: Habe Deinen Fehler glaube gefunden: Du meinst session_name() statt session_id(), richtig?
    Wäre also folgender Code:
    if (!empty($_REQUEST[session_name()])) {   session_start(); }

  4. Jan sagt:

    Noch kurz ne andere Frage an Dich, Ghostgambler:
    Ich habe bisher die Session immer per
    session_destroy()
    zerstört. Dabei wird aber komischerweise $_COOKIE[‚PHPSESSID‘] nicht gelöscht. Ist das normal? Habe es jetzt „manuell“ gelöscht mit setcookie und einem Expire-Datum in der Vergagenheit.

    PS: Erledigt.

  5. GhostGambler sagt:

    Ja, session_name() natürlich…

    Das Cookie stirbt doch eh am Ende der Session, das musst doch nicht löschen.
    Deutlich wichtiger ist da zum Beispiel beim Login session_regenerate_id(true) auszuführen – siehe dem verlinkten PDF für eine Erklärung, ansonsten halt einfach machen.

    Cookies in der Datenbank benötigen keine Schreibrechte auf das File-System mehr. Man kommt leicht an die Session-Daten ran. Man kann die User-Id separat speichern und so Sessions von einem Benutzer kicken ohne alle Dateien „aufmachen“ zu müssen (DEL FROM sessions WHERE uid=$id).
    Und zu guter letzt: Wenn der Hoster so unglaublich dummblöd ist und man seine eigenen Sessions nicht mehr löschen kann, funktioniert der Garbage-Collector auf der Datenbank wenigstens ohne Access-Warning… (ja derartige (bekannte) Hoster gibt es, einen Namen nenne ich jetzt mal freundlicherweise nicht…)

  6. Schöner Artikel. Danke.

    Ein paar weitere Anmerkungen/persönliche Erfahrungen:

    1. Sessiondaten im Filesystem ablegen funktioniert zuverlässig nur so lange, wie die Applikation auf lediglich einem Server läuft, ansonsten müssen die Session Daten in MySQL, Mysqlite, Memcache oder anderen Persistenzschicht gehalten werden (NFS o.ä. ist erfahrungsgemäß zu lahm/unzuverlässig dafür).

    2.Den Session Parameter per GET zu übergeben, falls der User keine Cookies unterstützt ist imo keine besonders gute Idee (wenn man es einfach nur generell anstellt), außer man sorgt dafür, dass man dieses Verhalten für Bots deaktiviert. Ansonsten werden URLs unendlich oft indiziert, da der Bot bei jedem Aufruf der Seite eine neue Session ID bekommt.

  7. Sören sagt:

    @Andreas Stephan

    Zusatz zu deinem 2. Punkt:

    Außerdem ist das SESSION-Hijacking viel einfach, da die SESSION-ID wesentlich präsenter ist. Außerdem kopieren unerfahrene Benutzer gerne mal Links mit SESSION-IDs in Foren, wodurch Zugriff auf deren Account erlangt werden kann, sofern die Session nicht über HTTP_REMOTE_ADR und HTTP_USER_AGENT zusätzlich geschützt wird.

  8. Marcel sagt:

    >>>Das bedeutet, wenn jemand Hilfeseiten oder das Impressum ansieht und nicht gleichzeitig auf dieser Seite sein Benutzername angezeigt werden soll, braucht man auch keine Session starten. Denn jedes session_start() legt eine 0-Byte-Datei an, auch wenn man keine Session-Variable mit Inhalt füllt. Das können schnell sehr viele solcher Dateien sein – unnötiger Ballast fürs Dateisystem. Da jedoch der User meist irgendwo seinen Nutzernamen sehen soll, um ihm mitzuteilen, dass er noch eingeloggt ist, wird meist auf jeder Seite die Session per session_start() gestartet.<<>>Speicherung im File System<<<
    Darauf hat man aber nur Einfluß wenn man ein eigenen (Root) Server hat oder hal Lokal das laufen läßt. Wer sich ein einfaches Hostingpaket mietet, kann dies eh nicht beeinflussen und die meisten Provider werden dem Ordner auch mit den nötigen Rechten versehen, damit der Sessionmüll auch wieder gelöscht wird.

    @andreas stephan
    Das mit der Session in der Url ist schon richtig, aber ganz darauf verzichten würde ich nicht bei allen Anwendungen (zB. Shops). Man muß halt schauen wie man die Sid anhängt (nicht PHP überlassen) und das ganze dann dem Login und Cookie Status nach auswählen.

    @sören
    Da sollte man halt vor dem Aufruf von sensiblen Daten schauen, ob sich was am User verändert hat und notfalls nochmal das Passwort vom User verlangen.

  9. Harry sagt:

    > @sören
    > Da sollte man halt vor dem Aufruf von sensiblen
    > Daten schauen, ob sich was am User verändert hat
    > und notfalls nochmal das Passwort vom User
    > verlangen.

    Mhh und die ganz „schlauen“ machen das wenn sich die User-IP ändert was bei Smartphones einfach normal ist und mobile User damit in den Wahnsinn treibt

    Session_IDs per URL zu übergeben ist einfach nur Schwachsinn weil sie mit dem Referer ins Access-log jeder verlinkten Fremdseite mitgeschireben werden

    Sessions ind die Datenbank legen ist auch ganz selten eine gute Idee weil die ohnehin genug zu tun hat und vor allem man damit auf einer gut besuchten Seite die Kiste unweigerlich in die Knie zwingt wenn permanent in die gleiche Tabelle geschreiben und gelesen wird

    Wenn man wirklich Perfromance braucht:

    * session.gc_probability = 0
    * Cleanup alle 5-10 Minuten per Cronjob
    * Damit kommt kein User-Request zum Handkuss
    * Genug RAM in die Kiste stecken
    * tmpfs für session.save_path benutzen

    Wer mal 2 Mio Requests auf eine dynamische Seite innerhalb von 45 Minuten hatte weiss warum, Gande dir Gott du schreibst deine Sessions in so einem Case in eine Datenbank – Es reicht EIN Update-Query pro Request und MySQL geht dir auf eine CPU-Last die nicht mehr schön ist, ohne die DB-Updates langweilt sich MySQL bei genug Query-Cache

  10. Harry sagt:

    Warum bitte sollten sie nicht nach 5-10 Minuten nicht eingeloggt sein? Hab ich was von „Alle Dateien im Sessiondir gesagt? Nö! Ich sagte „Cleanup“

    Unix-Basics!
    man find
    man crontab

    */10 * * * * apache nice -n 19 ionice -c 3 find /var/sessiondata -type f -mmin +30 -delete

    So und jetzt hast du a) nur alle 10 Minuten die IO-Last die dann auch wirkouch aufräumt, nicht im Apache-Kontext läuft und vor allem mit niedrgister UO/CPU-Priorität läuft und damit nicht mit dem Apache um ressourcen streitet

    Bei Konfigurationen die das Wort „probability“ in sich tragen habe ich sowieso schon gefressen weilich betreibe Server und keine Gambling-Maschine

  11. Ulrich sagt:

    Ein paar Anmerkungen, die mir dazu einfallen:
    1. Wenn der Server damit überlastet ist Apache am Laufen zu haben und nebenher ein paar temporäre Dateien zu löschen (die im Fall hier auch noch vollständig im RAM liegen), möchte man vielleicht die Hardware skalieren.
    2. Ein Streitthema ist vermutlich auch, ob Apache für Produktions-Umgebung noch erste Wahl ist. Da ich keine Lösung präferiere, hier Namen weiterer Software mit denen Interessierte bei Google suchen können: Lighttpd und nginx. Natürlich findet man auch diverse Vor-/Nachteile- und Vergleichswebseiten dazu.
    3. Die Lösung mit der Ramdisk ist super. Solange man nur einen Server hat.
    4. Dass man die Sessions nicht „mal eben“ in die Datenbank legen kann und diese eine nicht zu verachtende Last darstellen, wofür man im Ernstfall vielleicht die Datenbankserver-Hardware skalieren muss, sollte klar sein. Dass MySQL dabei direkt in die Knie geht, würde ich allerdings nicht unterstützen. MyISAM sperrt bei Update-Queries die gesamte Tabelle, InnoDB allerdings nicht, sondern nur den jeweiligen Datensatz. Außerdem, wie auch schon implizit festgestellt wurde, ändert sich an Session-Daten durchschnittlich nicht so regelmäßig etwas.
    5. Es gibt übrigens diverse fertige Lösungen für die Session-Problematik, z. B. SCD von Zend (http://files.zend.com/help/Zend-Platform/session_clustering.htm). Wer die DB-Lösung bevorzugt und dabei den Overhead vom Query-Parser umgehen möchte, kann auch die NoSQL-Schnittstelle nutzen (das wird z. B. hier untersucht http://schlueters.de/blog/archives/164-High-Performance-PHP-Session-Storage-on-Scale.html).

  12. Harry sagt:

    > Wenn der Server damit überlastet ist Apache am Laufen
    > zu haben und nebenher ein paar temporäre Dateien zu löschen
    > (die im Fall hier auch noch vollständig im RAM liegen), möchte
    > man vielleicht die Hardware skalieren

    Kind ich spreche von High-Traffic-Seiten
    Da entstehen schnell mal einige tausend Session-Dateien

    Kannst gerne mal auf der Shell „rm -f *“ in einem Ordner
    mit etlichen tausend Session-Files probieren und Zeit
    zählen, das will man ganz sicher nicht ZUFÄLLIG in
    einem User-Request

    Das dauert auch in der RAM-Disk

    Aber warte mal bis du unter eine DDoS-Attacke stehst die dir
    schneller Session-Files anlegt als du Pfeil rauf + Enter
    drücken kannst, danach siehst du vieles anders

    Das skalierst du nicht mit Hardware, niemals!

    Wenn do schon einen Dual E5640 mit jeweils 32 GB RAM
    stehen hast und dir Angriffsspitzen teilweise den Cisco
    Router druch zu viele Verbindungen dicht machen und dir
    die Requests mit 100 MBit eingehendem Traffic um die
    Ohren fliegen bist du dankbar für JEDE Micro-Optimization
    um die Load zu drücken und alles was dir bei solchen
    Last-Szenarien LATENZEN rein bringt wird zu einem Problem

    LATENZEN kannst du nur BEDINGT mit mehr Hardware erschlagen

    > Ein Streitthema ist vermutlich auch, ob Apache für Produktions-Umgebung
    > noch erste Wahl ist

    Ist er und wenns drauf ankommt steht für das Abfangen von
    statischem Content (Grafiken, JS, CSS) eine Apache Trafficserver
    als transparenter Reverse-Proxy davor

    > Die Lösung mit der Ramdisk ist super. Solange man nur einen Server hat

    Sie hlft vor allem dass man nur einen braucht

    > Dass man die Sessions nicht „mal eben“ in die Datenbank legen kann und diese
    > eine nicht zu verachtende Last darstellen, wofür man im Ernstfall vielleicht
    > die Datenbankserver-Hardware skalieren muss, sollte klar sein.

    Ab einem gewissen Traffic musst du LATENZEN wegbekommen und
    da ist eine Datenbank für Sessions alles andere als hilfreich

    > Dass MySQL dabei direkt in die Knie geht, würde ich allerdings nicht
    > unterstützen.

    Direkt nicht aber indirekt weil es ohne den Session-Kram genug zu tun hat

    > MyISAM sperrt bei Update-Queries die gesamte Tabelle, InnoDB allerdings nicht

    Nur dumm dass der Vergleich MyISAM / InnoDB im Worst-Case einem Vergleich
    zwei völlig verschiedener RDBMS gleichkommt

    > Außerdem, wie auch schon implizit festgestellt wurde, ändert sich an Session-Daten
    > durchschnittlich nicht so regelmäßig etwas

    Das ist VÖLLIGER BLÖDSINN

    * Es ändert sich zumindest mit jedem Request der Timestamp
    * Sonst würde deine Session ungültig
    * Ergo: Jeder Request ein DB-Schreibzugriff

    Datenbankserver skalieren aber allgemein bei lesendem Abfragen besser
    als bei schreibenden

    > Es gibt übrigens diverse fertige Lösungen für die Session-Problematik, z. B.
    > SCD von Zend (http://files.zend.com/help/Zend-Platform/session_clustering.htm).
    > Wer die DB-Lösung bevorzugt und dabei den Overhead vom Query-Parser umgehen möchte,
    > kann auch die NoSQL-Schnittstelle nutzen

    Man kann natürlich noch einen Layer an Komplexität rein bringen anstatt
    das Ganze von Default-Einstellungen die meistens gut genug
    sind auf eine ordentliche Config wie von mir beschreiben umzustellen

    Ob das so sehr sinnvoll ist möchte ich bezweifeln ausser in ganz
    wenigen Ausnahmefällen

    Vor allem nenne mir einen Grund warum man mit den durchschnittlichen
    Defaults leben soll anstatt von Grund auf seinen Server zu optimieren

    Mit „Mehr Hardware“ kann man dann immer noch daher kommen
    Aber auch das „Mehr Hardware“ wird wenn ALLES optimiert ist
    noch besser genutzt

  13. Ulrich sagt:

    • DDoS-Attacken wehrt man nicht mit dem Webserver oder dem Dateisystem als „Handwerkszeug“ ab, sondern auf der Systemebene wo das Problem entsteht, der Netzwerk-Schicht. Siehe z. B. http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5879/ps6264/ps5888/prod_white_paper0900aecd8011e927.html Deine „Lösung“ kriegt man schnell kaputt, denn eine DDoS-Attacke skaliert besser als jede Konfiguration des Servers von dir. Man behandelt bei Problemen besser die Wurzel und nicht die Symptome.
    • Offensichtlich sehen das Apache/Lighttpd/Nginx-Thema ein paar Systementscheider anders als du, siehe z. B. http://en.wikipedia.org/wiki/Lighttpd#Usage
    • Das Ziel in der heutigen Welt ist nicht mehr *ein* Server. Das ist aufgrund der Latenzen des Internets Quatsch, siehe z. B. http://blogs.msdn.com/b/sqlazure/archive/2010/07/16/10039137.aspx Das ist auch aufgrund von Redundanz/Replikation/Failover Quatsch. (Dafür muss ich wohl keinen Link angeben.)
    • Dass MyISAM und InnoDB grundverschieden sind, ist gerade das was ich gesagt habe?
    • Den Timestamp einer Session muss man nicht sekündlich aktualisieren, nur weil sie sekündlich verwendet wird.
    • Deine „Konfig“ ist ein Cronjob, der sich genau für ein-Server-Lösungen eignet. Ein-Server-Lösungen sind aber wie gesagt obsolet, man lese http://static.usenix.org/events/es99/full_papers/nessett/nessett.pdf oder http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/mapreduce-osdi04.pdf oder allgemeiner http://code.google.com/intl/de/edu/parallel/index.html oder oder oder. Die Zukunft gehört den verteilten Systemen. Das ist nicht mal eine neuere Entwicklung. Ich verstehe gar nicht wie du darauf kommst, dass eine Ein-Server-Lösung irgendwie Ziel sein könnte? Single-point-of-failure. Thema durch. Oder nicht?
    • Dass man die Default-Einstellungen nicht anfassen sollte, habe ich nicht gesagt.

    Verstehe mich nicht falsch, ich finde deine Lösung nicht schlecht, solange man mit einem Server auskommt. Da kann man bestimmt eine Menge so konfigurieren, dass es super läuft. Aber solche „kleinen“ Systeme sind nicht worüber ich spreche.
    Entweder man macht etwas Großes, dann plant man es verteilt (und da hilft dein Vorgehen nun mal einfach nicht), oder man macht etwas Kleines, da kann man im Notfall einfach stärkere Hardware kaufen, und dann auch praktisch konfigurieren wie man möchte. Aktuelle Hardware ist gut genug, um fast jede schlechte Konfiguration zu stemmen.

  14. Harry sagt:

    > DDoS-Attacken wehrt man nicht mit dem Webserver oder dem Dateisystem als „Handwerkszeug“ ab

    Das brauchst du mir nicht zu erzählen
    Ich mach den Job schon etwas länger

    Aber Fakt ist dass für die trotz Abwehr durchkommenden Requests
    jede Optimierung am backend-Server letztlich hilft

    > Offensichtlich sehen das Apache/Lighttpd/Nginx-Thema ein paar Systementscheider anders als du

    Lighttpd/Nginx ist bei hoher last verglichen
    mit Apache TRAFFICSERVER Kinderspielzeug

    > Das Ziel in der heutigen Welt ist nicht mehr *ein* Server. Das ist aufgrund der
    > Latenzen des Internets Quatsch, auch aufgrund von Redundanz/Replikation/Failover Quatsch

    In deiner kleinen Welt macht man Failover zu Fuss
    Da wo ich arbeite kümmert sich um Failover/Redundanz
    http://www.vmware.com/at/products/datacenter-virtualization/vsphere/high-availability/overview.html

    > Dass MyISAM und InnoDB grundverschieden sind, ist gerade das was ich gesagt habe?

    Ja und – Trotzdem ist es Quatsch alles auf InnoDB umzustellen
    und kischen von verschidenen tabellentypen aus vielen Gründen
    unschön

    > Den Timestamp einer Session muss man nicht sekündlich aktualisieren, nur weil sie
    > sekündlich verwendet wird

    Aha und wie erkkenst du Schlauberger dann ob sie abgelaufen ist?

    > Deine „Konfig“ ist ein Cronjob, der sich genau für ein-Server-Lösungen eignet.
    > Ein-Server-Lösungen sind aber wie gesagt obsolet

    Bruhaha ja klar

    > Die Zukunft gehört den verteilten Systemen

    Die Zukunft gehört Virtualiserungsclustern und sonst gar nichts

    > Das ist nicht mal eine neuere Entwicklung. Ich verstehe gar nicht
    > wie du darauf kommst, dass eine Ein-Server-Lösung irgendwie Ziel
    > sein könnte? Single-point-of-failure. Thema durch. Oder nicht?

    Wach mal auf

    Server auf physischem Blech installieren und sich dann fragen
    wie man Failover sauber hinbekommt ist lächerlich

    Wenn ich heute einen neuen phyischen Server in den Schrank stecke
    suche ich mir per Klick unterberechungsfrei aus welcher Server
    da drauf wandert und mit etwas merh Budget kümmert sich VMware DRS
    automatisch darum die virtuellen Server entsrpechend der aktuellen
    Last zu verteilen, das ganze mit automatischer Redundanz wenn ein
    Host ausfällt

    > Verstehe mich nicht falsch, ich finde deine Lösung nicht schlecht,
    > solange man mit einem Server auskommt. Da kann man bestimmt eine Menge
    > so konfigurieren, dass es super läuft.

    Du solltest mal anfangen Server und Hadware zu abstrahieren

    > Aber solche „kleinen“ Systeme sind nicht worüber ich spreche

    Bruhaha keline Systme Bruhaha

    > Entweder man macht etwas Großes, dann plant man es verteilt

    Nö, man kümmert sich um ordentliceh Redundanz und Hochverfügbarkeit
    weit unter dem Level des Betriebssystems anstatt selbiges
    5 mal aufzusetzen und dann Failover selbst zu konfigurieren

    Der Krempel wird nämlich letztlich nicht wirklich gut
    genug getestest während Läsungen wie VMware HA weniger
    Overhead verbrauchen und in weit grösseren Umgebungen
    getestest sind als sich 98% aller Admins vorstellen können

    > und da hilft dein Vorgehen nun mal einfach nicht

    Doch, du hast nur ekine Ahnung von meinem Vorgehen

    > oder man macht etwas Kleines, da kann man im Notfall einfach
    > stärkere Hardware kaufen, und dann auch praktisch konfigurieren
    > wie man möchte

    Und ich kaufe stärkere Hardware und schiebe den Server zu jeder
    Uhrezit im Vollbetrieb daruf

    > Aktuelle Hardware ist gut genug, um fast jede schlechte Konfiguration zu stemmen

    Schwachsinn, das gilt nur solange auf der Kiste nichts läuft

    Wir haben im Schnitt 0.011 Sekunden Generate-Times bei per CMS
    generierten Systemen, haben auf der Kiste ein par hundert Domains
    laufen und noch einige VMs für sonstige Dienste und isolierte Webserver

    Mit typischen Systemen wie Joomla/Wordpress fährst du keine 500 Installationen
    auf einem Host bei im Schniit 5-10% Auslastung, das funktioniert deswegen
    weil ich seit merh als 10 Jahren an Backend-Sofwtare, Libraries und allen
    Konfigurationen optimiere und das ganze für hunderte Kunden automatisiert
    verteilbar aufbaue

    Du kannst gerne mahen was du willst, ich habe mittlerweile genug
    Erfahrung mit allen Arten von Projekten in jeder Grösse und kenne
    aus Erfahrung jeden Flaschenhals im Gesamtkunstrukt, jeder einzelne
    davon kann dir bei unerwarteten lastspitzen den tag versauen oder
    du lernst daraus und schaffst JEDEN Flaschenhals in jeder Config
    aus dem Weg und feust dich am Ende wenn du Sptzen mit 1000 SQL-Abfragen
    pro Sekunde genauso unbeschadet überstehst als den Durchschnitt

  15. Ulrich sagt:

    Was meinst du denn was ein VM-Cluster ist? Ein verteiltes System. Darüber hast du nur bisher kein einziges Wort verloren. Ich kann nur von dem aus schließen was du schreibst.
    So oder so hilft aber ein abstrakter Server verteilt auf einem VM-Cluster auch nicht bei notwendiger geografisch verteilter Redundanz — und die wird sofort notwendig, wenn die Kundschaft z. B. gleich verteilt in Amerika und Russland sitzt. Man kann seine VM nun mal einfach nicht teilen und die eine Hälfte dort und die andere Hälfte da leben lassen (also kann man schon — das konstituiert ja gerade VM-Cluster — nur ist diese Art der Teilung nicht intelligent genug, um den spezifizierten Vorteil zu leisten, wenn der VMCluster nicht mehr geografisch lokal ist).
    Oder wie sorgst du dafür, dass ein abstrakter Server, bestückt mit z. B. Webserver und Datenbankserver, sowohl in Amerika sowie auch in Russland ohne die Latenz zwischen A nach R verwendet werden kann? Sprich beide Teile müssen autonom in der Lage sein Anfragen zu beantworten und gleichzeitig müssen sie ihre Daten aber natürlich auch ans jeweils andere Ende der Welt replizieren, damit sie dort verfügbar sind. Kann VMWare das? Diverse geografische Failovers sind klar kein Problem, aber zu einer parallel laufenden geografisch verteilten VM habe ich nichts gefunden.
    Ich kann mir auch nicht vorstellen, dass es dafür eine gute Lösung gibt — wenn es überhaupt eine gibt. Denn schließlich müsste die VM-Umgebung sowohl die Prozesse parallel an zwei Stellen laufen lassen, IPC darf aber nicht möglich sein, ansonsten holt man sich die Latenz rein, und die Datenbestände können nicht exklusiv gelockt werden, ansonsten dominiert auch dort die Latenz den Zugriff darauf. Die VM-Umgebung muss also auch intelligent genug sein gleichzeitige Zugriffe auf die Datenbasis zu koordinieren, dabei aber auch jeweils die Daten vom anderen Ende der Welt schon berücksichtigen, … das kriegt doch keine VM-Umgebung hin. Realtime und Konsistenz über 8000km ohne die Latenz der 8000km. Das kriegt man ja nicht mal ohne VM-Umgebung fehlerfrei hin.
    An der Stelle könnte man dann höchstens noch zwei VMs in zwei VM-Clustern laufen lassen, aber damit hat man dann alle Probleme von normalen verteilten Umgebungen wieder drin.

    Viel allgemeiner ist aber auch bei dem Thema nicht jeder der Meinung, dass Virtualisierung jetzt die Eierlegendewollmilchsau ist:
    http://www.zdnet.com/facebook-virtualisation-does-not-scale-4010021998/
    http://www.enterprisecioforum.com/en/blogs/michaelprocopio/cloud-computing-does-not-require-virtual

    Den Session-Zeitstempel lässt man zum Beispiel einfach nur alle 5 Minuten setzen. Bei den ganzen AJAX-Aufrufen und stundenlanger Lebenszeit von Sessions merkt man einen Threshold von 5 Minuten nicht.
    Dass man alles auf InnoDB umstellen soll habe ich nicht gesagt. Aber trotzdem ist gerade das kein Quatsch, wenn man sich schon an MySQL bindet. MyISAM ist nicht ACID-konform. MySQL mit MyISAM als storage engine ist als „richtiges“ DBMS damit praktisch nicht zu gebrauchen.

  16. Harry sagt:

    > Was meinst du denn was ein VM-Cluster ist?
    > Ein verteiltes System. Darüber hast du nur
    > bisher kein einziges Wort verloren

    Warum sollte ich?
    Was hat es mit dem Thema zu tun?

    Kind ich bin es leid hier über Dinge zu diskutieren die mit dem Thema herzlich wenig zu tun haben

    Der springende Punkt ist „Wahrscheinlichkeit der Garbage Collection“ und die ist einfach Schwachsinn, egal wie hoch man die setzt weil entweder geht dir die Platte/RAM-Disk über oder du hast unter Hochlast Apache-Prozesse die in einem Ordner mit tausenden Dateien rumgraben anstatt den User-Request zu beantworten

    Deswegen macht man das mit einem Cronjob anstatt in einem Artikel „Session-Verwaltung optimieren“ darauf hinzuweisen wo man an der Wahrscheinlichkeit drehen kann

    Und selbst wenn du deine dämlichen Sessions in eine Datenbank knallst bist du gut beraten die Cleanups nicht dem Webserver umzuhängen

    Ob und wie du verteilte Redundanz brauchst hat mit dem Thema eigentlich nichts zu tun und ob irgendjemand glaubt dass Virtualisierung zu empfehlen ist oder nicht spielt auch keine Rolle

    Dass VMware direkt kein VERTEILTES Clustering kann ist klar, das ändert aber nichts daran dass du gut beraten bist die so aufgesetzen Server an allen Locations in Virtualisierungs-Cluster zu knallen damit jede Node für sich Hochverfügbar ist und beim Hardwaretausch als auch bei Lastspitzen UNTERBRECHUNGSFREI migriert werden kann

    Optimierungen haben an allen Komponenten durchgeführt zu werden und es gibt verdammt wenige Last-Szenarien wo eine VM mit 10 GB RAM auf einem ProLiant DL380 nicht völlig asureichende Performance hat

    Alles was rüber hinausgeht hat sehr sehr wenig mit dem Thema hier zu tun

  17. Harry sagt:

    Zum Facebook-Artikel:

    > By way of example, he said that because
    > hundreds of virtual machines, each running
    > different applications, can be run on top of
    > a single server, if that specific hardware
    > fails it is complicated and costly to migrate
    > VMs, compared to starting again with new hardware

    Bruhahahahaha

    Was soll da kompliziert sein?

    Ja klar darf ich nicht so dämlich sein zu wenig Hosts hinzustellen dass wenn einer wegbricht die anderen die Leistung nicht auffangen können, wenn ich das mache habe ich einfach nichts vom Thema verstanden

    „Starting again with new hardware“?

    WTF – VMware DRS verteilt dir die Gastmaschinen automatisch auf die Hosts je nach aktueller Leistung und wenn du die kaputte Kiste austauschst und in den Cluster integrierst musst du nichtmal wo klicken und sie bekommt ihre Gastsysteme zugewiesen

    Bei Bare-Metal darfst du deinen ganzen Krempel wieder zurückspielen

    Sorry aber der Artikel spricht sich nicht gegen Virtualisierung aus sondern dagegen dass sie von Leuten gemacht wird die nichts davon verstehen, in dem fall ist es natürlich besser man lässt die Finger davon

  18. Ulrich sagt:

    > > Was meinst du denn was ein VM-Cluster ist?
    > > Ein verteiltes System. Darüber hast du nur
    > > bisher kein einziges Wort verloren
    > Warum sollte ich?

    Zumindest ich habe das Gefühl, dass die Diskussion deswegen ziemlich sinnlos verläuft. Du gibst ein paar Tipps von dir, und kommst nach Anmerkungen damit, dass das ja so gar nicht gemeint war, sondern noch viel toller.
    Guck dir doch die Beiträge hier mal an. Die meisten Leute wollen hier wissen, wie sie ihre WordPress-Installation auf dem Managed-Hosting Paket für 5€ „optimieren“. Hier wird jetzt gerade mal ein bisschen über GC und Randomisierung geredet. Wow. Dann kommt einer an und redet von Cronjob und Ramdisk. Glaubst du im ernst mein erster Gedanke ist dann „Klar, der redet von einer VM verteilt auf 50 Server und RAM-Größen von 100GB“? Nein. Mein erster Gedanke ist, du redest von deinem VServer, vielleicht noch deinem eigenen physikalischen Server, und vielleicht hat die Kiste sogar schon mehr 32GB RAM. Vielleicht hast du sogar ein paar mehr davon.
    Entsprechend antworte ich, und dann kommst du mit der Info um die Ecke, dass deine Dimensionen ja viel größer ist.
    Na ist klar, dass meine Antwort dann nicht hundertprozentig passt. In der Informatik sind alle Antworten kontextabhängig. Wenn du den Kontext vorenthältst, kann dein Diskussionspartner nur eher unpassende Reaktionen geben. Hättest du direkt mehr Kontext offenbart, hätte man auch eine sinnvollere Diskussion führen können.

    Darüber hinaus habe ich niemals gesagt, dass es eine schlechte Idee ist den GC aus den Requests raus zu ziehen.
    Ich habe dir genau genommen selten überhaupt widersprochen. Im Gegenteil, ich habe dir öfter zugestimmt.
    Ansonsten habe ich weitere Anmerkungen gegeben, wo man sich informieren kann, wenn man noch andere Sichten auf das Thema haben möchte. Und – so weit solltest selbst du mir zustimmen – es gibt nicht die Lösung, die alle Anwendungsfälle abdeckt. Sich selbst mit dem Thema zu beschäftigen, unterschiedliche Lösungen zu begutachten, und sich dann passgenau für die eigene Anwendung zu entscheiden, ist das Beste was man machen kann.

    Die geografische Verteilung hat viel mit dem Thema zu tun, denn sofort wird es notwendig die Daten nicht mehr nur auf einem Server/VMCluster zu halten, sondern auf mehreren. Damit ist deine Cronjob-Lösung mit Ramdisk ohne Erweiterung erstmal nicht zu gebrauchen, und – ich schließe die Brücke zu meinem ersten Beitrag – man ist gut damit beraten eine fertige verteilte Lösung zu nutzen, anstatt sich selbst etwas zu basteln.
    Womit übrigens auch mein Satz von oben „Deine ‚Konfig‘ ist ein Cronjob, der sich genau für ein-Server-Lösungen eignet. Ein-Server-Lösungen sind aber wie gesagt obsolet, man lese“ wieder vollkommen valide ist, ich würde ihn an der Stelle nur mit anderen Links belegen. Belege für globale IT-Systeme, wo VMs dran scheitern. Das hätte ich auch direkt gemacht, hätte ich gewusst worüber du sprichst.
    Für einzelne Server, egal ob physikalischer oder virtueller Natur, ist deine Lösung aber doch gut. Das steht auch ganz oben schon, und das hättest du ebenso für dich auch einfach von physikalisch auf virtuell abstrahieren können. Dass es keinen Unterschied macht worüber genau geredet wird, sollte dir ja klar sein. Zumindest wenn du verstanden hast, dass ich nicht auf RZ-Ebene diskutiere, sondern auf globaler Ebene. Du hast ja offensichtlich Ahnung vom Thema.

    Bei dem Artikel zu Facebook habe ich auch nicht alles verstanden, was derjenige als Argumente anführt. Meine Intention war es nur zu zeigen, dass es durchaus Menschen in hohen Positionen gibt, die eben anderer Ansicht sind.
    Ob das nun gut oder schlecht ist, dazu habe ich mich nicht geäußert.

  19. Harry sagt:

    > Die geografische Verteilung hat viel mit dem Thema
    > zu tun, denn sofort wird es notwendig die Daten
    > nicht mehr nur auf einem Server/VMCluster zu
    > halten, sondern auf mehreren.

    Das ist für sich genommen erstmal Unsinn

    Eine Website wird üblicherweise nicht nur aus einem Land aufgerufen und die IP-Pakete haben kein Problem damit Landesgrenzen zu überschreiten

    Selbiges gilt für Mailserver für hier einer für einen Kunden mit Stammsitz in London steht die auch Subdomains aus aller Herren Länder hier hosten

    Die geografische Verteilung macht für grosse Contents wie Videos und dergleichen Sinn – Dafür muss ich aber nicht das komplette Projekt auf mehrere Server legen

    Da wird einfach ein http://trafficserver.apache.org/ aufgesetzt und dann per DNS/Routing damit in CDN aufgebaut, der cacht statische Dateien wie Bilder und Multimediazeug und sämtliche Trafficserver stellen dir die Requests erstmal auf einen zentralen Origin-Server durch der damit wesentlich entlastet wird

    So, damit steigt mal dei Schwelle ab wann du mehr als einen Server brauchst gewaltig, die Leitungsanbindung ist auch kein Problem mehr und wenn die Leistung trotzdem nicht reicht ziehst du dahinter das Clustering wie gehabt durch und erklärst den Trafficserver-Instanzen dass sie jetzt mehrere Origin-Server haben

    Ändert aber nichts daran dass sowohl die Trafficserver als auch der oder die Origin-Server sehr gut in vSphere Clustern laufen weil ESXi5 mittlerweile nur mehr knapp 5% Virtualisierungs-Overhead hat der sich durch die deutlich verbesserte Administration und zuverlässiges Failover auf Node-Ebene locker ausgleichen lässt

  20. Ulrich sagt:

    > Eine Website wird üblicherweise nicht nur aus einem Land aufgerufen und die IP-Pakete haben kein Problem damit Landesgrenzen zu überschreiten.

    Ja, aber meist sind die ausländischen Gäste nur in kleiner Zahl vertreten. Dann ist es egal, das merkt keiner. Die gehen davon aus, dass es etwas langsamer ist, und die werden die Webseite auch nicht so regelmäßig nutzen, sodass sie sich beschweren würden.
    Deshalb schrieb ich oben von gleich verteilter Kundschaft z. B. in Amerika und Russland. Dann will und muss man natürlich beiden Kundenstämmen eine schnelle Anbindung bieten, und das geht nicht mit einem einzelnen originären Server (siehe unten).

    > Die geografische Verteilung macht für grosse Contents wie Videos und dergleichen Sinn – Dafür muss ich aber nicht das komplette Projekt auf mehrere Server legen.

    Du hast natürlich recht, gerade für große Inhalte lohnt es sich, und gerade große statische Inhalte sind leicht zu behandeln. Aber mal ehrlich, darüber muss man sich nicht unterhalten. Cache-Mechanismen für statische Dateien werden schon solange untersucht wie das Internet existiert. Du hast selbst schon eine Hand voll Maßnahmen genannt, wie man das abfedern kann, und es gibt vermeintlich noch eine Hand voll weiterer Maßnahmen.
    Das Problem sind immer die dynamischen Inhalte. In dem Moment wo ein Benutzer eingeloggt ist, und praktisch jeder Aufruf personalisiert ist, wo kein Cache mehr außerhalb der Applikation hilft, weil ihm die Intelligenz fehlt zu unterscheiden, wann ein dynamischer Inhalt veraltet ist oder nicht, … da wird es problematisch. Und gerade über dynamische Inhalte reden wir ja, sobald wir unter dem Thema Sessions diskutieren. Und da hilft kein Trafficserver und kein CDN, und die Schwelle „steigt“ bei der zunehmenden Sozialisierung von Webseiten nun auch wirklich nicht „gewaltig“ nur weil man nebst Cache-Header noch einen Proxy für sich als Mittel der Wahl erkannt hat. Das Internet wird einfach immer „persönlicher“ und damit immer „uncachbarer“.

    Die geografische Verteilung macht dann auch bei kleinen Inhalten Sinn. Die Latenz des Internets ist über weite Strecken nicht zu verachten. Ein Beispiel sei ein Ping in Richtung Facebook und einer in Richtung renren.com (ein großes chinesisches Social-Network): 100ms zu 550ms durchschnittlich über den Daumen gepeilt. Das allein ist schon ein Faktor 5 Unterschied. Du gibst hier Generate-Times von 0,011 Sekunden vor. Das macht also 11 ms drauf, ein bisschen Toleranz, wir sind für renren dann bei ungefähr 600ms. Die 550ms waren Durchschnitt, sprich die Hälfte liegt drüber, die Hälfte drunter, … schlechterer Fall also schon 700-800ms. Und es war nur ein Ping. Vermutlich werden mehr Datenmengen als der Inhalt eines Ping-Pakets übermittelt. Das dauert dann erwartungsgemäß etwas länger. Über den Daumen sind wir dann bei 1 Sekunde Anfragezeit. Das kann man im 21. Jahrhundert doch niemandem mehr bieten.

    Das war geschätzt. Den Profiler im Browser aufgerufen und gemessen:
    renren.com; Laden der ersten Seite (ohne statische Dateien) macht 2s connecting, 600ms waiting, 500ms receiving.
    Facebook.com; Wie oben macht connecting 300ms, waiting 210ms; receiving 1s
    Jetzt ist Facebook bei receiving deutlich schlechter, gut, renren übermittelt aber auch nur 7.5kb, während Facebook ganze 80kb übermittelt.

    Vermutlich ist ein Beispiel mit einem chinesischen Server hinter der chinesischen Firewall nun auch nicht das repräsentativste, aber es vermittelt einen Eindruck.

    Dass man die originären Server danach mit VMWare abhandeln kann und denen die Last mit Trafficserver oder irgendwie anders noch abnehmen kann, dem stimme ich soweit zu. Aber für globale primär dynamische IT-Systeme tut’s *ein* originärer Server einfach nicht. Dafür ist die Latenz vom Internet zu hoch.
    Und trotzdem muss man die Datenbestände dann irgendwie synchron halten.

  21. Harry sagt:

    > Aber für globale primär dynamische
    > IT-Systeme tut’s *ein* originärer
    > Server einfach nicht

    Sagen wir mal so: Für wenige tut er das nicht
    Für die meisten schon!

    * Client -> Trafficserver -> Keep-Alive-Connection
    * Neben der dynamischen Seite lädt die CSS/JS/IMG
    * Die Ladezeit CSS/JS/IMG macht einen Großteil aus
    * Dieser kommt vom nahen Proxy

    Die eigentliche Latenz kommt von einer Initial-Connection, der Rest wandert Keep-Alive ohne Handshakes etc.

    Wenn mein Origin-Server hochoptimiert ist und so wie unsere CMS-Seiten in 0.005-0.015 Sekunden generieren während die meisten anderen Systeme a) von Grund auf langsamer sind und b) darauf auch noch Monster wie Joomla laufen fahre ich mit dem einen Origin-Server 80% aller Internetangebote trotz Latenzen sowas von über den Kopf

    Unter Last holt dir ein hochoptmierter Server wo jede Komonente (DB-Layer, Bytecode-Cache, Sessionverwaltung, ordentliche Disk-Performance….) mit ihrer bestmöglichen Leistung arbeitet kommen an all diesen ecken und Enden soviele eingesparte Verzögerungen zusammen dass sie in den meisten Fällen Latenzen egalisieren

    Man muss halt auch das Gesamte sehen

    Abseits vom Server und der Software auf selbigem kannst du dann eine Seite auch noch intelligent aufbauen und die spürbare Ladezeit DEUTLICH reduzieren als wenn sie einfach mal schnell hingerotzt wurde

    Häng mal ein 30 KB Javascript in den Head-Bereich und dann probiers nochmal wenn du das Teil ans Ende des Body-Tags schiebst -> Das spürst du mehr als jede Latenz ganz einfach weil der Browser die ganze Seite zu rendern beginnt, irgendwann am Ende das Skript nachlädt und dann Event-Hanlder ausfüjrt anstatt das JS übers Netz zu ziehen und in der Zeit nichts zum Anziegen zu haben

Eine Antwort schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert mit *

You may use these HTML tags and attributes: <a href=""> <blockquote cite=""> <pre lang=""> <b> <strong> <i> <em>