Web-Server

ID #1053 Hochleistungs-Apache: Performance-Tuning

Apache am Ende?

Apache gilt als der beste Webserver für Linux/Unix. Ist er wahrscheinlich auch. Gerade in der Version 2, bei der deutlich mehr Konfigurationen möglich sind. Aber sobald der Indianer eine Menge zu tun bekommt kann er schon mal das ganze System in die Knie zwingen. Daher hier ein paar Tipps für ausgelastete Apache.
Bitte bedenkt aber, daß die Optimierung immer ein dynamischer Prozess ist! (Siehe Punkt e.)

Apache aufbohren, tieferlegen, tunen

Es sind zwei wesentliche Dinge, die den Apache beschleunigen und damit schnelleres Arbeiten erlauben:
a) Speicherverbrauch minimieren.
b) Speicher besser aufteilen und Requests beschränken.
c) Finetuning
d) Testing
e) Beobachtung

Die erste Station lässt sich meistens leicht entscheiden, ob man gewisse Module braucht oder nicht.
Schwieriger wird es bei Punkt b) und c). Hier gibt es keine allgemeine Aussagen á la "Bei XX-Usern in YY-Forum auf ZZ-Hardware braucht man folgende Einstellungen." Jeder der so etwas behauptet (oder hier sucht) liegt Grundsätzlich falsch.
Der Tuning-Prozess ist immer eine eigenständige Entwicklung und muß an die Gegebenheiten angepasst werden. Hier braucht man etwas Experimentierfreudigkeit und Geduld.

a) Entschlackung:

Der Apache kann mit Modulen vielseitig erweitert werden. Nachteil: Die Module nehmen Speicher und Performance in Anspruch. Denn jeder Request durchläuft fast alle Module, welche jeweils prüfen, ob es damit etwas zu tun hat. D.h. daß auch pro Request von jedem Modul Speicher angefordert wird.
Die vorinstallierte Apache-Conf der jeweiligen Linux-Distribution ist für die "breite Masse" ausgelegt und i.d.R. nicht für den jeweiligen in Betrieb befindlichen Server.

Hier ein kleiner Auszug aus möglichen Modulen die Sinn oder weniger Sinn haben:

  • Braucht man Server-Auth? Wenn ja welche?
    Meistens wird nur mod_auth benötigt.
  • Dynamische Seiten:
    + mod_log_config erlaubt die access_log-Dateien in div. Formaten.
    + mod_cgi braucht man, wenn man CGI zulassen will.
    + mod_suexec erlaubt CGIs als ein bestimmter User zu laufen.
    - mod_perl braucht man nicht um Perl als CGI auszuführen!
    + mod_php4 (5) ist schneller als PHP als CGI (aber nicht so sicher).
    - mod_include erlaubt die Verwendung von SSI.
  • URL-Manipulationen:
    + mod_alias braucht man zum Einblenden von virtuellen Verzeichnissen.
    - mod_rewrite erlaubt URL-Manipulationen, kostet aber Performance.
    - mod_autoindex & mod_dir erlauben eine Navigation ohne index.html
    - mod_userdir erlaub User-URLs mit z.B.: www.huschi.net/~huschi/
    - mod_negotiation analysiert Accept-Anfragen.
    + mod_vhost_alias erlaubt das Anlegen von virtuellen Hosts.
  • Environment- & Header-Manipulation:
    + mod_mime setzt automatisch den richtigen Header anhand der Dateiendung.
    - mod_env & mod_setenvif erlauben die modifizierung von ENV-Variablen.
    - mod_expires erlaubt die HTTP-Header Manipulation des Expires-Date.
    - mod_ssl erlaubt die Verwendung von SSL (https).

b) MPM Tuning:

Beispiel für ein MPM-Prefork welcher knapp 500 (Massenhosting-)Webs auf einen 2GHz-Server mit 2 GByte Speicher verwaltet inkl. mod_php, CGI, rewrite, etc.:

StartServers         5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 150
MaxClients 150
MaxRequestsPerChild 0

Der Parameter MaxClients entspricht den maximal simultan abzuarbeitenden Request. Er kann nicht höher als ServerLimit sein. Wenn diese Anzahl an simultanen Prozessen ausgeschöpft ist, werden weitere Requests nicht verworfen sondern ein eine Warteschlange (queue) eingereiht welche dann entsprechende längere Antwortzeiten haben.

Im Laufe der Zeit hat sich eine Faustregel für den Prefork-MPM manifestiert:
Ein Apache-Prozess benötigt rund 12 MB Speicher. 12 MB mal MaxClients ist dann der Speicher den man (ohne Swap) frei haben sollte.

