Apache für maximale Leistung konfigurieren

Apache ist eine Open-Source-HTTP-Server-Implementierung. Es ist der beliebteste Webserver im Internet. Die Webserver-Umfrage von Netcraft aus Dezember 2005 [

] zeigt, dass etwa 70 % der Websites im Internet Apache verwenden.

1. Leistung des Apache-Servers

Die Leistung des Apache-Servers kann durch Hinzufügen zusätzlicher Hardware-Ressourcen wie RAM, schnelleren CPU usw. verbessert werden. Aber meistens kann das gleiche Ergebnis durch eine benutzerdefinierte Konfiguration des Servers erreicht werden. Dieser Artikel befasst sich damit, die maximale Leistung aus Apache mit den vorhandenen Hardware-Ressourcen, insbesondere auf Linux-Systemen, herauszuholen. Natürlich wird angenommen, dass genügend Hardware-Ressourcen vorhanden sind, insbesondere genügend RAM, damit der Server nicht häufig auslagert. Die ersten beiden Abschnitte befassen sich mit verschiedenen Compile-Time- und Run-Time-Konfigurationsoptionen. Der Run-Time-Abschnitt geht davon aus, dass Apache mit dem

prefork

MPM kompiliert ist. HTTP-Kompression und Caching werden als Nächstes behandelt. Schließlich wird die Verwendung separater Server für die Bereitstellung statischer und dynamischer Inhalte diskutiert. Grundkenntnisse in der Kompilierung und Konfiguration von Apache und Linux werden vorausgesetzt.

2 Compile-Time-Konfigurationsoptionen

2.1 Nur die erforderlichen Module laden:

Der Apache HTTP Server ist ein modulares Programm, bei dem der Administrator die Funktionalität auswählen kann, die im Server enthalten sein soll, indem er eine Reihe von Modulen auswählt [

]. Die Module können entweder statisch in die httpd-Binärdatei kompiliert oder als Dynamic Shared Objects (DSOs) kompiliert werden. DSO-Module können entweder kompiliert werden, wenn der Server erstellt wird, oder die

apxs

Utility verwenden, um sie später zu kompilieren und hinzuzufügen. Das Modul mod_so muss statisch in den Apache-Kern kompiliert werden, um die DSO-Unterstützung zu aktivieren.

Führen Sie Apache nur mit den erforderlichen Modulen aus. Dies reduziert den Speicherbedarf und damit die Serverleistung. Das statische Kompilieren von Modulen spart RAM, der zur Unterstützung dynamisch geladener Module verwendet wird, aber man muss Apache neu kompilieren, wann immer ein Modul hinzugefügt oder entfernt werden soll. Hier kommt der DSO-Mechanismus ins Spiel. Sobald das mod_so-Modul statisch kompiliert ist, kann jedes andere Modul mit dem LoadModule-Befehl in der httpd.conf-Datei hinzugefügt oder entfernt werden - natürlich müssen Sie die Module mit apxs kompilieren, wenn sie nicht kompiliert wurden, als der Server erstellt wurde.

2.2 Wählen Sie das geeignete MPM:

Der Apache-Server wird mit einer Auswahl von Multi-Processing-Modulen (MPMs) geliefert, die dafür verantwortlich sind, Netzwerkports auf der Maschine zu binden, Anfragen anzunehmen und Kinder zu dispatchen, um die Anfragen zu bearbeiten [

]. Es kann immer nur ein MPM gleichzeitig in den Server geladen werden.

Die Wahl eines MPM hängt von verschiedenen Faktoren ab, wie z. B. ob das Betriebssystem Threads unterstützt, wie viel Speicher verfügbar ist, Skalierbarkeit versus Stabilität, ob nicht-thread-sichere Drittanbieter-Module verwendet werden usw. Linux-Systeme können wählen, ob sie ein thread-basiertes MPM wie worker oder ein nicht-thread-basiertes MPM wie prefork verwenden:

