Aus Linux-Magazin 07/2007

Apache-Alternativen

© Pippilotta, photocase.com

Obwohl Apache seit langem der meistverwendete Webserver ist, sind nicht alle Anwender damit zufrieden. Als leichtgewichtige Konkurrenten treten Cherokee und Lighttpd gegen ihn an. Letzterer konnte sich im vergangenen Jahr sogar heimlich unter die ersten Plätze schleichen.

Wer gegen Platzhirsche antreten will, hat es nicht gerade leicht. Im Web ist der Apache-Server nicht nur auf Unix-Seite derart weit verbreitet, dass die meisten gar nicht auf die Idee kommen, es könne auch Alternativen geben. Andererseits schleppt der Apache-Server durchaus einigen Ballast mit sich herum, der bis zu seinem Ursprung als NCSA-HTTPD zurückreicht.

So haben sich die Apache-Entwickler erst mit Version 2 vom Multiprozess-Modell mit seiner festen Anzahl vorab gestarteter Serverinstanzen lösen können. Jetzt gibt es immerhin eine Variante, die zur Verarbeitung von Requests mehrere Threads verwendet. Die Codebasis hat sich durch diese Neukonstruktion jedenfalls noch einmal vergrößert.

Cherokee

Mit wesentlich weniger Code kommt Cherokee [1] aus, der zwar Anfang 2006 einige Medienwellen schlug (Abbildung 1), aber im Rennen um den meistverwendeten Server bisher keine Chance hat. Aber er beherrscht die wichtigsten Anwendungsfelder eines Webservers und ist von überschaubarer Größe. Das zeigt sich schon bei der Installation: Sie setzt außer der C-Library keine außergewöhnlichen Bibliotheken voraus. Nur für SSL-Verbindungen greift Cherokee auf OpenSSL oder Gnutls zurück. Unter Verzicht auf einige Funktionen lässt sich Cherokee auch in eine Mikro-Variante für Embedded-Systeme übersetzen.

Abbildung 1: Mit seinem Webserver Cherokee hat es Programmierer Alvaro Lopez Ortega in die spanische Tageszeitung „El Pais“ geschafft.

Abbildung 1: Mit seinem Webserver Cherokee hat es Programmierer Alvaro Lopez Ortega in die spanische Tageszeitung „El Pais“ geschafft.

Nach dem Download von [1] und dem Entpacken bleibt nur die übliche Abfolge von »configure«, »make« und »make install«. Um die Cherokee-Dateien in die gewohnte Verzeichnishierarchie einzuspielen, ist im Configure-Schritt die Option »–prefix=/usr« nötig. Sonst landen die Dateien unter »/usr/local«. Das Konfigurations- und das Webwurzelverzeichnis setzen die Parameter »–sysconfdir« respektive »–with-wwwroot«.

Für größere Sicherheit kann Cherokee auch in einem Chroot-Jail laufen und besitzt Schnittstellen zur PAM-Authentifizierung und für LDAP. Die Performance beim Transfer großer Files verbessert Cherokee, indem er den neuen Systemaufruf »sendfile()« des Linux-Kernels verwendet, der die Datenübertragung zwischen Dateideskriptoren und Sockets beschleunigt. Für das normale Connection-Handling greift Cherokee auf das Epoll-Interface des Kernels zurück.

Sites durch Symlinks

Ist im Configure-Schritt das Konfigurationsverzeichnis auf »/etc« eingestellt, landen die Dateien mit den Cherokee-Einstellungen in »/etc/cherokee«, zum Beispiel »cherokee.conf«. Wer sich schon einmal mit der Apache-Konfiguration beschäftigt hat, dürfte damit keine Schwierigkeiten haben, auch wenn die Syntax ein bisschen anders aussieht. Zudem funktioniert Cherokee schon mit den Standardeinstellungen.

In »cherokee.conf« stehen nur die Haupteinstellungen, die für alle (virtuellen) Server gelten, die wiederum in »/etc/cherokee/sites-enabled« zu finden sind. Genauer gesagt stößt der Webmaster dort nur auf symbolische Links, die auf Dateien im parallel zu jenem Verzeichnis liegenden »sites-available« zeigen. Mit diesen Symlinks kann der Administrator ganz einfach Sites aus- und einschalten, ohne die Dateien selbst anzutasten.

Analog verhält es sich mit den Verzeichnissen »mods-available« und »mods-enabled«, die Erweiterungsmodule enthalten, zum Beispiel für SSL und die Verwaltung des Servers. Listing 1 zeigt einen Ausschnitt aus der Konfiguration des Standardservers.

