Open Source im professionellen Einsatz
Linux-Magazin 08/2015
© lightpoet, 123RF

© lightpoet, 123RF

Performance-Tuning für den Apache-Webserver

Pfeilschnell

Das rasante Wachstum des Internets verlangt Webservern immer mehr ab. Kann Apaches altgedienter HTTP-Server hier noch mithalten? Er kann – wenn der Admin den Bogen raus hat.

1489

Apaches HTTP-Server bleibt der meistgenutzte Webserver im Internet [1], auch wenn die erste Version bereits vor zwei Jahrzehnten erschien – im April 1995. Das liegt auch daran, dass ihn das Projekt ständig weiterentwickelt. Er punktet im Wettbewerb zudem durch seinen modularen Aufbau und die damit einhergehende große Funktionsvielfalt.

Doch die Konkurrenz schläft nicht, und so sind seit ein paar Jahren alternative Webserver auf dem Vormarsch, allen voran Nginx. Das entging auch der Apache Software Foundation nicht, weshalb sie sich für Version 2.4 das Ziel setzte, in puncto Performance wieder den Anschluss an Nginx zu finden.

Ob das gelungen ist, darüber streiten die Fachleute. Fakt ist, dass die neue Version die alte in Sachen Performance überflügelt. Das belegt unter anderem ein Vergleich der Webserver-Versionen von Debian Wheezy (2.2.22) und Debian Jessie (2.4.10). Wie Abbildung 1 zeigt, arbeitet der Server in Version 2.4 eine Million Zugriffe etwa 20 Sekunden schneller ab als die Vorgängerversion 2.2.

Abbildung 1: Bereits in der Standardkonfiguration zeigt sich Apaches HTTP-Server unter Debian Jessie performanter als unter Debian Wheezy.

Unter Jessie haben die Tester dazu anstelle des Multi Processing Module Event (MPM) das MPM Worker aktiviert, um das gleiche Modul zu verwenden. Getestet haben sie den direkten Zugriff auf »localhost« in einer Virtualbox-VM mit 512 MByte RAM. Beim Vergleich kam Apaches Benchmarktool »ab« [2] zum Einsatz, das jeweils auf eine Textdatei mit dem Inhalt »hello world« zugriff.

Wie performant der Server eine Webseite ausliefert, hängt allerdings noch von anderen Faktoren ab. So verwenden die Webapplikationen meist Skriptsprachen wie PHP und Perl, hinzu kommen Datenbankabfragen (etwa über MySQL). Ein Admin sollte im Hinterkopf behalten, dass auch sie nicht selten die Performance ausbremsen.

Wer den Apachen tunen möchte, sollte jedoch ein paar Dinge beachten. Um sich beispielsweise auf einem Produktivsystem beim Experimentieren nicht die bestehende Konfiguration zu zerschießen, versioniert der Admin diese am besten mit »etckeeper« [3]. Außerdem testet er neue Konfigurationen noch vor einem Neustart oder Reload des Dienstes besser über »apache2ctl -t« auf syntaktische Korrektheit.

RAM, RAM, nochmals RAM

Jeder HTTP-Prozess auf dem Webserver benötigt einige MByte RAM. Daher ist es für viele Zugriffe essenziell, dass ausreichend Arbeitsspeicher verfügbar ist. Reicht der nicht aus, beginnt der Server zu swappen, er lagert den Arbeitsspeicher auf die Festplatte aus. Weil der Datendurchsatz von Festplatten selbst in Zeiten von SSDs noch immer um ein Vielfaches langsamer ist als der des RAM, sollte der Admin das nach Kräften verhindern.

Unter Linux bedeutet mehr RAM zugleich, dass der Kernel einen größeren Pagecache halten kann, was I/O-Abfragen massiv beschleunigt. Auch dies sollte der Admin bei der RAM-Dimensionierung berücksichtigen. Des Weiteren muss er die Apache-Konfiguration auf den verfügbaren Arbeitsspeicher abstimmen. Erlaubt er zu viele Prozesse, ist der verfügbare Speicher schnell aufgebraucht. Für das MPM Prefork bietet sich die Formel aus Abbildung 2 an.

Abbildung 2: Die Anzahl der Prozesse auf einem Apache-Server sollte der Admin an die Größe des verfügbaren RAM anpassen.

Die einzelnen Werte kann der Admin zum Beispiel über »top« ermitteln (Abbildung 3). Indem er [Shift]+[M] drückt, zeigt »top« die Prozesse sortiert nach Speicherbedarf an. In der Spalte »RES« erscheint der tatsächliche Arbeitsspeicherbedarf der Prozesse.

