nginx, PHP und WordPress

WordPress on steroids

Folgender Artikel ist etwas für technisch interessierte Leser. Ich schildere hier meine Erfahrung mit dem Webserver nginx, dem FCGI-Dienst spawn-cgi und einem darauf laufenden WordPress.

Dass das Blogsystem WordPress nicht unbedingt sparsam mit den Ressourcen umgeht, ist mittlerweile fast allen klar. Dem zu einem fast vollwertig gewachsenen CMS spendiert man auch immer fleißig weitere Funktion

alitäten, viele Dinge, die früher als Plugins installiert werden mussten, wandern in den Kern. Und dennoch wird der eine oder andere Blogger auch weiterhin seine Plugins installieren, da WordPress halt nicht die perfekte eierlegende Wollmilchsau ist. Dies alles geht natürlich immer zu Lasten der Performance. Es wird mehr RAM benötigt, auch die PHP-Version muss nun mindestens 5 (5.1?) sein, und die Ladezeiten beim Besucher schnellen da gern mal in die Höhe. Mit den falschen Plugins können das mal mehrere Sekunden sein, gefühlt wie Minuten!

Aber ich hab nun die Erfahrung gemacht, dass es auch anders geht. Doch nicht jedem ist dieses Glück beschieden. Denn: man muss schon am besten einen eigenen Server haben (ein VPS^[01] geht auch).

Warum?

Die Lösung für ein wirklich flottes (und auch RAM schonenderes) WordPress liegt halt auch in der darunter liegenden Architektur, die verwendet wird. Das Gespann Apache mit mod_php ist jedenfalls aus meiner Sicht schon die denkbar ungünstigste Variante, die aber sicher in den meisten Fällen auf Webservern zur Anwendung kommt. Fast jeder Webhoster wird diese billige Lösung nutzen – sehr wohl auch zum eigenen Leidwesen! Da es nämlich auch anders geht und die Anbieter so auch bessere Qualität liefern könnten.

Nun kann man zwar weiterhin auf Apache bauen, aber für PHP eine andere Schnittstelle nutzen: FCGI, FastCGI oder ein vergleichbarer CGI-Wrapper wären Alternativen. Getestet habe ich das jetzt nicht (also Apache+FCGI), aber ich vermute stark, dass hier durchaus das eine oder andere Megabyte an RAM gespart wird, ohne Caching nutzen zu müssen (was wohl eh nicht so trivial ist – damit beschäftige ich mich wohl auch erst später).

Nun sollte man wissen, dass aber auch der Apache selbst nicht unbedingt zu den sparsamsten Webservern gehört, außerdem ist er auch manchmal recht träge. Es gibt da draußen viele, viele andere Programme, die auch ihren Dienst tun. Okay, manche Funktionen werden dann nicht zur Verfügung stehen, aber mal Hand aufs Herz: wer von euch weiß überhaupt, was die Webserver-Kiste denn wirklich kann? Und dann noch die ganzen Module beim Apache … da ist man manchmal auch froh, wenn der Server einfach nur das macht, wofür er gedacht ist: Seiten ausliefern!

Kleines Wunder: nginx

Und das tut dann auch die nun von mir verwendete Alternative und nennt sich nginx. Dieses feine Stück Software kommt ursprünglich aus russischen Landen, erfreut sich aber nun einer wohl weltweiten Beliebtheit. Weil er schlank ist, weil er kaum Ressourcen beansprucht und weil er eigentlich sogar etwas mehr kann als der Apache: er ist nicht nur ein reiner Webserver sondern auch ein guter Proxy. Viele große Seiten oder Dienste verwenden wohl auch schon den nginx zum Verteilen der Lasten (denn das kann er auch so ganz nebenbei – Stichwort Loadbalancing). Nun interessierte mich vordergründig nicht der Proxy oder Loadbalancer, sondern der Webserver und dessen Leistung – denn auf einem einzigen Server gibt es zumindest nicht zu viel zu verteilen an Last. Zum Thema Proxy komme ich aber noch einmal, dass brauchen wir nämlich dann doch noch in einer anderen Form.

