Apache Performance Tuning

Hinweis: Bitte beachten Sie, dass dieser Artikel / diese Kategorie sich entweder auf ältere Software/Hardware Komponenten bezieht oder aus sonstigen Gründen nicht mehr gewartet wird. Diese Seite wird nicht mehr aktualisiert und ist rein zu Referenzzwecken noch hier im Archiv abrufbar.

Serverlimitierungen

Der Parameter MaxRequestWorkers (bis 2.3.13 MaxClients) bestimmt wieviel Apache Prozesse und somit Client Verbindungen zugelassen werden (Voraussetzung: prefork MPM). Wenn das worker MPM verwendet wird limitiert es die Anzahl der Threads die für Clients zur Verfügung stehen. Der Apache Standard für MaxRequestWorkers ist 256, wobei zu beachten ist, dass Distributionen oft andere Werte per Default gesetzt haben.

Wenn MaxRequestWorkers größer als 256 gesetzt werden soll, muss zusätzlich noch der Parameter ServerLimit entsprechend erhöht werden.

Wenn der MaxRequestWorkers Wert im laufenden Betrieb erreicht wird, wird dies im Apache error.log vermerkt.

[Fri Jun 05 13:15:24.760818 2015] [mpm_prefork:error] [pid 1649] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Spare Prozesse

Bei Verwendung von prefork MPM kann mittels des Parameters MinSpareServers eingestellt werden, wieviel unbeschäftigte (=spare) Apache Prozesse minimal zur Verfügung stehen sollen. Sobald eine Anfrage kommt kann dann dieser unbeschäftigte Prozess verwendet werden, wodurch die Anfrage schneller beantwortet werden kann, da nicht extra ein neuer Prozess erstellt werden muss. Der Parameter MaxSpareServers legt fest, wieviel spare Prozesse maximal vorgehalten werden dürfen, um nicht unnötig Arbeitsspeicher zu belegen. Die Apache Default Werte sind für MinSpareServers 5 und MaxSpareServers 10.

Bei Verwendung von worker MPM können analog dazu die jeweils verfügbaren Threads mit MinSpareThreads und MaxSpareThreads eingestellt werden. Zusätzlich ist noch der Parameter ThreadsPerChild relevant, wodurch die Anzahl der Threads pro Apache Prozess festgelegt wird.

Der Parameter StartServers legt fest wieviel Apache Prozesse beim Serverstart erstellt werden sollen.

Hardware Sizing

Wesentlich für die Anzahl der Serverprozesse ist der Arbeitsspeicher/RAM des Servers. Jeder Prozess benötigt einige MB Arbeitsspeicher, d.h. der Server muss über entsprechend viel RAM verfügen. Darüber muss man sich unbedingt Gedanken machen, wenn man die obig behandelten Werte optimiert. Wenn man zu viele Prozesse erlaubt, kann der RAM schnell ausgehen und der Server beginnt zu swapen. Dies sollte auf alle Fälle verhindert werden.

Mehr RAM bedeutet zusätzlich unter Linux auch einen größeren Page Cache, was das System generell beschleunigt, da viele I/O Abfragen aus dem RAM beantwortet werden können.

Das Skript apachebuddy.pl kann auch bei einer Prüfung der Konfiguration in Bezug auf RAM helfen: http://apachebuddy.pl

Module entschlacken

Je weniger Module der Apache Webserver geladen hat, desto kleiner ist der Memory Footprint der Apache Prozesse. Es ist daher sinnvoll nicht benötigte Module zu deaktivieren.

Einen Überblick über aktuelle geladene Module bekommt man mit folgendem Kommando:

root@testserver:/# apache2ctl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 mime_module (shared)
 mpm_prefork_module (shared)
 negotiation_module (shared)
 php5_module (shared)
 setenvif_module (shared)
 status_module (shared)

Man unterscheidet dabei zwischen statisch einkompilierten Modulen ("statically compiled") und dynamisch geladenen Modulen ("Dynamic Shared Objects", DSO). Im oberen Output sind die statischen Module mit dem "static" Hinweis und die dynamisch geladenen mit "shared" gekennzeichnet.

Die statischen Module können nur deaktiviert werden, indem das Apache Binary neu kompiliert wird. Davon wird generell eher abgeraten, da dadurch für jedes verfügbar gewordene Sicherheitsupdate der Apache Server wieder neu kompiliert werden müsste.

Die dynamischen Module können jedoch einfach deaktiviert bzw. aktiviert werden. Dies kann entweder direkt in der Apache Konfiguration erfolgen (siehe Parameter "LoadModule") oder meist einfacher mit eigenen Tools oder Verzeichnisstrukturen die in der jeweiligen Linux Distribution mitgeliefert werden.

Unter Debian/Ubuntu steht dafür das Tool a2enmod zum aktivieren und a2dismod zum deaktivieren zur Verfügung.

Unter CentOS/RHEL gibt es kein eigenes Tool zur Verwaltung der Module. Der Aufbau ist dort so gegliedert, dass die Default Module in /etc/httpd/conf/httpd.conf geladen werden und dort enstprechend auskommentiert werden können. Wenn Module zusätzlich installiert werden, wird in der Regel eine Datei in /etc/httpd/conf.d angelegt. Zum Beispiel gibt es für PHP eine Datei /etc/httpd/conf.d/php.conf.

