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.

Entsprechend den Gegenbenheiten kommt auf den Plesk-Servern Apache 2.x (mpm_prefork), PHP5 (mod_php) und mySQL 5 zum Einsatz. Leider ist die Diskussion zum Artikel „WordPress-Performance“ aufgrund der Probleme beim Update nicht mehr vorhanden. Unter anderem meine Erkenntnisse die daraus und aus der ganzen Optimierung dieses Projektes hervor gingen, will ich jetzt in die neue Serverkonfiguration einfließen lassen. Das bedeutet im einzelnen:

• Webserver/PHP nicht wie sonst über mod_php
• Eventuell vorsorglich eine Reverse-Proxy-Lösung zumindet vorsehen oder direkt einbauen

Die erstmal schwierigste Entscheidung ist die des richtigen Webservers. Weicht man vom Standard ab, bieten sich einige Möglichkeiten mit unterschiedlichen Vor- und Nachteilen. Ich will die mir bekannten und relevanten Möglichkeiten mal kurz aufführen und etwas erläutern:

Apache 2.2.x (mpm_worker)

Im Vergleich zum mpm_prefork handelt es sich beim „worker“ um einen Threaded Webserver. Die Performance soll gerade bei statischen Files deutlich besser sein als beim „prefork“. PHP wird über fast_cgi angebunden wodurch die Performance bei dynamischen Inhalten ungefähr ähnlich schnell wie mod_php sein sollte. mod_php ist beim „worker“ nicht möglich, da einige php-Erweiterungen nicht threadsafe ist. Infos zu den Multi-Processing-Modules (MPMs) gibt’s direkt bei Apache.

Nachteile: Bei statischen Files nicht so schnell wie die „leichte“ Konkurrenz. php/fast_cgi Lösung komplexer zu konfigurieren als mit mod_php.

Vorteile: Apache-Module (z.b. mod_rewrite) können verwendet und mit der meist verbreiteten Syntax bzw. direkten Unterstützung (WP selbst, SuperCache-Plugin, etc.) genutzt werden. Deutlich performantere Gesamtlösung als mit prefork_mpm.

Lighttpd 1.4.x

Der „Lighty“ wie er landläufig genannt wird, erfreut sich immer stärker wachsender Beliebtheit und ist vom Geheimtipp zur Performancealternative gewachsen. Ebenso wie der Apache unterliegt der Lighttpd einer OpenSource-Lizenz und wurde (nebst einigen Contributors) vom deutschen Jan Kneschke entwickelt. Das Projekt ist für ein relative kleines OSS-Projekt recht aktiv weshalb einem Einsatz aus diesem Gesichtspunkt nichts im Weg steht. Auch einige größere Websites wie YouTube und Wikipedia setzen auf den leichten httpd. PHP wird beim Lighty ebenfalls über fast_cgi angesprochen.

Nachteile: Die Konfiguration ist anders als beim Apache und daher für mich erstmal weitestgehend unbekannt (einige kleine Versuche ausgenommen). Für Apache-Module gibt es nicht immer ein Lighty-Äquivalent und auch die Konfiguration von z.B. rewrite-rules für „schöne URLs“ ist teilweise etwas kompliziert.

Vorteile: Bei Requests auf statische Dateien deutlich schneller als beide Apache-Varianten. Bei dynamischen Inhalten ist die Performance kaum anders als beim Apache mit php/fcgi.

Das war’s auch schon an wirklichen Alternativen. Warum? Das ist eigentlich auf eine Begründung herunterzubrechen. Die weiteren zur Verfügung stehenden Alternativen kommen für mich aufgrund der geringen Verbreitung und daher mangelnden Hilfsquellen nicht in Frage – ich bin kein Hardcore-Unix-Admin, der sich zur Not die Bits selbst zurecht biegt, sondern bin – wie wohl die meisten anderen auch – auf Dokumentation, Tipps, Tutorials etc. angewiesen. Nichts desto trotz will ich ein paar mögliche Alternativen dokumentieren, für diejenigen, die gerne etwas tiefer einsteigen:

• Nginx (sprich »engine-x«) – aus dem Umfeld von russischen Websites zu uns geschwappt findet der auch nicht mehr ganz junge httpd wohl vorwiegend im Rails-Umfeld sein Einsatzgebiet.
• LiteSpeed – kommerzielles leichtgewicht, das u.a. bei WordPress.com zum Einsatz kommt. Unterstütz (angeblich aber nicht problemlos) z.B. die apache mod_rewrite Syntax und wirbt auch damit „Apache Interchangable“ zu sein.
• Cherokee – auch ein kleiner Leichtgewichtiger. FastCGI-Support ist aber noch in den Kinderschuhen. Sollte man aber definitiv im Auge behalten.

Sicher gibt’s noch zahllose weitere Möglichkeiten, aber man muss es ja nicht übertreiben ;-)

Reverse-Proxy sinnvoll?

Die zusätliche Überlegung ist nun den Webserver auf einen anderen Port als default 80 zu legen bzw. nur lokale Verbindungen annehmen zu lassen und entweder einen Apache mit mod_proxy/mod_cache bzw. einen Squid auf Port 80 bzw. externe Verbindungen als Cache arbeiten zu lassen. Der Konfigurationsaufwand wird dadurch freilich deutlich größer, allerdings wächst auch der Puffer weil durch diese Lösung problemlos erstmal die meisten statischen Files in den Arbeitsspeicher gelegt werden können (der auf dem neuen Server mit 8G relativ großzügig bemessen sein wird). Wirklich nötig sein wird der Proxy vermutlich erstmal nicht, jedoch kann ein wenig Konfigurationserfahrung in diesem Bereich natürlich auch nicht schaden.

Das waren erstmal die Überlegungen – ich freue mich auf Eure Kommentare.