Einige Gedanken zu Wordpress
Sebastian Kraus — 22.10.2013
Obwohl ursprünglich als Blog-Software konzipiert, wird WordPress inzwischen auf breiter Front auch im geschäftlichen Umfeld als Content Management System eingesetzt. Wir haben dazu einige Erfahrungen gesammelt.
Bevorzugt in Low-Budget-Projekten, in denen keine individuelle Programmierung erforderlich ist, sondern nur möglichst schnell ein rudimentäres CMS gebraucht wird, kommt WordPress gerne zum Einsatz. Zudem benutzen einige Kunden WordPress auch für den eigentlich angedachten Verwendungszweck, nämlich zum Bloggen. So haben wir inzwischen eine deutlich zweistellige Anzahl an Installationen dieser Software und können einige Erfahrung aus dem Betrieb zusammentragen.
Codequalität in Bezug auf Performance
Wir betreiben Server, auf denen mehrere Hundert Webseiten liegen und ausgeliefert werden. Ein sehr kleiner Anteil davon besteht aus statischen HTML-Seiten, ganz ohne ein Content Management System. Diese Seiten werden in aller Regel niemals zu einem Performanceproblem für den Server. Der weitaus größte Teil der Webseiten läuft mit unserem Hauseigenen Application Framework, geschätzt ca 3/4. Und dann sind da noch ca 25 WordPress-Installationen. Letztere verursachen ca 80% der Serverlast, während sie lediglich für 5 bis 10% der Seitenaufrufe verantwortlich sind. Gut verdeutlicht das der folgende Versuch:
Wir betreuen unter anderem Managed-Server bei 1&1. Man darf davon ausgehen, dass diese nicht vollständig falsch konfiguriert sind. Auf einer dieser Managed-Maschinen liegt die WordPress-Installation eines Kunden. Diese habe ich im Browser aufgerufen und dann den Finger für ca 30 Sekunden auf die F5-Taste gelegt. Das Folgende ist passiert:
Zur Erklärung: Die Load-Average beziffert in etwa die Auslastung pro CPU-Kern. Bei zwei CPU-Kernen - wie in diesem Fall - entspräche eine Last von 2 einer Vollauslastung. Das ist zwar etwas vereinfacht dargestellt, da hier nicht nur die CPU-, sondern auch Festplatten-IO und weitere Busauslastung mit einberechnet sind, aber als grober Richtwert taugt es. Eine Last von 4 auf dieser Maschine entspricht etwa einer 200%-Auslastung. Ich bin also in der Lage, mit einem Browser eine 1&1 Managed-Kiste so heftig auszulasten, dass sie nur noch mit INTERNAL SERVER ERROR antwortet. Dieses Ergebnis ist aus Performance-Sicht suboptimal bis inakzeptabel.
Codequalität in Bezug auf Bugs
Eine unserer WordPress-Installationen machte uns seit einigen Wochen Kummer. Sie hat ein Error-Logfile erstellt, welches über Nacht ca 11 GB groß wurde. Ein durchschnittliches Error-Logfile anderer Kunden kann schon mal 3 bis 4 MB groß werden, 11 Gigabyte sind aber eine Dimension, wo ein Systemadministrator nachsehen muss. Wir haben einen Fehler im Code festgestellt, der durch eine durch WordPress verursachte Endlosschleife tausendfach Warnungen in diese Logdatei geschrieben hat, bis die voreingestellte MAX_EXECUTION_TIME erreicht war. Da kommen dann über Nacht 11 GB zusammen und mittelfristig läuft man Gefahr, dass Festplatten volllaufen oder die Backup-Replikation an dieser Größe scheitert. Zwei geänderte Codezeilen in WordPress hätten genügt, um dieses Verhalten abzustellen. In fremde Kundeninstallationen habe ich in der Rolle des Webhosters aber nicht hineinzugreifen. Also bleibt nur die Webseite zu sperren und den Kunden darüber zu informieren, oder das Problem an die Entwickler von WordPress melden. WordPress ist ja Open Source, demnach hat jeder die Möglichkeit, Verbesserungen dort einzubringen.
http://core.trac.wordpress.org/ticket/25648
Wir haben uns dort die Mühe gemacht, das Problem zu beschreiben und haben Lösungsvorschlage angeboten, wie das Problem zu beheben sei. Folgender - repräsentativer - Dialog hat dieser Unternehmung ein jähes Ende gesetzt:
ticktoo
> So, am I right with my interpretation, that your point is, a 11GB
> Logfile full of catchable warnings caused by an infinite loop in
> one of your core component files is a valid behaviour?
ein WordPress Entwickler
> Yes.
> [...]