Wir waren ja, wie angekündigt mit dem halben Palasthotel auf dem Wordcamp in Köln. Von den fünf zuvor eingereichten Sessions wurde tatsächlich auch eine genommen – zu meiner großen Freude mein eigene. Bzw. nur halb meine eigene, denn ich hab zusammen mit Markus von unseren Freunden von Freistil.it etwas über unsere gemeinsamen Projekte erzählt, bei denen WordPress unter Hochlast (PDF) läuft.
Das Wichtigste fasse ich hier doch nochmal zusammen: Hochlast ist nicht gleich Hochlast.
Für den Kunden und Entwickler stellen sich aber alle Formen von Hochlast meist gleich dar: White Screen of Death, oder ein Fehler aus dem 500er Spektrum, oder eine Guru Meditation. WsoD können aber ganz, ganz unterschiedliche Ursachen haben, die dann unterschiedlich gelöst werden müssen. Daher dachten wir, ist es ganz klug mal einen Überblick zu geben, was für Ursachen wir inzwischen so kennengelernt haben.
- Viele, anonyme Zugriffe, bei relative wenigen Redakteuren und redaktioneller Veränderung.
- Viele, ggf. auch komplexe Inhalte, aber wenig Zugriffe.
- Viele, anonyme Zugriffe, zudem gebündelt in extremen Lastspitzen.
- Viele eingeloggte User (Redakteure oder Community).
- Viele Lesezugriffe und viele Schreibzugriffe. Entweder sehr aktive Communities, oder Live-Statistiken mit im CMS.
- Wenige Inhalte, aber viele, ineffektive Plugins. Death of a thousand Queries.
- Sehr aufwändige und langlaufende Prozesse.
Wenig überraschenderweise ist unsere Lösung für all die Problem nie „There’s a Plugin“ for that, sondern genau das Gegenteil. Die unterschiedlichen Lösungen für all diese Probleme haben eigentlich immer eines gemein: Die Lösung liegt außerhalb von WordPress (oder Drupal). Sei es in Form eines Varnishes, einer optimierten Datenbankstruktur, der Entlastung der Datenbank durch alternative Systeme oder das komplette Auslagern von Aufgaben auf unabhängige Server.
Alles in allem, war ich selber ganz schön erstaunt, was uns in den 4 Jahren, in denen wir jetzt in dieser Firma Projekte machen, schon so alles untergekommen ist…