Normale Root-Server und vorallem virtuelle Server sollten den MaxClients-Wert möglichst gering halten. Hier ist mod_status zur Analyse des realen Bedarfs sehr Hilfreich.

Zusätzlich hat hier ein KeepAlive Off den Server vor dem Abrauchen bewart.
Wer mag, kann natürlich versuchen den KeepAlive mit einem entsprechend kleinen TimeOut (hier 2 Sekunden) zu setzen:

KeepAlive On
KeepAliveTimeout 2
MaxKeepAliveRequests 10

c) Finetunig:

  • Vermeiden von DNS-Lookups: HostNameLookups off
    Denn erstmal jede Client-IP auf seinen Hostnamen aufzulösen ist unnötig und kostet nur Zeit.
  • Vermeiden von .htaccess-Dateien:
    Diese Dateien werden pro Request geprüft! Und zwar den ganzen Verzeichnispfad von DocumentRoot bis zum Ziel-Verzeichnis.
    Die Direktiven von dort sollte man also am besten in die Apache-Config übernehmen und mit AllowOverride None sucht Apache erst gar nicht nach .htaccess-Dateien.

d) Performance-Test:

Hierfür bietet sich das von Apache mitgelieferte ab2 an. Damit kann man einige Requests in Serie abfeuern und erhält direkt eine statistische Auswertung.
Auch hier gilt: Es gibt keine Normwerte die ein Server erfüllen muß! Das Tool sehe ich eher als Erfolgstest an, um die neuen Parameter zu testen. Es simuliert auch keine echten Benutzer/Surfer auf dem Server.

e) Beobachtung

Weitere Optimierungsschritte finden sich schnell, wenn man den Server vernünftig beobachtet. Dazu nutzt man mod_status im ExtendedStatus On Modus.
Besondere Beachtung sollten Scripte (PHP/Perl/etc.) haben. Sollte hier vereinzelt die CPU-Zeit oder Laufzeit extrem hoch gehen, wird eine gewisse Aktivität erforderlich.

weiter Links:

  1. huschi.net: Apache-Optimierung auf HTTP-Ebene
  2. Apache HTTP-Server: Modul-Index
  3. Linux-Magazin 2004/01: Häuptling Schnelles Wiesel
  4. Linux-NetMag: Configuring Apache for Maximum Performance (2006)
    (Link verlegt auf berlios.de)

 

sozial Bookmarking
Bookmarken bei YIGG Bookmarken bei Mister-Wong Bookmarken bei Icio Bookmarken bei del.icio.us Bookmarken bei Technorati Bookmarken bei Furl Bookmarken bei Spurl Bookmarken bei Yahoo Bookmarken bei Google

vom 2006-01-20 10:01, zuletzt 2009-06-29 14:13     Artikel ausdrucken Artikel weiterempfehlen Als PDF-Datei anzeigen

Dieser Inhalt ist unter der Creative-Commons Lizenz lizensiert.

Probleme bitte im Server-Support-Forum diskutieren.

überflüssig 1 2 3 4 5 wertvoll  
Durchschnittliche Bewertung:   4.41 von 5 (17 Bewertungen)

Artikel kommentieren

Kommentar von suther (2008-03-26 11:44:21):
Der Artikel ist gut, besser wäre er, wenn direkt angegeben würde, in welchen Dateien die jeweiligen Änderungen vorzunehmen sind.

Kommentar von d.mueller (2008-03-31 23:24:08):
Klasse Artikel.
Hab meinen Apache minimiert und konnte den Speicher gut ausnutzen.

An meinen Vorredner:
Wenn Huschi hier alles Mundgerecht vorkauen würde, könnte man die Howto's nicht mehr lesen. :)

Kommentar von ChristianS (2009-06-29 16:20:37):
mod_expires halte ich durchaus für sinnvoll, denn damit lassen sich Verfallsdaten für statische Dateien steuern. JavaScript, CSS und verzierende Grafiken ändern sich in der Regel nicht täglich und können durch mod_expires gemütlich im Browser-Cache vorgehalten werden. Als Folge davon müssen diese Requests für die Cache-Dauer nicht mehr vom Apache beantwortet werden, was ihm eine Entlastung bringt.

Kommentar von huschi (2009-06-29 22:54:13):
@ChristianS
Sicher ist mod_expire sinnvoll. Aber eben nur wenn man es auch nutzt.
Solange man keine passenden Direktiven einsetzt, ist das Modul nur ein Speicherfresser.

huschi.

Kommentar von Mark (2013-05-16 13:39:24):
Der Artikel ist ja schon älter. Wie wäre es mit einer Anpassung oder Neuauflage für heutige Server?

Da fallen mir so Sachen ein wie worker Apache.....