Mein Zwischenbericht lautet bis hierher: der nginx ist verdammt schnell! Und klein! Und ich will behaupten, dass er auch unter großer Beanspruchung dem Apache haushoch überlegen sein wird.

Schnell, schneller, spawn it!

Doch damit es nicht nur bei statischen Seiten so schnell geht, muss also hinter dem Webserver auch das PHP vernünftig ackern. Und das erreichen wir im Falle von nginx nicht mit einem simplen PHP-Modul wie im Apache, sondern hier muss man schon noch ein wenig mehr Hand anlegen. Ich habe mich für die Variante mit spawn-fcgi entschieden, da es dazu einige englischsprachige Anleitungen gab und diese CGI-Variante wohl auch mit eines der vielversprechendsten ist, es gibt noch einen anderen FCGI-Server, der mich interessiert, den ich aber erst zu späterer Zeit testen werde (fpm soll der Testkandidat sein, wer hier schon Erfahrung gesammelt hat, gern her damit!).

Beim nginx geht dieser Übergang auch recht einfach, theoretisch ist die Lösung eine Art implementierte Proxy-Geschichte. Tatsächlich kann die CGI-Anwendung sogar auf einem anderen Server laufen als der Webserver! Die Grundkonfiguration ist meist in der default-Site hineinkommentiert, andernfalls einfach die vielen Beispiele im Netz nehmen, da man hier oftmals einen ungeschriebenem Standard folgt. Also für eine Site einfach mal die CGI-Konfiguration vorbereitet und weiter geht es mit dem CGI-Dämonen, der da werkeln soll.

Der Helfer spawn-cgi ist meistens im Paket für einen anderen leichtgewichtigen Webserver vorhanden, dem lighttpd. In Ubuntu z. B. muss man also diesen installieren (er muss aber dagegen nicht laufen, kann also -falls er automatisch starten sollte- getrost deaktiviert werden). Dann frickelt man sich den spawn-cgi so zurecht, dass er als Dienst läuft und auch bei einem Reboot automatisch gestartet wird. Ganz nebenbei kann man dann auch mal die php.ini für die CGI-Variante anpassen, da diese Konfiguration nicht unbedingt dieselbe wie für den Apache sein muss. In allen gängigen Linux-Distributionen wird nämlich gern eine ini-Datei für die möglichen drei Anwendungsfälle vorgehalten: Apache, CGI und CLI (die Konsolenvariante).

Wenn man nun ausreichend getestet hat, dass der spawn-cgi läuft, dann sollte man nun alles zusammen testen. Nicht vergessen, die neue Konfiguration der Site im nginx durch einen Restart selbigen zu aktivieren. Mit der phpinfo()-Funktion geht der Test ganz gut und man bekommt auch alle nötigen Infos der Umgebung gleich mit.

WordPress, it’s your turn!

Jetzt kann man endlich ein WordPress installieren. Achja, wer die schönen Permalinks haben will, muss nochmal kurz Hand anlegen. nginx bietet keine .htaccess-Unterstützung, aber im Falle von WordPress braucht man ohnehin nur eine simple Rewrite-Regel, die ruhig fest in die Konfiguration eingearbeitet werden kann. Den Rest übernimmt WordPress zum Glück von allein dank internem Rewriting.

Was mir sofort auffällt: die Reaktionszeiten sind beeindruckend! Es fühlt sich fast so an, als wenn man auf einem lokalen System testet.

Nachdem ich WordPress eingerichtet und einige Plugins installiert und aktiviert hatte, war ich vollends überzeugt, den richtigen Riecher gehabt zu haben.

