Er ist schon in Sichtweite, der neue Apache-Webserver 2.4. Der letzte Antrittsbesuch eines Häuptlings, Apache 2.2 sein Name, liegt bereits über fünf Jahre zurück. Der Neue soll ein schneller Läufer sein, erzählt man sich am Lagerfeuer.
Als außerordentlich wichtige Infrastrukturkomponente, die allerorten als geschäftskritische Applikation läuft, neigt der Apache-Webserver [1] nicht zu überraschenden Innovationen. Das ist kein Manko, ganz im Gegenteil: Admins mögen stabile APIs und eine konstante Struktur der Konfigurationsdateien. Ein Webserver ist nunmal kein Videoplayer, bei dem sich der Anwender nach dem morgendlichen Update über ein paar neue Knöpfe freut.
Umso bedeutsamer ist es, wenn Apache ein Major-Update ankündigt. Zuletzt war das im Dezember 2005 mit Version 2.2.0 der Fall. Die technisch größte Umstellung fand bislang im Jahr 2000 statt mit dem Übergang von Version 1.3 auf 2.0 [2]. Um es vorweg zu nehmen: So revolutionär wird der Übergang von 2.2 zu 2.4 nicht – aber umfangreich genug [3]. Langjährige Beobachter meinen, dass Menge und Qualität der Änderungen zumindest größer ausfallen als bei Upgrade 2.0 zu 2.2. Denn die Konkurrenz schläft nicht. Neben dem ewigen Zweiten Microsoft IIE drängen den Platzhirschen auch funktional schwachbrüstige, aber geschwindigkeitsoptimierte Verfolger (siehe Abbildung 1).
Abbildung 1: Die absolute Verbreitung von aktiven Webservern von 2000 bis heute zeigt Apache als Erstplatzierten. Damit das so bleibt, legen die Entwickler alle paar Jahre eine neue Version auf (Quelle: Netcraft)
Die Entwickler liegen offensichtlich deutlich hinter ihrem ursprünglichen Zeitplan: Vor einem Jahr prognostizierten sie noch Ende 2010 als Releasezeitpunkt der Version 2.4.0. Zum Redaktionsschluss lag Entwicklerversion 2.3.12-beta vor, die bereits alle neuen Komponenten enthält.
Neben neuen Versionen haben die Programmierer viel an der Geschwindigkeit gearbeitet. Die meisten Änderungen betreffen die MPM-Architektur (Multi Processing Modul). In solche Spezialmodulen lagert Apache den Code aus, der die Prozesse und Threads verwaltet. MPMs nehmen eingehende HTTP-Anfragen möglichst schnell und ressourcenschonend an und verarbeiten sie.
Jedes MPM implementiert eine andere Strategie, mit der der Webserver die anfallenden HTTP-Anfragen abarbeiten soll. Ein Webmaster bekommt so die Möglichkeit, die für seine jeweilige Anwendung geeignetste Variante auszusuchen (siehe Kasten "Vorgefertigte Apache-MPMs"). Die Apache-Entwickler erlauben es in MPMs übrigens schon länger ausdrücklich, betriebssystemspezifischen Code zu benutzen. Solche MPMs lassen sich nur auf diesem einen Betriebssystem übersetzen, laufen dann dort aber Performance-optimiert – ein Effekt, der insbesondere auf Nicht-Unix-Betriebssystemen zu beobachten ist.
Vorgefertigte Apache-MPMs
Prefork: bei diesem Unix-typischen Single-Threaded-Veteranen erzeugt ein Eltern-Prozess immer einen Vorrat von Kind-Prozessen für die eingehenden HTTP-Anfragen. Die Optionen »MinSpareServers«
und »MaxSpareServers«
legen den Mindest- und den Maximal-Vorrat an Kindprozessen fest. Sinkt die Anzahl der freien Prozesse unter die Anzahl »MinSpareServers«
, werden neue erzeugt, steigt sie über »MaxSpareServers«
, entfernt Apache sie aus dem Speicher. Da jeder Prozess genau eine Anfrage gleichzeitig bearbeitet, kann durch einen Fehler in einem solchen Prozess auch nur eine Verbindung mit dem Server verloren gehen, ein Vorteil vor allem bei dynamisch generierten Seiten.
Worker: Im Unterschied zu Prefork können hier in jedem Apache-Prozess mehrere Threads laufen; wie viele, das legt die Konfigurationsoption »ThreadsPerChild«
fest. Der Httpd achtet auf die verbliebene Anzahl der unbeschäftigten Threads. Die Direktiven »MinSpareThreads«
und »MaxSpareThreads«
geben an, wie viele Threads unbeschäftigt sein dürfen, bevor neue Prozesse erzeugt oder aus dem Speicher entfernt werden. Worker sieht ein Thread pro TCP-Verbindung vor. Threads verbrauchen unter Linux weniger Ressourcen als Prozesse. Andererseits kann ein fehlerhafter Thread seinen Prozess mitreißen.
Event: Das in Apache 2.2 noch als experimentell markierte Event-MPM ist mit Version 2.4 produktiv einsetzbar – möglicherweise wird es gar das Default-Modul. Event sorgt für eine Lastverteilung unter den gestarteten Threads, indem ein Listener-Thread Events auf Verbindungen überwacht und den Worker-Threads zuteilt. Ziel ist es, die Haupt-Threads dynamisch zu entlasten, indem der Algorithmus Aufgaben an untergeordnete Threads delegiert. Tests zeigen, dass davon vor allem Multicore-Maschinen profitieren.
Simple: Neues experimentelles MPM, das den Code und die Konfiguration zu vereinfachen trachtet. Wie Event arbeitet es multi-threaded und Event-basiert. Simple skaliert mittels zusätzlicher Prozesse; pro Prozess kommt eine feste Anzahl von Threads dazu.
Die mit Apache 2.0 eingeführten MPM-Architektur sah ursprünglich vor, das gewählte MPM in das Apache-Binary einzukompilieren. Apache 2.4 kann nun mehrere Module passend zum Core-Binary kompilieren und sie dynamisch zur Laufzeit konfigurierbar machen. So erhält der Webmaster von Servern mit langen Uptimes die Chance, den laufenden Httpd auf sich ändernde Useraktivitäten hin umzukonfigureren. Zudem versprechen die Entwickler eine bessere Unterstützung für asynchrone Lese- und Schreiboperationen im Event-MPM (Async Write Completion, die Threads freigibt, sobald der Inhalt übertragen ist, das Netz beim Zurückschreiben aber blockiert).
Der Admin kann in Apache 2.4 das Loglevel für Verzeichnisse und Module unterschiedlich einstellen (»TRACE1«
bis »TRACE8«
) und auch in extra Logfiles auflösen. Zudem führen die Entwickler beim Error-Logging ein neues Format ein, das mit Subsekunden-Zeitstempeln (in Mikrosekunden) hantiert.
Zudem bekommt Apache 2.4 neue Module mit auf den Weg: Mit Mod_lua findet die Skriptsprache Lua für Konfiguration und Logik ihren Weg ins Indianerdorf, Mod_proxy_fcgi sorgt für Fast CGI und Mod_ratelimit beschränkt wenn nötig die Bandbreiten für die Clients.
Als Fazit lässt sich sagen, dass Webmaster mit einiger Freunde und ohne Bedenken der neuen Version entgegensehen dürfen. Ob sich der von den Entwickler vermutete Geschwindigkeitsvorteil gegenüber dem noch amtierenden Häuptling einstellt, muss die Praxis zeigen.
Infos
Umfang: 2 Heftseiten
Preis € 0,99
(inkl. 19% MwSt.)
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
