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.

0 Gedanken zu „WordPress: Lighttpd, Apache, Reverse Proxy und andere Überlegungen“

  1. Moin Moin,
    auf meinem Server läuft nur Lighttpd (Apache nur für SVN), da Apache für meinen verfügbaren RAM nicht gerade sauber und schnell läuft. Ich würde dir gleich die Version 1.5 von Lightly empfehlen, die ist zwar noch in Entwicklung aber vom Configsyntax viel besser.
    Bei WordPress.com läuft jetzt seit ein paar Tagen der russische Webserver ngnix. Matt soll ganz stolz auf das Ding sein ;). Ngnix kann ich dir empfehlen, wenn du bei WordPress das Plugin WP-Super-Cache nutzen willst. Bei Lighttpd könnte ich bisher kein perfekte Config dafür erstellen (Kann leider kein Lua).
    Gruß Dennis

  2. Danke für den Tipp bzgl. 1.5

    Ngnix kann ich dir empfehlen, wenn du bei WordPress das Plugin WP-Super-Cache nutzen willst.

    Warum?

    Ich überlege den Einsatz des Reverse-Proxy-Cache u.a. auch um von WP-(Super-)Cache unabhängig zu sein – hat natürlich den kleinen Nachteil das der Cache nicht so aktiv neu generiert werden kann wie es bei den WordPress-Plugins der Fall ist. Dafür könnte man z.B. locker die statischen Files aus dem Arbeitsspeicher des Servers ausliefern.

    Ich bastel schon den ganzen Tag im Kopf an dem Szenario rum, allerdings fällt mir selbiger bald vom Hals vor lauter Informationen ;-)

  3. Also, ich würde gerne WP-Super-Cache nutzen, weil mein RAM dann entlastet wird. Hab leider nur 128mb.
    Bei der WPMU-Installation der taz haben wir uns dafür entschieden eine Kombi von WP-Super-Cache und Memcache (Wird schon auch bei der Typo3-Installation genutzt).

    Gruß Dennis

  4. Ich meinte eher warum die Nginx dafür empfehlen kannst – das muss ja nen Grund haben, wenn Du es empfiehlst.

    Bei der WPMU-Installation der taz haben wir uns dafür entschieden eine Kombi von WP-Super-Cache und Memcache (Wird schon auch bei der Typo3-Installation genutzt).

    Wer ist denn wir?

    Der memcached dürfte aber ziemlich außen vor sein, wenn WP-Super-Cache im Einsatz ist oder was cached der?

  5. Ich meinte eher warum die Nginx dafür empfehlen kannst – das muss ja nen Grund haben, wenn Du es empfiehlst.

    Weil für WP-Super-Cache muss man ja abfragen ob die statische Seite wirklich gibt und ob der Benutzer eingeloggt (Cookie vorhanden) ist. Das geht bei Apache über mod_rewrite, bei nginx über die Config. Bei Lighttpd müsste man sowas über die Lua-Config machen, dass kann ich leider nicht. Deshalb mein Tipp für nginx.

    Wer ist denn wir?

    Das Team von taz.de und ich ;)

    Der memcached dürfte aber ziemlich außen vor sein, wenn WP-Super-Cache im Einsatz ist oder was cached der?

    Jein, die Blogseiten ist ja statisches. Aber es gibt ja viele dnyamische Übersichtsseiten (Tolle neue Funktion) und diese brauche viele Querys, die werden alle cachtet über memcache. Außerdem bekommt jeder der einen Kommentar hinterlässt die PHP-Seite und diese Benutzer sollen auch eine schnelle Seite bekommen.

  6. @Dennis, es wurde doch Pound (Load Balancer) ausgetauscht, nicht der Webserver. Die überlegen, ob sie in Zukunft komplett auf ngnix setzten, aber zur Zeit ist das nur der neue Load Balancer.

    „Dieser und einige andere WordPress-Blogs“ machen so viel Traffic? Die Frage ist ja, ob ein Reverse Proxy überhaupt was bringt. Bei WordPress bezweifel ich das etwas. Dagegen wurde z.B. MediaWiki extra dafür entwickelt, dass es mit Memcached, Squid, MySQL Replication… zusammenarbeitet.

    Und wenn ein Reverse Proxy, warum nicht Varnish?

  7. “Dieser und einige andere WordPress-Blogs” machen so viel Traffic?

    @Martin: nein, machen sie nicht. Die Notwendigkeit zu solchen Maßnahmen ist sicher fraglich. Für mich ist es auch mehr ein Experiment und eine Herausforderung.

    Die Frage ist ja, ob ein Reverse Proxy überhaupt was bringt. Bei WordPress bezweifel ich das etwas.

    Das hat nur sekundär mit WordPress zu tun – den dynamischen Requests stehen auf jeden Fall eine Menge satischer gegenüber die man mit einem Cache (der zumindest bei Squid zusammen mit dem ReverseProxy kommt) wunderbar aus dem Arbeitsspeicher ausliefern kann.

    Und wenn ein Reverse Proxy, warum nicht Varnish?

    Weil ich ihn bisher nicht kenne – danke für den Hinweis.

    Ein etwas einfacher zu konfigurierender und wartender Ansatz mit dem ich derzeit liebäugle ist eine apache2 (mpm_worker) im Zusammenspiel mit mod_cache. Ich konnte nur noch nicht viel Erfahrungswerte über mod_cache finden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.