Das Worker-MPM verwendet mehrere Kindprozesse. Es ist innerhalb jedes Kindes mehrthreadig, und jeder Thread bearbeitet eine einzelne Verbindung. Worker ist schnell und hochgradig skalierbar, und der Speicherbedarf ist vergleichsweise gering. Es eignet sich gut für mehrere Prozessoren. Andererseits ist der Worker weniger tolerant gegenüber fehlerhaften Modulen, und fehlerhafte Threads können alle Threads in einem Kindprozess beeinträchtigen.

Das Prefork-MPM verwendet mehrere Kindprozesse, wobei jedes Kind eine Verbindung zur gleichen Zeit bearbeitet. Prefork eignet sich gut für Einzel- oder Doppel-CPU-Systeme, die Geschwindigkeit ist vergleichbar mit der des Workers, und es ist hochgradig tolerant gegenüber fehlerhaften Modulen und abstürzenden Kindern. Aber der Speicherverbrauch ist hoch, mehr Verkehr führt zu mehr Speicherverbrauch.

3 Run-Time-Konfigurationsoptionen

3.1 DNS-Lookup:

Die Direktive HostnameLookups aktiviert DNS-Lookups, sodass Hostnamen anstelle der IP-Adresse protokolliert werden können. Dies fügt jeder Anfrage Latenz hinzu, da der DNS-Lookup abgeschlossen sein muss, bevor die Anfrage beendet ist. HostnameLookups ist standardmäßig in Apache 1.3 und höher deaktiviert. Lassen Sie es deaktiviert und verwenden Sie ein Nachbearbeitungsprogramm wie logresolve, um IP-Adressen in den Zugriffsprotokolldateien von Apache aufzulösen. Logresolve wird mit Apache geliefert.

Wenn Sie die Direktiven Allow from oder Deny from verwenden, verwenden Sie die IP-Adresse anstelle eines Domainnamens oder eines Hostnamens. Andernfalls wird ein doppelter DNS-Lookup durchgeführt, um sicherzustellen, dass der Domainname oder der Hostname nicht gefälscht wird.

3.2 AllowOverride:

Wenn AllowOverride nicht auf ‘None’ gesetzt ist, wird Apache versuchen, die .htaccess-Datei (wie durch die Direktive AccessFileName angegeben) in jedem Verzeichnis zu öffnen, das es besucht. Zum Beispiel:

DocumentRoot /var/www/html  
   
 AllowOverride all

Wenn eine Anfrage für die URI /index.html gestellt wird, wird Apache versuchen, /.htaccess, /var/.htaccess, /var/www/.htaccess und /var/www/html/.htaccess zu öffnen. Diese zusätzlichen Dateisystem-Lookups erhöhen die Latenz. Wenn .htaccess für ein bestimmtes Verzeichnis erforderlich ist, aktivieren Sie es nur für dieses Verzeichnis.

3.3 FollowSymLinks und SymLinksIfOwnerMatch:

Wenn die Option FollowSymLinks gesetzt ist, folgt der Server symbolischen Links in diesem Verzeichnis. Wenn SymLinksIfOwnerMatch gesetzt ist, folgt der Server symbolischen Links nur, wenn die Zieldatei oder das Zielverzeichnis vom gleichen Benutzer wie der Link besessen wird.

Wenn SymLinksIfOwnerMatch gesetzt ist, muss Apache zusätzliche Systemaufrufe tätigen, um zu überprüfen, ob die Eigentümerschaft des Links und der Zieldatei übereinstimmt. Zusätzliche Systemaufrufe sind auch erforderlich, wenn FollowSymLinks NICHT gesetzt ist. Zum Beispiel:

 DocumentRoot /vaw/www/html   
    
 Options SymLinksIfOwnerMatch