Im Schnitt kann ich sagen, dass WordPress nun nur noch rund die Hälfte des RAMs frisst als via Apache mit mod_php und dafür auch noch schneller reagiert als der Bruder im Indianerdorf. Und dies, obwohl wir jetzt auf dem Server auf Prozessebene vielleicht eher einen Schritt zurück gemacht haben (nginx-Prozess und spawn-cgi-Prozess), was aber auch wieder ein Vorteil ist. Denn durch die Trennung von Webserver und FCGI-Daemon habe ich auch etwas mehr Flexibilität gewohnnen, da ich Pferd und Sattel beliebig wechseln kann anstatt ein Pferd mit festgeschraubtem Sattel zu nutzen. Klar, ich könnte auch das Schlachtross Apache weiter verwenden, aber ich will einen schnellen Gaul statt Limousine mit Pool. Letzteres ist zwar chic, aber ersteres im Internet wohl wichtiger.

Fazit

Ich werde wohl mit vielen meiner Projekte umsatteln. blogcraft läuft zwar noch auf dem Apache, aber z. B. mein privates Blog mannaz.cc rennt bereits mit dem hier geschildertem Szenario. Mit einem Testblog werde ich wohl auch mal andere FCGI-Dienste wie den erwähnten fpm testen, um auf der Ebene auch noch mal separat vergleichen zu können. Doch mit dem spawn bin ich schon sehr zufrieden.

Mein Webdesign-Gedanke setzt sich nun auch technisch fort, denn ich mag minimalistische Sachen. Man kann vielleicht dann nicht soviel rumspielen, aber dies ist in Produktivumgebungen wohl auch weniger ratsam.

Was man jetzt noch mit Caching-Möglichkeiten wie memcached & Co. rausholen kann, bleibt bei mir auch noch offen. Bisher sehe ich da aber auch noch keinen Bedarf, da alles sowas von flott und flüssig geht, dass ich wohl noch reichlich Zeit habe, mir da noch was anzulesen und dieses zu testen.

WordPress funktioniert übrigens reibungslos. Dass z. B. keine .htaccess zum Tragen kommt, stört überhaupt nicht, es sei denn, man verwendet Plugins, die darauf aufbauen, was bei WordPress-Caching-Lösungen durchaus der Fall ist. Mit der hier geschilderten Lösung sollte der Blogger aber ohnehin erst einmal ohne WP-Cache oder WP Super Cache auskommen können.

Zusammenfassung der technischen Details

• Webserver: nginx
• FCGI-Dienst: spawn-cgi (im lighttpd enthalten)
• WordPress mit einigen Plugins
• RAM und Geschwindigkeit – Vergleich
  • Blog auf Apache mit mod_php: rund 25 MB (in Spitzen hatte ich auch mal bis zu 50 MB!)
  • Blog auf nginx mit spawn-cgi: 50 % weniger RAM-Verbrauch! Dafür aber auch gefühlte 1000 % schneller!

Wer sich dafür interessiert, wie das technisch im Detail funktioniert, melde sich hier in den Kommentaren. Bei genügend Feedback werde ich dann ein Tutorial erstellen, da es im deutschsprachigen Raum kaum gute Anleitungen hierzu gibt.

Auch noch offene Fragen können wir hier gemeinsam klären, da es hier ja schon hochtechnisch hergeht.

Wordpress on steroids Folgender Artikel ist etwas für technisch interessierte Leser. Ich schildere hier meine Erfahrung mit dem Webserver nginx, dem FCGI-Dienst spawn-cgi und einem darauf laufenden Wordpress. Dass das Blogsystem Wordpress nicht unbedingt sparsam mit den Ressourcen umgeht, ist mittlerweile fast allen klar. Dem zu einem fast vollwertig gewachsenen CMS spendiert man auch immer fleißig weitere Funktion alitäten, viele Dinge, die früher als Plugins installiert werden mussten, wandern in den Kern. Und dennoch wird der eine oder andere Blogger auch weiterhin seine Plugins installieren, da Wordpress halt nicht die perfekte eierlegende Wollmilchsau ist. Dies alles geht natürlich immer zu Lasten der Performance. Es wird mehr RAM benötigt, auch die PHP-Version muss nun mindestens 5 (5.1?) sein, und die Ladezeiten beim Besucher schnellen da gern mal in die Höhe. Mit den falschen Plugins können das mal mehrere Sekunden sein, gefühlt wie Minuten! Aber ich hab nun die Erfa