WordPress: Lighttpd, Apache, Reverse Proxy und andere Überlegungen

Dieser und einige andere WordPress-Blogs werden demnächst auf einen anderen Server umziehen. Ich bin gerade dabei den Server zu konfigurieren und bin noch etwas unschlüssig bzgl. der optimalen Komponenten. Ich will hier einfach mal ein paar meiner Gedanken niederschreiben – vielleicht kann der ein oder andere unter Euch ja was zum Thema beitragen.

Die bisherigen Server laufen zum großen Teil mit Plesk, was die Konfiguration der vhosts, mail-accounts, backup etc. stark vereinfacht, aber nicht das nötige Maß an Flexbilität zur Verfügung stellt um an der Performanceschraube zu drehen. Die Situation ist aber grundsätzlich okay, da durch die Vielzahl der dort laufenden Projekte, die einfache Konfiguration mit bewährter Software im Vordergrund steht. Bei diesem Server um den es jetzt geht spielt das keine Rolle – da werden nur recht wenige Projekte/Vhosts laufen.

„WordPress: Lighttpd, Apache, Reverse Proxy und andere Überlegungen“ weiterlesen

WordPress-Performance: MySQL vs. Apache

Gestern Abend durfte ich im Rahmen eines Kundenprojekts einmal mehr Erfahrungen im Umgang mit »High traffic« auf einem WordPress-Blog machen. Es handelt sich dabei um einen Blog der im Normalfall täglich zwischen 8.000 und 20.000 Unique Visitors hat und mit eingen Plugins (üblicher Umfang) ausgestattet ist.

Gegen 20 Uhr hat ein Ausnahmesituation dann dazu geführt, dass innerhalb kürzester Zeit die Besucherzahlen stark angestiegen und für ca. 1-2 Stunden sehr hoch geblieben sind. Interessant war dabei die Entwicklung der Serverlast auf unterschiedlichen Ebenen. Das Projekt läuft auf diesem Server und unter meiner Betreuung seit ca. 4 Monaten. Die Konfiguration des Servers wurde durch die Erfahrungswerte der letzte Wochen und Monate immer wieder angepasst und läuft seit einiger Zeit auch bei kleineren Lastspitzen absolut Problemfrei. Der gestrige Ansturm jedoch hat dazu geführt, dass die Hardware an seine Grenzen geführt wurde. Die Unix-Load war zu Spitzenzeiten bei Knapp unter 100 anzufinden. Im normalen Betrieb steigt sie selten über 1.

Die Analyse der Situation während des Ansturms und danach hat einige überraschende Aspekte hervorgebracht. Zum einen war entgegen meinen ersten Vermutungen der Datenbank-Server (MySQL) in keinster Weise schuld an der Auslastung. Klar stieg die Anzahl der Queries (Abfragen) in die Höhe, jedoch wurden nahezu alle vom großzügig angelegten Query Cache abgefangen, der sich komplett aus dem Arbeitsspeicher bedient und dadurch auch dafür gesorgt hat, dass der Webserver selbst bei recht hoher Systemlast noch zügig antworten konnte.

Die Auslastung des Arbeitsspeichers (insgesamt 4 GB) war während der ganzen aktion absolut im grünen Bereich. Grund dafür ist wohl vor allem die Tatsache, dass es sich fast ausschließlich um Lesezugriffe auf den DB-Server handelte und vorwiegend ein Beitrag aufgerufen wurde, der probemlos aus dem Cache geliefert werden konnte. Das tatsächliche Problem war zu Spitzenzeiten dann der Webserver (Apache 2.x) der bis zu 90 Requests/Sekunde handeln musste. Wie schon ander oben erwähnten geringen Memory-Auslastung zu erkennen war auch gar nicht der sonst oft erwähnte hohe Memoryfootprint des Indianers das Problem sondern eher die CPU-Last die dadurch entstand. Aus diesem Grund hat auch die kurzfristige Zuschaltung von WP-Supercache erwartungsgemäß keinen Erfolg gebracht.

CPU-Auslastung WordPress

Das eigentliche Problem beim hohen Resourcenverbrauch des Apache-Webservers sind dabei gar nicht unbedingt die blanken Userzugriffe auf dynamische Seiten, sondern eher die statischen Dateien die beim Aufbau der Seiten geladen werden. Dazu gehören z.B. Bilder des Layouts, Icons, kleine Javascript-Dateien etc. pp. Für jede dieser Dateien wird eine eigene Verbindung aufgebaut und belegt damit grundsätzlich erstmal den Verbrauch, den eine Verbindung braucht – egal ob sie einen Datenbankrequest zur Folge hat oder nicht. Pro Aufruf einer Seite entstehen so schnell mehr als 20 oder 30 Anfragen an den Webserver, Während der Spitzenzeit war das gut über den Statusmonitor des Webservers zu erkennen. EIn nicht unerheblicher teil der offenen Verbindungen kam durch Social-Bookmarking-Icons und ähnliches zu Stande. Mein Vorschlag an den Kunden wird daher sein den größten Teil der statischen Dateien – soweit möglich – auf einen zweiten Webserver (z.B. Lighttpd “Lighty”) auszulagern, der mit wesentlich weniger Resourcen klar kommt und auch für die Auslieferung dieser statischen Dateien optimiert wird. Das sollte die Ladegeschwindigkeit der Seiten noch einmal deutlich erhöhen und vor allem den Server bei Zugriffsspitzen deutlich entlasten.

Trotz allem wurde der gestrige Ansturm vom Server gut abgearbeitet und bis auf wenige Momente war die Seite problemlos erreichbar.