DNS Abfragen

Der Parameter HostnameLookups sollte unbedingt auf "off" gestellt sein, da sonst jede Anfrage eine DNS Auflösung der anfragenden IP zur Folge hätte, was die Performance stark verschlechtert. Per Default ist dieser Wert seit Apache 1.3 auch auf "off" gestellt. Die DNS Auflösung soll stattdessen durch die Log-Auswertungssoftware vorgenommen werden.

Nicht benötigte Apache Features deaktivieren

Wenn z.B. der Parameter AllowOverride auf "All" gesetzt ist, muss bei jedem Apache Zugriff überprüft werden ob eine .htaccess Datei vorhanden ist. Wenn die .htaccess Funktionalität nicht verwendet wird bei der Webseite, sollte AllowOverride daher auf "None" gestellt werden. Wenn das Feature nur bei wenigen Verzeichnisen benötigt wird, sollte es dort explizit erlaubt werden mit einer "<Directory>" Direktive.

KeepAlive Requests

Die KeepAlive Funktionalität von HTTP erlaubt mehrere Anfragen eines Clients über die selbe TCP Verbindung abzuhandeln. Dies ist per Default aktiviert und kann über den Parameter KeepAlive gesteuert werden. Der Parameter KeepAliveTimeout legt fest, wie lange ein Prozess auf weitere Anfragen warten soll. (Default: 5 Sekunden)

HTTP Komprimierung

Das HTTP Protokoll erlaubt eine serverseitige Komprimierung von Content, welcher dann auf der Clientseite wieder dekomprimiert werden kann. Dies kann den Traffic senken und somit auch die Geschwindigkeit spürbar verbessern.

Möglich macht dies das Apache Modul mod_deflate.

Unter Debian existiert für Apache 2.4 auch schon eine Beispiel-Konfiguration:

AddOutputFilterByType DEFLATE text/html text/plain text/xml 
AddOutputFilterByType DEFLATE text/css 
AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript 
AddOutputFilterByType DEFLATE application/rss+xml 
AddOutputFilterByType DEFLATE application/xml

Achtung: Seit Apache 2.4 komprimiert mod_deflate nur dann, wenn der Overhead durch die Komprimierung kleiner ist, als die zu komprimierenden Daten. Ganz kurze Dateien werden dadurch unter Umständen nicht komprimiert. (siehe [1])

Trennung statischer und dynamischer Content

Wenn die oben erwähnten Optimierungen keine Besserung mehr bringen, kann es notwendig werden Content auf mehrere Server aufzuteilen. Eine beliebte Variante ist dabei, dass ein Frontend Server mit möglichst wenig geladenen Modulen und ohne dynamischen Content Modulen (wie z.B. PHP oder Perl) für alle statischen Daten (z.B. Bilder, CSS, Javascript) verwendet wird. Die Prozesse auf diesem Frontend Server haben dann einen minimalen Memory Footprint, d.h. der Server kann auch wesentlich mehr gleichzeitige Verbindungen verarbeiten. Der dynamische Content würde dann von einem weiteren Server (nennen wir ihn "Dynamic Content Server") verarbeitet. Diese Weiterleitung bzw. das Durchreichen vom Frontend Server zum Dynamic Content Server kann z.B. über das Modul mod_proxy realisiert werden.

Noch einfacher kann man diese Aufteilung auch realisieren, indem man z.B. eigene Subdomains für statische Daten verwendet. Viele große Webseiten machen von diesem Prinzip gebrauch. Wenn man z.B. YouTube betrachtet, dort kommen Bilder meist nicht von www.youtube.com sondern von einer eigenen Subdomain von ytimg.com.

Benchmark

Der Apache Webserver liefert bereits ein Benchmark Tool namens ab mit. Nähere Informationen dazu findet man hier: http://httpd.apache.org/docs/2.4/programs/ab.html

Sollte man PHP einsetzten, ist auch die Verwendung eine PHP Profilers (z.b. Xhprof) zu empfehlen.

Monitoring

Mit Hilfe des Moduls mod_status kann der Status des Webservers abgefragt werden. Der Zugriff erfolgt über

https://<servername>/server-status

. Normalerweise muss die IP des Clients noch explizit in der Konfiguration freigeschaltet werden.

Diese Status Seite kann einerseits für die manuelle Analyse verwendet werden und andererseits für eine automatische Überwachung via Icinga oder über das Percona Apache Monitoring Template [2].

Literatur/Quelle:

Autor: Christoph Mitasch

Christoph Mitasch arbeitet in der Abteilung Web Operations & Knowledge Transfer bei Thomas-Krenn. Er ist für die Betreuung und Weiterentwicklung der Webshop Infrastruktur zuständig. Seit einem Studienprojekt zum Thema Hochverfügbarkeit und Daten Replikation unter Linux beschäftigt er sich intensiv mit diesem Themenbereich. Nach einem Praktikum bei IBM Linz schloss er sein Diplomstudium „Computer- und Mediensicherheit“ an der FH Hagenberg ab. Er wohnt in der Nähe von Linz und ist neben der Arbeit ein begeisterter Marathon-Läufer und Jongleur, wo er mehrere Weltrekorde in der Team-Jonglage hält.