Der 250€ Turbo-Rucksack für den iMac (SSD)

Unter Fachleuten ist seit längerem unbestritten, was so langsam auch an die breite Öffentlichkeit dringt: Festplatten sind der größte Bremsfaktor im Alltagsgebrauch eines Computers. Zwar sind Prozessoren und Arbeitsspeicher natürlich weiterhin wichtige Faktoren, allerdings sind es am Ende meist doch die Festplatten deren vergleichsweise schlechte Performance einen Rechner in die Knie zwingt. Und selbst wenn dem blechernen Kumpel der Arbeitsspeicher ausgeht ist es die Festplatte die das Handling der Auslagerungsdateien zur enorm zähen Veranstaltung macht.

Während Arbeitsspeicher schon immer verhältnismäßig schnell war und sich sowohl in Größe als auch Preis großartig entwickelt hat, hat diese Entwicklung zwar auch der Festplattenmarkt durchgemacht, in Sachen Geschwindigkeit hat sich aber vor allem in den letzten Jahren recht wenig getan. Die logische Grenze ist hier bedingt durch die mechanischen Vorgänge, die in einer solchen Festplatte passieren: Schreib/Leseköpfe werden auf Armen über sich drehende Scheiben bewegt. Das geht zwar deutlich schneller als bei Papis Schallplattenspieler, dennoch aber einfach nicht schnell genug wenn es darum geht eine große Zahl kleinster Dateien schnell hintereinander zu laden die in der Regel über die ganze Festplatte verteilt liegen. „Der 250€ Turbo-Rucksack für den iMac (SSD)“ 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.

UTW-Patch eingearbeitet

Den hier erwähnten UTW-Patch habe ich eben testhalber mal auf diesem Blog eingearbeitet. Gefühlt ist alles etwas performanter, aber wie genau kann man das um die Uhrzeit ob des geringen Traffics und der müden Augen schon wahrnehmen? :)

Probleme bitte direkt in den Kommentaren posten. Sollte aber alles gut laufen wenn man die Reaktionen auf Donncha’s „Holy Shmoly!“ so liest. Donncha ist übrigens der Haupt- (oder sogar Standalone-) Entwickler von WordPress MU, der Multiuser/Bloghosting-Version von WordPress die (wenn auch in mittlerweile stark abgewandelter Form) auch bei WordPress.com zum Einsatz kommt.

[tags]performance,patch,wordpress,plugin,ultimate tag warrior, utw[/tags]

UTW-Performance-Boost

In letzter Zeit habe ich öfter von Problemen mit UTW (Ultimate Tag Warrior) für WordPress gelesen. Auch habe in den letzten Tagen vermehrt Probleme mit meinem Blog hier die nach etwas Nachforschung UTW zumindest mal nicht ausschließen. Durch Zufall bin ich gerade beim Googlen auf einen Performance-Patch für UTW gestoßen, der auch die Ursache einiger Probleme genauer erklärt.

Ich habe leider im Moment selber nicht die Zeit das zu testen, aber evtl. wills ja jemand anders ausprobieren.

Simple UTW Performance Boost

klingt vielversprechend. Außerdem gibt’s auf dem Blog offenbar noch einige andere Performance-Tipps für WordPress, die man sich ggf. mal genauer anschauen sollte.

[tags]wordpress,performance,utw,tags[/tags]

Demonstration

1&1 hat uns mal wieder gezeigt wie man sich gehörig in der Blogosphäre den Namen kaputt macht. Dr. Web – das allseits bekannte Webmastermagazin -betreibt ein Pohotoshop-Weblog auf Basis von WordPress 2. Dieses Weblog ist recht erfolgreich – bringt es auf ca. 5000 bis 6000 PageViews pro Tag. WordPress ist sicherlich nicht unkritisch was die Performance angeht, jedoch läuft das Photoshop-Weblog laut Dr. Web mit recht wenigen Plugins.

Immerhin 39,99 Euro pro Monat zahlte Dr. Web bisher für einen Shared-Hosting-Account beim Providerriesen. Als Dank dafür wurde nun mir nichts – Dir nichts von heute auf morgen (am Wochenende) die Datenbank gesperrt und eine Mail geschickt mit dem Hinweis: „Falls Sie Ihre Anwendungen in unveränderter Form weiterbenutzen möchten, sollten Sie auf einen dedizierten Server wechseln.“

Was ist denn nun eigentlich das schlimme daran und für mich persönlich ein Grund warum ich bei diesem Laden keinen Blog betreiben würde? Die Performance-Probleme von WordPress sind durchaus bekannt (siehe auch Thomas Promny), der Umgang mit Kunden von Seiten 1&1 leider auch. So geht man einfach nicht mit Kunden um – schon gar nicht mit Bloggern ;)

[tags]1und1, drweb, wordpress, performance, probleme, datenbank[/tags]

WordPress Performance: JS+CSS konsolidieren

Einen sehr interessanten Ansatz zur Performancesteigerung eines WordPress-Weblogs liefert Tom Sherman in seinem Artikel „Consolidate CSS and JavaScript in WordPress“.

Dabei hat er festgestellt, dass viele Plugins oft zum Problem werden – jedoch nicht wegen der steigenden Anzahl an Queries oder dem mehr an PHP-Code (das ist mit WP-Cache ganz gut in den Griff zu kriegen), sondern eher weil viele Plugins ihre eigenen zusätzlichen Files einbinden – vor allem Javascript und CSS. Das kann ich bestätigen und ist bei dem aktuell verwendeten Theme, das selbst schon einige Files einbindet gut zu sehen – ein Grund für mich mir da bald Gedanken drüber zu machen. Die Lösung baut Tom auf einer Konsolidierung der einzelnen Files auf, die sehr sinnvoll klingt.

Eine kurze Zusammenfassung seiner Tipps:

  • Javascript und CSS-Dateien der Plugins in jeweils einer Datei zusammenfassen
  • JS/CSS-Include der Plugins deaktivieren
  • konsolidierte Datei gzippen

Eine ausführliche Beschreibung in englischer Sprache findet sich hier.

[tags]wordpress,performance,konsolidierung[/tags]