Für eine Anfrage, die an die URI /index.html gerichtet ist, wird Apache lstat() auf /var, /var/www, /var/www/html und /var/www/html/index.html ausführen. Diese zusätzlichen Systemaufrufe erhöhen die Latenz. Die lstat-Ergebnisse werden nicht zwischengespeichert, sodass sie bei jeder Anfrage auftreten.

Für maximale Leistung setzen Sie FollowSymLinks überall ein und setzen Sie niemals SymLinksIfOwnerMatch. Andernfalls, wenn SymLinksIfOwnerMatch für ein Verzeichnis erforderlich ist, setzen Sie es nur für dieses Verzeichnis.

3.4 Inhaltsverhandlung:

Vermeiden Sie die Inhaltsverhandlung für schnelle Antworten. Wenn für die Website eine Inhaltsverhandlung erforderlich ist, verwenden Sie Typen-Map-Dateien anstelle der Direktive Options MultiViews. Mit MultiViews muss Apache das Verzeichnis nach Dateien durchsuchen, was die Latenz erhöht.

3.5 MaxClients:

Die MaxClients-Direktive legt das Limit für die maximalen gleichzeitigen Anfragen fest, die vom Server unterstützt werden können. Es werden nicht mehr Kindprozesse erzeugt als diese Anzahl. Es sollte nicht zu niedrig eingestellt werden, sodass neue Verbindungen in die Warteschlange gestellt werden, die schließlich ablaufen und die Serverressourcen ungenutzt bleiben. Wenn dies zu hoch eingestellt wird, beginnt der Server mit dem Auslagern, und die Antwortzeit verschlechtert sich drastisch. Der geeignete Wert für MaxClients kann berechnet werden als: MaxClients = Gesamter RAM, der dem Webserver zugewiesen ist / Maximalgröße des Kindprozesses —- [

] Die Größe des Kindprozesses zur Bereitstellung statischer Dateien beträgt etwa 2-3M. Für dynamische Inhalte wie PHP kann es etwa 15M betragen. Die RSS-Spalte in

"ps -ylC httpd --sort:rss"

zeigt den nicht ausgelagerten physischen Speicherverbrauch durch Apache-Prozesse in Kilobyte.

Wenn es mehr gleichzeitige Benutzer als MaxClients gibt, werden die Anfragen bis zu einer Anzahl, die auf der Direktive ListenBacklog basiert, in die Warteschlange gestellt. Erhöhen Sie ServerLimit, um MaxClients über 256 zu setzen.

3.6 MinSpareServers, MaxSpareServers und StartServers:

MaxSpareServers und MinSpareServers bestimmen, wie viele Kindprozesse während des Wartens auf Anfragen gehalten werden. Wenn MinSpareServers zu niedrig ist und eine Reihe von Anfragen eingeht, muss Apache zusätzliche Kindprozesse erzeugen, um die Anfragen zu bedienen. Das Erstellen von Kindprozessen ist relativ teuer. Wenn der Server beschäftigt ist, Kindprozesse zu erstellen, kann er die Client-Anfragen nicht sofort bedienen. MaxSpareServers sollte nicht zu hoch eingestellt werden, da dies zu Ressourcenproblemen führen kann, da die Kindprozesse Ressourcen verbrauchen.

Passen Sie MinSpareServers und MaxSpareServers so an, dass Apache nicht häufig mehr als 4 Kindprozesse pro Sekunde erzeugt (Apache kann maximal 32 Kindprozesse pro Sekunde erzeugen). Wenn mehr als 4 Kinder pro Sekunde erzeugt werden, wird eine Nachricht im ErrorLog protokolliert.

Die StartServers-Direktive legt die Anzahl der Kindserverprozesse fest, die beim Start erstellt werden. Apache wird weiterhin Kindprozesse erstellen, bis die Einstellung MinSpareServers erreicht ist. Hat nicht viel Einfluss auf die Leistung, wenn der Server nicht häufig neu gestartet wird. Wenn es viele Anfragen gibt und Apache häufig neu gestartet wird, setzen Sie dies auf einen relativ hohen Wert.