Abbildung 3: Das Linux-Standardtool top zeigt die Prozesse des HTTP-Servers an.

Im Beispielsetup standen insgesamt 16 GByte RAM zur Verfügung. MySQL benötigte 39 MByte, der größte Apache-HTTP-Prozess gerade mal 22 MByte. Den Nameserver Bind kann der Admin vernachlässigen, er beansprucht nicht einmal 1 MByte RAM.

Zieht der Administrator hier also die in der Abbildung 2 vorgestellte Formel heran und für das Betriebssystem 100 MByte sowie für MySQL noch mal 50 MByte ab und sieht zugleich für den Pagecache 2 GByte vor, kommt er am Ende auf einen Wert von 644 für »MaxRequestWorkers« . Diese Variable legt fest, wie viele Anfragen der Server im Ernstfall zeitgleich abarbeiten kann.

Um dem Server im Ernstfall etwas Luft zu verschaffen, wäre im konkreten Fall ein Maximum von 400 Zugriffen eine gute Wahl. Alternativ kann der Serverbetreiber auch kleine Helfer einsetzen, welche die Kalkulation übernehmen (siehe Kasten "Apachebuddy.pl").

Apachebuddy.pl

Das Perl-Skript »apachebuddy.pl« gibt automatisiert Tipps, die einem Admin dabei helfen, den Apachen in Bezug auf den Arbeitsspeicher zu konfigurieren. Listing 1 zeigt einen Auszug von einem Webserver, der noch unter Debian Squeeze LTS läuft.

Listing 1

apachebuddy.pl

01 root@testserver:~# wget apachebuddy.pl -O apachebuddy.pl
02 root@testserver:~# perl apachebuddy.pl
03 ######################################################################
04
05 # Apache Buddy v 0.3 #################################################
06
07 ######################################################################
08
09 Gathering information...
10 We are checking the service running on port 80
11 The process listening on port 80 is /usr/sbin/apache2
12 The process running on port 80 is Apache/2.2.16 (Debian)
13 Apache has been running 7d 01h 39m 11s
14 The full path to the Apache config file is: /etc/apache2/apache2.conf
15 Apache is using prefork model
16
17 Examining your Apache configuration...
18 Apache runs as apache
19 Your max clients setting is 150
20
21 Analyzing memory use...
22 Your server has 16024 MB of memory
23 The largest apache process is using 30.59 MB of memory
24 The smallest apache process is using 15.01 MB of memory
25 The average apache process is using 20.53 MB of memory
26 Going by the average Apache process, Apache can potentially use 3079.51 MB RAM (19.22 % of available RAM)
27 Going by the largest Apache process, Apache can potentially use 4588.51 MB RAM (28.64 % of available RAM)
28
29 Generating reports...
30 ### GENERAL REPORT ###
31
32 Settings considered for this report:
33
34         Your server's physical RAM:             16024MB
35         Apache's MaxClients directive:          150
36         Apache MPM Model:                       prefork
37         Largest Apache process (by memory):     30.59MB
38 [ OK ]  Your MaxClients setting is within an acceptable range.
39         Max potential memory usage:             4588.5 MB
40
41         Percentage of RAM allocated to Apache   28.64 %
42
43 -----------------------------------------------------------------------
44

Multiprocessing-Module

Apache HTTP unterstützt in Version 2.4 unter Linux drei verschiedene Multiprocessing-Module (MPM):

  • Prefork
  • Worker
  • Event

Seit Version 2.4 kann der Server MPMs zudem zur Laufzeit laden.

Das MPM Prefork (Modulname: »mod_mpm_prefork.so« ) kommt ohne Threads aus. Für jeden Zugriff existiert ein eigener Prozess im System. Beim Einsatz von PHP als Apache-Modul ist dies im Normalfall die einzige Option für den Betrieb, denn in PHP gibt es zu viele Bibliotheken von Drittanbietern, die noch nicht Thread-safe sind [4].

Wer ein Threaded MPM zusammen mit PHP verwenden möchte, kann dies mit Fast CGI und PHP-FPM realisieren. Ob sich der Umstieg lohnt, ist aus Performancesicht jedoch fraglich. Die Vorteile durch das Threaded MPM verlieren sich aufgrund der Performance-Nachteile, die eine PHP-Integration über Fast CGI nach sich zieht, teilweise wieder [5].

