www.thomas-krenn.com - der Server Spezialist
Apache Performance Tuning
Aus Wiki Thomas-Krenn.AG
Serverlimitierungen
Der Parameter 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 MaxClients ist 256, wobei zu beachten ist, dass Distributionen oft andere Werte per Default gesetzt haben.
Wenn der Wert von MaxClients größer als 256 gesetzt werden möchte, muss zusätzlich noch der Parameter ServerLimit entsprechend erhöht werden.
Wenn der MaxClients Wert im laufenden Betrieb erreicht wird, wird dies im Apache error.log vermerkt.
[Thu Dec 18 11:00:28 2008] [error] server reached MaxClients setting, consider raising the MaxClients 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. Es muss auf alle Fälle verhindert werden, dass der Webserver swapt.
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) log_config_module (static) logio_module (static) mpm_prefork_module (static) http_module (static) so_module (static) alias_module (shared) auth_basic_module (shared) authn_file_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgi_module (shared) dir_module (shared) env_module (shared) mime_module (shared) negotiation_module (shared) setenvif_module (shared) status_module (shared) Syntax OK
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 Logauswertungssoftware vorgenommen werden.
Nicht benötigte Apache Features deaktivieren
Wenn z.B. der Parameter AllowOverride auf "All" gesetzt wird 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 serverseite 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.
Eine Beispielkonfiguration für Apache 2.2, welche CSS und Javascript Content komprimiert ausliefert, könnte wie folgt aussehen:
FilterDeclare gzipping CONTENT_SET FilterProvider gzipping deflate Content-Type text/css FilterProvider gzipping deflate Content-Type $javascript FilterChain gzipping
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.
Apache 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.2/programs/ab.html
Spezialfall Parallels Virtuozzo
Wenn unter Virtuozzo in Version 3 virtuelle Umgebungen (VPS, VE, Container) betrieben werden, wird die durch die jeweilige Distribution mitgelieferten Apache Konfiguration durch ein Virtuozzo "post-install" Skript des Betriebssystem Templates automatisch angepasst.
Diese Anpassung minimiert den Speicherbedarf einer virtuellen Umgebung, was beim Betrieb von sehr vielen VEs auf einem einzelnen Server durchaus erwünscht sein kann, beim Betrieb einer gutbesuchten Webseite aber sehr schnell zu Engpässen führt.
Hier sehen Sie einen Auszug des Debian 5 post-install Skripts.
/vz/template/debian/5.0/x86/config/os/default/post-install
...
# apache tuning
CFG_FILE=etc/apache2/apache2.conf
if [ -f $CFG_FILE ]; then
sed -e "s/^[[:blank:]]*StartServers[[:blank:]]*.*/StartServers 1/" \
-e "s/^[[:blank:]]*MinSpareServers[[:blank:]]*.*/MinSpareServers 1/" \
-e "s/^[[:blank:]]*MaxSpareServers[[:blank:]]*.*/MaxSpareServers 5/" \
-e "s/^[[:blank:]]*ServerLimit[[:blank:]]*.*/ServerLimit 10/" \
-e "s/^[[:blank:]]*MaxClients[[:blank:]]*.*/MaxClients 10/" \
-e "s/^[[:blank:]]*MinSpareThreads[[:blank:]]*.*/MinSpareThreads 1/" \
-e "s/^[[:blank:]]*MaxSpareThreads[[:blank:]]*.*/MaxSpareThreads 4/" \
$CFG_FILE > ${CFG_FILE}.$$ && \
move_file ${CFG_FILE}.$$ $CFG_FILE > /dev/null 2>&1
fi
...
Genau diese Werte müssen entsprechend erhöht werden, um die Webseiten für mehr Besucher vorzubereiten. Vorallem der Wert MaxClients und ServerLimit sollte unbedingt von 10 auf einen höheren Wert gesetzt werden, ansonsten sind nur 10 gleichzeitige Clientverbindungen mit dem Webserver möglich. Sinnvoll ist es auch die Werte für StartServers, MinSpareServers bzw. MinSpareThreads entsprechend zu erhöhen, damit für neue Anfragen bereits Apache Prozess zur Verfügung stehen und diese nicht erst extra erstellt werden müssen.
Weiter oben im Beitrag finden Sie Empfehlungen für die jeweiligen Werte.
Ein weiterer Grund für Performance Engpässe können Ressourcen Limitierungen unter Virtuozzo sein. Sie finden innerhalb des VEs die Datei /proc/user_beancounters. In dieser Datei finden Sie in der letzten Spalte "failcnt" einen Counter welche anzeigt wie oft Ressourcenübertretungen aufgetreten sind.
Hier ein Beispielauszug.
/proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
3007: kmemsize 2483745 2546680 57490800 59160657 0
lockedpages 0 0 1024 1024 0
privvmpages 178824 178853 262144 278528 0
shmpages 16 16 86016 86016 0
dummy 0 0 0 0 0
numproc 51 52 960 960 0
...
Informationen zur Ressourcen Konfiguration finden Sie in der Virtuozzo Dokumentation.