3.7 MaxRequestsPerChild:

Die MaxRequestsPerChild-Direktive legt das Limit für die Anzahl der Anfragen fest, die ein einzelner Kindserverprozess bearbeiten wird. Nach MaxRequestsPerChild-Anfragen wird der Kindprozess beendet. Es ist standardmäßig auf 0 gesetzt, was bedeutet, dass der Kindprozess niemals abläuft. Es ist angemessen, dies auf einen Wert von einigen Tausend zu setzen. Dies kann helfen, Speicherlecks zu verhindern, da der Prozess nach dem Bedienen einer bestimmten Anzahl von Anfragen stirbt. Setzen Sie dies nicht zu niedrig, da das Erstellen neuer Prozesse Overhead verursacht.

3.8 KeepAlive und KeepAliveTimeout:

Die KeepAlive-Direktive ermöglicht es, mehrere Anfragen über dieselbe TCP-Verbindung zu senden. Dies ist besonders nützlich, wenn HTML-Seiten mit vielen Bildern bedient werden. Wenn KeepAlive auf Aus gesetzt ist, muss für jedes Bild eine separate TCP-Verbindung hergestellt werden. Der Overhead durch das Herstellen einer TCP-Verbindung kann durch das Aktivieren von KeepAlive eliminiert werden.

KeepAliveTimeout bestimmt, wie lange auf die nächste Anfrage gewartet werden soll. Setzen Sie dies auf einen niedrigen Wert, vielleicht zwischen zwei und fünf Sekunden. Wenn es zu hoch eingestellt ist, sind die Kindprozesse damit beschäftigt, auf den Client zu warten, während sie für die Bedienung neuer Clients verwendet werden könnten.

4 HTTP-Kompression & Caching

Die HTTP-Kompression ist vollständig in HTTP/1.1 spezifiziert. Der Server verwendet das gzip- oder deflate-Codierungsverfahren für die Antwortnutzlast, bevor sie an den Client gesendet wird. Der Client dekomprimiert dann die Nutzlast. Es ist keine Installation zusätzlicher Software auf der Client-Seite erforderlich, da alle gängigen Browser dies unterstützen. Die Verwendung von Kompression spart Bandbreite und verbessert die Antwortzeit; Studien haben einen durchschnittlichen Kompressionsgewinn von 75,2 % festgestellt [

]. Die HTTP-Kompression kann in Apache mit dem

mod_deflate

Modul aktiviert werden. Die Nutzlast wird nur komprimiert, wenn der Browser eine Kompression anfordert, andernfalls wird unkomprimierter Inhalt bereitgestellt. Ein kompressionsbewusster Browser informiert den Server, dass er komprimierten Inhalt über den HTTP-Anforderungsheader - “Accept-Encoding: gzip,deflate” - bevorzugt. Dann antwortet der Server mit komprimierter Nutzlast und dem Antwortheader, der auf “

Content-Encoding:  
gzip

Der folgende Beispiel verwendet telnet, um Anforderungs- und Antwortheader anzuzeigen:

bash-3.00$ telnet www.webperformance.org 80  
 Trying 24.60.234.27...  
 Connected to www.webperformance.org (24.60.234.27).  
 Escape character is '^]'.  
 HEAD / HTTP/1.1  
 Host: www.webperformance.org  
 Accept-Encoding: gzip,deflate  
   
 HTTP/1.1 200 OK  
 Date: Sat, 31 Dec 2005 02:29:22 GMT  
 Server: Apache/2.0  
 X-Powered-By: PHP/5.1.1  
 Cache-Control: max-age=0  
 Expires: Sat, 31 Dec 2005 02:29:22 GMT  
 Vary: Accept-Encoding  
 Content-Encoding: gzip  
 Content-Length: 20  
 Content-Type: text/html; charset=ISO-8859-1