Interessant sind vor allem die so genannten Handler, die, basierend auf Datei-Endungen oder Verzeichnisnamen, bestimmte Module von Cherokee aktivieren, die sich um das Datei-Handling kümmern. So lässt etwa der Handler »file« den Server ausgelieferte Dateien intern in einem Cache speichern. Auch den PHP-Support aktiviert der Administrator auf diese Weise, wie die Zeilen 26 bis 28 in Listing 1 zeigen.

Listing 1: »default«
von Cherokee

01 DirectoryIndex index.php, index.html, index.htm, index.shtml
02 
03 DocumentRoot /var/www/html
04 
05 UserDir public_html {
06     Directory / { 
07        Handler common
08     }
09 
10     Directory /cgi-bin/ {
11           Handler cgi
12           DocumentRoot /var/www/cgi-bin/
13     }
14 }
15 
16 Log combined {
17     AccessLog /var/log/cherokee.access
18     ErrorLog  /var/log/cherokee.error
19 }
20 
21 Directory /icons {
22     Handler file
23     DocumentRoot /usr/share/cherokee/icons/
24 }
25 
26 Extension php, php3, php4 {
27                 Handler phpcgi
28 }

Allerdings bekommt er damit nur die sehr langsame CGI-Version von PHP. Wie man die wesentlich schnellere Fast-CGI-Schnittstelle (FCGI) aktiviert, zeigt Listing 2. Ob der PHP-CGI-Interpreter auch Fast CGI beherrscht, verrät die Ausgabe von »php-cgi -v«. Über FCGI oder über das gleichfalls verfügbare SCGI-Interface lassen sich auch die meisten anderen Application-Server oder Frameworks wie Ruby on Rails anbinden.

Listing 2: Fast CGI mit
Cherokee

01 Extension php {
02    Handler fcgi {
03       Server localhost:8002 {
04          Env PHP_FCGI_MAX_REQUESTS "-1"
05          Env PHP_FCGI_CHILDREN     "11"
06          Interpreter  "/usr/bin/php-cgi -b 8002"
07       }
08    }
09 }

Lighty

Lighttpd [2] oder Lighty, wie er auch genannt wird, spielt bereits in einer anderen Liga. Vor einigen Monaten hat er sich unter die ersten vier der von Netcraft erhobenen Webserver-Charts geschlichen [3]. Zum Teil, weil ihn einige große Sites wie [flickr.com] einsetzen – wenn auch nicht für die Hauptserver.

Programmierer Jan Kneschke [4] hat sich schon mit anderen Open-Source-Projekten, vor allem im PHP-Bereich, einen Namen gemacht und arbeitet immer weiter daran, seinen Server zu verbessern. Lighty benutzt wie Cherokee die modernen und schnellen Kernelschnittstellen von Linux und beschleunigt so die Requestverarbeitung. Auf Wunsch verwendet er zum Beispiel auch den File Alteration Monitor (FAM) und reduziert damit die Zahl der nötigen »stat()«-Systemaufrufe. Dieses Feature kam jedoch im Test nicht zum Einsatz.

Lighttpd beeindruckt nicht nur durch gute Performance, sondern auch durch eine Vielfalt an interessanten Zusatzmodulen, zum Beispiel zum Flash-Streaming oder das überaus mächtige Magnet-Modul, mit dem sich die Phasen der Request-Bearbeitung über die Skriptsprache Lua [5] steuern lassen.

Die Konfiguration ist sympathisch einfach gestrickt: Es gibt nur eine Datei. Leider ist die Syntax manchmal etwas kompliziert und damit fehleranfällig, wie der Abschnitt des FCGI-Servers in den Zeilen 18 bis 25 von Listing 3 zeigt. Zum Glück genügt es meist, in den mitgelieferten Beispieldateien Passagen auszukommentieren und die Beispielstrings auszutauschen. Damit die FCGI-Anbindung funktioniert, muss das entsprechende Servermodul geladen werden (Zeile 11). FCGI-Backends lassen sich prinzipiell über mehrere Server verteilen, Lighttpd besitzt sogar einen eingebauten Load Balancer dafür.

Listing 3:
»lighttpd.conf«

