Die Alternativen an Webserver-Software sind eigentlich recht überschaubar, wobei jede eine gewisse Daseinsberechtigung aufweist.

Etabliert und durchaus die eierlegende Wollmilchsau: der Apache HTTP Server. Kann alles, aber zu einem hohen Preis.

Zu nennen wäre hier beispielweise, dass Apache direkt SVN bzw. DAV spricht und über weitere Module erweitert werden kann. Auch die Verarbeitung von .htaccess-Dateien vereinfacht gerade für unpriviligierte Anwender die Konfiguration und Anpassung. PHP lässt sich nicht nur “klassisch” als Modul (mod_php5), sondern auch als selbst-gesteuerter (mod_fcgid) oder extern kontrollierter (mod_fastcgi) FastCGI-Prozess einbinden. Durch die große Verbreitung sind besonders viele Verwaltungsoberflächen existent, über die die Konfiguration des Apachen bequem per Webinterface angepasst werden kann (Confixx, Plesk, CPanel, ISPConfig, ISPCP Omega, LiveConfig, Froxlor, …).

Allerdings arbeitet Apache entweder mit einem Thread- oder Prozess-orientiertem Modell, wobei für jede Anfrage ein neuer Thread/Prozess mit dem kompletten Modul-Stack erstellt wird. Dies kostet nicht nur Geschwindigkeit, da der Thread/Prozess entweder on demand erzeugt oder vorab bereitgestellt wird, in jedem Fall aber dauerhaft RAM: jeder aktive Request hält Daten im RAM und belastet diesen ziemlich.

Andere Webserver verwenden kein Prozess-Modell, sondern arbeiten event-basiert.

Persönlich bin ich dabei Fan des Lighttpd: dieser ist nicht nur schlank, sondern bietet auch eine übersichtliche und flexible Konfigurationssyntax. Genau wie der Apache können PHP-Prozesse selbst gesteuert werden oder aber auf externe Prozesse zurückgegriffen werden.

Nachteil des Lighttpd: er kann weder SVN-Repositories einbinden, noch gibt es dafür vernünftige Weboberflächen. Auch zeigte sich in Benchmarks und unter “hoher Belastung”, dass Lighttpd durchaus seine Nachteile hat.

Für Webseiten, die besonders hohe Last erzeugen, greifen wir daher seit längerem auf Nginx zurück. Genau wie Lighttpd arbeitet Nginx mit dem eventbasierten Prozessmodell, kann somit eine große Anzahl an Anfragen mit nur minimalem RAM-Bedarf parallel verarbeiten.

Nginx arbeitet dabei noch extremer als Lighttpd. Dies betrifft sowohl die Leistung (Nginx kann deutlich mehr Anfragen verarbeiten als Lighttpd oder gar Apache), als auch die Konfiguration an sich. So unterstützt Lighttpd die Ausführung von CGI/Perl-Skripten problemlos, Nginx benötigt hierfür einen externen Wrapper (der CGI-Skripte via FastCGI bereitstellt). Ähnliches gilt für PHP, wobei Nginx die PHP-Prozesse nicht selbst steuern kann, sondern auf einen externen Prozess angewiesen ist.

Hier kommt nun der “neue” PHP-FastCGI Prozess Manager (PHP-FPM) ins Spiel. Dieser erlaubt die Konfiguration mehrerer “Pools”, die auf einem TCP/Unix-Socket auf Anfragen warten. PHP-FPM steuert dabei die Anzahl der aktiven Prozesse, die UNIX-Umgebung (unter welchem Benutzer der PHP-Prozess läuft) sowie die PHP-Laufzeit-Variablen.

Dementsprechend arbeiten Nginx und PHP-FPM perfekt zusammen: statische Inhalte liefert Nginx direkt von der Festplatte aus, die dynamischen werden per FastCGI-Protokoll an PHP-FPM übergeben.

Da es bereits anderweitig genügend positive Erfahrungen gab, habe ich heute einige Seiten weg vom Apache zu Nginx migriert, wobei das Ergebnis überzeugt. Gefühlt laden die Seiten jetzt bei gleichem bzw. niedrigerem Server-Load schneller.

Durch die Trennung von Webserver und Skript-Ausführung ist es nun auch möglich, einzelne Webanwendung komplett von den anderen abzuschotten: Dafür ist es nur notwendig, einen eigenen Linux-System-Account anzulegen, die Verzeichnisrechte passend zu setzen sowie den entsprechenden PHP-FPM-Pool anzupassen, damit der PHP-Prozess mit den Rechten des neuen Benutzers läuft. Ein erfolgreicher Angriff auf eine einzelne Webanwendung kompromittiert somit nicht den gesamten Server.

Leider steht Nginx für unsere Hosting-Systeme nicht zur Debatte, dafür ist dieser noch zu unflexibel. Nicht nur müsste die komplette Konfigurations-Generierung umgeschrieben werden, die bisher gewohnten Abläufe müssen auch angepasst werden. Dazu gehört, dass .htaccess-Dateien nicht mehr verarbeitet werden (alle Anweisungen müssten im Webinterface verwaltet werden können) sowie die Syntax dieser Konfiguration sich doch deutlich vom Apache unterscheidet. Die dafür nötige “Migration” ist schon allgemein nicht gerade einfach, für Einsteiger aber unzumutbar.

Plesk verwendet Nginx als Proxy vor dem Apachen, um statische Dateien schneller auszuliefern. Meiner Meinung nach ist dies eine Option, die aber den Aufwand nicht rechtfertigt. Gerade dynamische Dateien erzeugen allgemein eine höhere Last – und diese wird dem Apachen nicht abgenommen.

Auf unseren Kunden-Systemen greifen wir jedoch des öfteren auf ISPConfig3 zurück. Dieses kann statt dem Apache auch Nginx verwalten und betreuen, jedoch lohnt sich der Aufwand nur dann, wenn die eingesetzten CMS überschaubar und relativ einfach sind. Mit ISPConfig lässt sich zwar die Nginx-Konfiguration direkt per Weboberfläche anpassen bzw. erweitern – die Migration (beispielweise) der Rewrite-Rules werden einem aber auch nicht abgenommen. Auch dieses Blog sowie unsere Firmenseiten werden seit Anfang April mit Nginx und PHP-FPM ausgeliefert, wobei die Konfiguration über ISPConfig3 erfolgt.

Eigene Statistiken, die den Erfolg von Nginx belegen, liegen uns noch nicht vor. Der interne Server “terra”, der auch dieses Blog hostet, hat zwar seit dem Einsatz von Nginx deutlich niedrigere Auslastungswerte. Diese sind aber primär dem davor erfolgten Server-Hardware-Upgrade (bzw. der Migration auf neue Hardware) geschuldet. Ein SAS-RAID10 arbeitet dann doch schneller als ein betagtes SATA1-RAID1 von 2008 …

Somit wird Nginx bei allen internen Anwendungen wohl häufiger zum Zuge kommen – auf Webhosting-Systemen aber gibt es derzeit keine Alternative zum Apachen.

Next Post Previous Post