Beim Caching wird eine Kopie der Daten beim Client oder in einem Proxy-Server gespeichert, sodass sie nicht häufig vom Server abgerufen werden muss. Dies spart Bandbreite, verringert die Last auf dem Server und reduziert die Latenz. Die Cache-Steuerung erfolgt über HTTP-Header. In Apache kann dies durch die Module mod_expires und mod_headers erreicht werden. Es gibt auch serverseitiges Caching, bei dem die häufig abgerufenen Inhalte im Speicher gespeichert werden, sodass sie schnell bereitgestellt werden können. Das Modul mod_cache kann für serverseitiges Caching verwendet werden, es ist in der Apache-Version 2.2 produktionsstabil.

5 Separater Server für statische und dynamische Inhalte

Apache-Prozesse, die dynamische Inhalte bereitstellen, benötigen etwa 3M bis 20M RAM. Es wächst, um den Inhalt, den es bereitstellt, aufzunehmen und verringert sich nie, bis der Prozess stirbt. Angenommen, ein Apache-Prozess wächst auf 20M, um einen dynamischen Inhalt bereitzustellen. Nach Abschluss der Anfrage ist er frei, eine andere Anfrage zu bedienen. Wenn eine Anfrage für ein Bild eingeht, bedient dieser 20M-Prozess einen statischen Inhalt, der ebenso gut von einem 1M-Prozess bereitgestellt werden könnte. Der Speicher wird ineffizient genutzt.

Verwenden Sie einen kleinen Apache (mit minimalen Modulen, die statisch kompiliert sind) als Front-End-Server, um statische Inhalte bereitzustellen. Anfragen für dynamische Inhalte werden an den schweren Apache (kompiliert mit allen erforderlichen Modulen) weitergeleitet. Die Verwendung eines leichten Front-End-Servers hat den Vorteil, dass die statischen Inhalte schnell ohne großen Speicherverbrauch bereitgestellt werden und nur die dynamischen Inhalte an den schweren Server weitergeleitet werden.

Die Anfrageweiterleitung kann durch die Verwendung der Module mod_proxy und rewrite_module erreicht werden. Angenommen, es gibt einen leichten Apache-Server, der auf Port 80 hört, und den schweren Apache, der auf Port 8088 hört. Dann kann die folgende Konfiguration im leichten Apache verwendet werden, um alle Anfragen außer Anfragen für Bilder an den schweren Server weiterzuleiten.

ProxyPassReverse / http://%{HTTP_HOST}:8088/  
 RewriteEngine on                                             ---- [9]  
 RewriteCond   %{REQUEST_URI} !.*\.(gif|png|jpg)$  
 RewriteRule ^/(.*) http://%{HTTP_HOST}:8088/$1 [P]

Alle Anfragen, außer für Bilder, werden an den Backend-Server weitergeleitet. Die Antwort wird vom Frontend-Server empfangen und dann an den Client geliefert. Soweit der Client betroffen ist, scheinen alle Antworten von einem einzigen Server zu kommen.

6 Fazit

Die Konfiguration von Apache für maximale Leistung ist knifflig, es gibt keine festen Regeln. Verstehen Sie die Anforderungen des Webservers und experimentieren Sie mit verschiedenen verfügbaren Optionen. Verwenden Sie Tools wie

und

httperf

, um die Leistung des Webservers zu messen. Leichte Server wie

tux

thttpd

können ebenfalls als Front-End-Server verwendet werden. Wenn ein Datenbankserver verwendet wird, stellen Sie sicher, dass er optimiert ist, damit er keinen Engpass verursacht. Im Falle von MySQL kann

mtop

verwendet werden, um langsame Abfragen zu überwachen. Die Leistung von PHP-Skripten kann durch die Verwendung eines PHP-Caching-Produkts wie

Turck MMCache

verbessert werden. Es beseitigt den Overhead durch das Kompilieren, indem es die PHP-Skripte im kompilierten Zustand zwischenspeichert.