01 server.modules = (  modules
02 #          "mod_rewrite",
03 #          "mod_redirect",
04 #          "mod_alias",
05            "mod_access",
06 #          "mod_cml",
07 #          "mod_trigger_b4_dl",
08 #          "mod_auth",
09 #          "mod_status",
10 #          "mod_setenv",
11            "mod_fastcgi",
12 ...
13 server.document-root  = "/var/www/html/"
14 server.errorlog       = "/var/log/lighttpd/error_log"
15 index-file.names      = ( "index.php", 
16                       "index.html","index.htm", "default.htm" )
17 ...
18 fastcgi.server        = ( ".php" =>
19                       ( "localhost" =>
20                         (
21                           "socket" => "/tmp/php-fastcgi.socket" , "bin-path" =>
22                            "/usr/bin/php-cgi"
23                         )
24                       )
25                 )

Auch Lighty läuft auf Wunsch in einer Chroot-Umgebung, bringt aber wesentlich mehr Funktionen mit als Cherokee. Das sind Standards wie FCGI, SCGI, Proxy-Funktion, Virtual Hosting, User Tracking, Traffic Shaping und einiges mehr. Es finden sich auch einige etwas exotische Anwendungen wie Geo-IP oder ein Modul für das RRD-Tool zur Traffic-Visualisierung.

Für den Test mussten Cherokee und Lighttpd gegen Apache in einem kleinen Benchmark antreten. Vorausgeschickt sei, dass dieser Benchmark – wie alle Web-Benchmarks – nur Anhaltspunkte für das Verhalten des Servers in einer echten Umgebung liefern kann. Es ist praktisch unmöglich, das komplexe zeitliche Verhalten vieler Clients zu simulieren, die über ganz unterschiedliche Bandbreiten zu gewissermaßen zufälligen Zeiten auf den Server zugreifen.

Nackte Zahlen

Es wurden keine Optimierungen irgendeiner Art vorgenommen, alle Serverprogramme liefen in der Standardkonfiguration auf einem Athlon 2800+ mit 1 GByte RAM. Die Benchmarks wurden in einem dedizierten 100-MBit-Ethernet mit lediglich einem Client durchgeführt, der mit Apachebench 1000 Seiten abruft und dabei zehn Requests parallel verarbeitet. Die entsprechende Kommandozeile:

ab -c 10 -n 1000 http://Server/Datei

Als Testdaten dienten drei HTML-Dateien mit den Größen von 1 KByte, 30 KByte und 100 KByte. Wie die Abbildung 2 zeigt, liegt die Konkurrenz gegenüber Apache vor allem bei kleinen Dateien vorn. Hier scheint sich der Vorteil des geringeren Verarbeitungs-Overhead am meisten bemerkbar zu machen. Bei größeren Dateien fällt er weniger ins Gewicht und andere Faktoren wie die Latenzzeiten von Netzwerk und Kernel gewinnen an Bedeutung.

Abbildung 2: Die Benchmarks zeigen, dass Cherokee und Lighttpd bei kleinen Files schneller als Apache sind. Bei größeren Dateien und PHP-Skripten fällt das Ergebnis gemischt aus.

Abbildung 2: Die Benchmarks zeigen, dass Cherokee und Lighttpd bei kleinen Files schneller als Apache sind. Bei größeren Dateien und PHP-Skripten fällt das Ergebnis gemischt aus.

Bei PHP-Skripten wendet sich allerdings das Blatt. Apache liegt in Führung, gefolgt von Lighttpd und vom weit abgeschlagenen Cherokee. Das ist kein Wunder, denn von Haus aus benutzt Cherokee die CGI-Variante von PHP, die für jeden Zugriff einen neuen Prozess starten muss. Weit besser sieht es aus, wenn Cherokee zur PHP-Verarbeitung das Fast-CGI-Interface benutzt. Damit kann er seine Leistung mehr als verdoppeln und sogar den Konkurrenten Lighty überflügeln, kommt jedoch nicht ganz an Apache heran.

Leicht und einfach

Cherokee und Lighttpd sind leistungsfähige Webserver, die den Marktführer Apache in mancherlei Hinsicht übertreffen. Zwar erreicht keiner der beiden die Funktionsvielfalt von Apache. Wie die Benchmarks zeigen, können sie aber zum Beispiel beim Ausliefern kleiner statischer Dateien einen Performance-Gewinn bringen.

Das bestätigt auch der Einsatz von Lighttpd bei der Site [flickr.com], die ihn innerhalb ihrer Farm als Server für Thumbnails verwendet. Dass beide Server im Vergleich zu Apache einfacher zu konfigurieren sind, macht einen relativ unkomplizierten Test möglich.

Infos

[1] Cherokee: [http://www.cherokee-project.com]

[2] Lighttpd: [http://www.lighttpd.net]

[3] Netcraft Survey: [http://news.netcraft.com/archives/web_server_survey.html]

[4] Jan Kneschkes Blog: [http://blog.lighttpd.net]

[5] Tim Schürmann, “Skriptsprache Lua”: Linux-Magazin 12/06, S. 128

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 3 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben