wie versprochen, hier mal ein Graph, der die Systemlast aufzeichnet.

Man beachte die Last gestern um 19 Uhr und heute um 19 Uhr. Ich habe die gleichen Besucherzahlen (+-200) wie gestern feststellen können.

Wie deutlich zu erkennen ist, habe ich kurz vor 18 Uhr den Webserver umgestellt.

Der Apache ist ein dickes Tier. Schon immer gwesen. Hier mal ein Bericht einer Migration von Apache auf lighttpd. Grafische Statistik folgt.

Hardware:

• Intel Pentium 4, 3.4GHz (HT)
• 1 GB DDR400 (non ECC) Ram
• 2x 120GB Sata im Hardware-Raid1

Ist-Zustand:

• apache2 (MPM: prefork) als Grundlage
• suPHP+php4-cgi für dynamische Webseiten
• MySQL4
• eine Webseite mit 30-50 Req's pro Sekunde (in der Hauptzeit)
• 80% Last pro CPU (zwei CPU's sichtbar, da HT)

Soll-Zustand:

• lighttpd
• php4-fcgi (spawned)
• MySQL4
• < 35% Last pro CPU in der Hauptzeit

Die Umsetzung:

Nachdem ich lange Zeit mit lighttpd geliebäugelt habe, entschloss ich mich gestern Abend einen der Webserver, die ich verwalte, auf lighttpd zu migrieren. Der einfache aber dennoch wichtige Grund war die stetig steigende Systemlast. Diese war für die "wenigen" Anfragen (50 Req's/sec) recht hoch.

Da es sich bei dem Webserver um ein produktives System handelt, lies ich den lighttpd auf Port 81 laufen. Man will ja vorher wenigstens ein wenig testen.

Wichtige Fakten die zu Beachten waren: - PHP Scripte müssen unbedingt mit den Rechten des jeweiligen Besitzers laufen (wg. Sicherheit und um Probleme bei Upload's zu vermeiden) - jede Webseite hat ihr eigenes Temp-Verzeichnis für Uploads und Sessions - rewrite Rules müssen zu 100% umgesetzt werden

Los ging es mit der Umsetzung der PHP-Anbindung. Am Anfang dachte ich, das wird relativ einfach. Ich musste jedoch schnell feststellen, das dem nicht so war.

Erstes Problem: die Scripte wollten partout nicht als Besitzer laufen. Nach ein wenig lesen in den Foren von lighttpd fand ich dann doch eine Lösung. (Hier nachzulesen):

Statt die FCGI Prozesse direkt starten zu lassen, lieber vorher forken (logischerweise als der jeweilige Benutzer). Dafür stellt lighttpd eigens das Programm "spawn-fcgi" zur Verfügung. Lighttpd greift dann nur noch auf die generierten Unix-Sockets zu.

Soweit so gut, die Scripte liefen dann auch als Besitzer. Es gab jedoch noch eine kleine Unstimmigkeit mit den Scripten:

Zweites Problem: alle Benutzer hatten das gleiche Temp-Verzeichnis. Auch hier fand ich schnell den Grund:

Ich hatte zuvor mittels suPHP die jeweiligen Scripte mit unterschiedlichen php.ini's versorgt. Also musste ich die php-fcgi's für jeden Webbenutzer nicht nur einzeln forken sondern auch unterschiedliche php.ini-Pfade übergeben. Klingt einfach? Ist es aber nicht: spawn-fcgi hat keine Möglichkeit, Argumente an das zu forkende FCGI-Programm zu übegeben. Aber von sowas wollte ich mich nicht aufhalten lassen.

Nach gut einer Stunde im Sourcecode rumhacken hatte ich dem spawn-fcgi ein neues Argument beigebracht, welches das Verzeichnis der php.ini an die php-fcgi Binary übergibt. (den Patch gibt es hier)

Nachdem alle PHP Angelegenheiten beseitigt waren, ging es weiter mit der Migrierung der .htaccess - speziell die rewrite Rules - Dateien. Das war kein großes Problem, nur ein bisschen Probieren war von Nöten, da das rewrite Modul von lighttpd noch (jedoch hoffentlich bald) keine RewriteConditions untersützt. Am Ende ging es jedoch ganz gut.

Rein umsetzungstechnisch war damit alles erledigt. Die Spannung stieg. Hat der ganze Aufwand wirklich was gebracht? JA! Hat er.

Die beiden (virtuellen) Prozessoren hatten jeweils eine Last von gerade mal 12-14 % - in der Hauptzeit! Wir erinnern uns, zuvor waren es rund 80 (!!) %.

Soviel dazu, ich werde Morgen mal die Graphen des Systemmonitors posten, das ihr den extremen Unterschied auch mal sehen könnt :-)

Sollten noch Fragen offen geblieben sein, oder ihr einfach noch mehr Details haben wollt - einfach einen Kommentar schreiben.