Die folgenden Optionen sind beim MPM Prefork relevant:

  • »StartServers«
  • »MinSpareServers« , »MaxSpareServers«
  • »MaxRequestWorkers«
  • »ServerLimit«
  • »MaxConnectionsPerChild«

»StartServers« legt fest, wie viele Prozesse der Webserver nach einem Neustart vorweg starten soll. »MinSpareServer« und »MaxSpareServers« bestimmen, wie viele unbenutzte Prozesse Apache mindestens vorhalten soll beziehungsweise maximal vorhalten darf. »MaxRequestWorkers« (bis 2.3.13 »MaxClients« ) limitiert die maximale Prozessanzahl und somit die Anzahl der gleichzeitigen Zugriffe. Beachtenswert ist auch die Direktive »ServerLimit« , die eine Obergrenze für »MaxRequestWorkers« festlegt, der Standardwert liegt bei »256« .

Wer für »MaxRequestWorkers« einen größeren Wert erwartet, muss die Direktive »ServerLimit« parallel dazu erhöhen. »MaxConnectionsPerChild« legt fest, wie viele Verbindungen ein einzelner Prozess abarbeiten darf. In einer perfekten Welt ist der Wert 0, was bedeutet, dass der Server Prozesse für alle folgende Requests nie neu startet. Bei umfangreichen Applikationen kann es jedoch sinnvoll sein, Prozesse nach ein paar Hundert Verbindungen wieder zu erneuern. Das gibt den vom Prozess verwendeten RAM-Bereich wieder frei, was Memory Leaks vorbeugt. Reichen die konfigurierten »MaxRequestWorkers« nicht aus, erscheint im Logfile die Meldung aus Listing 2.

Listing 2

Logfile-Meldung

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

Ohne PHP-Modul kann der Admin ein Threaded MPM ohne Bedenken einsetzen. Dadurch arbeitet der Server einen Zugriff durch einen einzelnen Thread ab statt durch einen einzelnen Prozess. Da ein Thread weniger Overhead erzeugt als ein Prozess, erreicht der Server so eine bessere Performance.

Unter Apache stehen zwei Threaded MPMs bereit. Mit Version 2.0 haben die Entwickler MPM Worker (Modulname: »mod_mpm_worker.so« ) eingeführt, seit Version 2.2 gibt es ein zusätzliches Threaded MPM namens Event (Modulname: »mod_mpm_event.so« ), das seit Apache 2.4 als stabil gilt.

Die wichtigsten Optionen für MPM Worker und Event sind identisch:

  • »ThreadsPerChild«
  • »MinSpareThreads« , »MaxSpareThreads«
  • »MaxRequestWorkers«
  • »ServerLimit«

»ThreadsPerChild« legt fest, wie viele Threads ein einzelner Prozess erstellen darf. »MinSpareThreads« und »MaxSpareThreads« funktionieren analog zu den oben erwähnten Direktiven »MinSpareServers« und »MaxSpareServers« .

»MaxRequestWorkers« limitiert die gesamte Anzahl an Threads. Der Standardwert von »ServerLimit« liegt im Falle von Threaded MPMs bei 16. Multipliziert der Admin »ThreadsPerChild« (Standard: 25) mit »ServerLimit« (Standard: 16), erhält er das obere Limit für die Anzahl an Threads. Die Default-Einstellung erlaubt somit einen Wert von maximal 400 Threads für »MaxRequestWorkers« .

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 6 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Apache 2.4

    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.

  • Der mit dem Kater tanzt

    Sowohl der Webserver Apache als auch der Servlet-Container Tomcat werden von der Apache Software Foundation gepflegt. Ein perfektes Zusammenspiel scheint daher selbstverständlich. Doch die Realität sieht anders aus. Dieser Coffee-Shop zeigt Ansätze für eine Lösung.

  • Nachfolge-Regelung

    Jetzt oder erst in ein paar Monaten steht für Administratoren der Wechsel vom Apache-Server 1.3 zu 2 ins Tipi. Dieser Beitrag nennt die wichtigen Neuerungen und gibt Entscheidungshilfen.

  • Eingriff ins Getriebe

    Wer bei der Webentwicklung alle Schritte vom Request bis zum Response im Detail kontrollieren will, muss sich tief ins Innere des Servers begeben. Perl-Programmierer greifen dafür zu Mod_perl.

  • Fit fürs Web 1.0

    Apache ist ein Klassiker: Der HTTP-Daemon läuft auf etlichen Webservern. Für die Level-1-Zertifizierung erwartet das LPI Grundkenntnisse zur Konfiguration, wie sie dieser Artikel vermittelt.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.