Benchmarking von Apache und Lighttpd

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Zum Vergleich der Performance von eStudy im Betrieb mit Apache und Lighttpd soll ein Benchmarking beider Webserver erfolgen. Dabei wird von einem bereits funktionsfähigen, installierten Apache ausgegangen, so dass nur noch die Installation von Lighttpd nötig ist.

Installation von Lighttpd

Grundinstallation

Die Installation von Lighttpd in Debian erfolgt entweder durch das Kompilieren der Quellen oder mit Hilfe des Paketmanagers von Debian. In diesem Fall kommt letztere Variante zum Einsatz. Nach dem Update des Repositories mit

apt-get update

wird zunächst die CGI-Version von PHP5 installiert, da Lighttpd mit FastCGI arbeitet.

apt-get install php5-cgi

Danach kann Lighttpd installiert werden.

apt-get install lighttpd

Anschliessend wird Lighttpd für die Benutzung von PHP5-CGI konfiguriert. Dazu ist es zunächst notwendig, an das Ende der Datei

/etc/php5/cgi/php.ini 

die folgende Zeile hinzuzufügen.

cgi.fix_pathinfo = 1

In der Konfigurationsdatei von Lighttpd

/etc/lighttpd/lighttpd.conf 

wird nun das Modul mod_fastcgi aktiviert, indem es an die oberste Stelle der Modul-Liste hinzugefügt oder, falls schon enthalten, auskommentiert wird.

server.modules = ( 
  "mod_fastcgi",
  "mod_access",
  "mod_alias",
  "mod_accesslog",
 #"mod_rewrite", 
 #"mod_deflate",
 #"mod_redirect", 
 #"mod_status", 
 #"mod_evhost",
 #"mod_compress",
 #"mod_usertrack",
 #"mod_rrdtool",
 #"mod_webdav",
 #"mod_expire",
 #"mod_flv_streaming",
 #"mod_evasive"
)

An das Ende der Datei werden nun noch die Einstellungen für das Arbeiten von FastCGI zusammen mit Lighttpd hinzugefügt.

# Bindung an FastCGI mit Default-Einstellungen
fastcgi.server = ( ".php" => ((
  "bin-path" => "/usr/bin/php5-cgi",
  "socket" => "/tmp/php.socket",
  "min-procs" => 1,
  "max-procs" => 5,
  "max-load-per-proc" => 4,
  "idle-timeout" => 20
)))

Danach sollte Lighttpd bereits lauffähig sein und kann mit

/etc/init.d/lighttpd start

gestartet werden. Falls, wie in diesem Fall, Apache bereits läuft, muss dieser zunächst beendet werden, da beide Webserver den Port 80 beziehungsweise 443 für SSL benutzen sollen. Aus Sicherheitsgründen wird außerdem das Directory-Listing deaktiviert.

# virtual directory listings 
dir-listing.encoding = "utf-8" 
server.dir-listing = "disable"

Zusätzliche Module

Für nahezu alle Module von Apache existieren äquivalente und meist namensgleiche Module für Lighttpd. Für das anstehende Benchmarking sollen deshalb die Module mod_ssl, mod_expire und mod_deflate für Lighttpd installiert und den Einstellungen in Apache entsprechend konfiguriert werden.

Das Modul mod_expire wurde in der Liste der Module zunächst auskommentiert.

server.modules = ( 
  "mod_fastcgi",
  "mod_access",
  "mod_alias",
  "mod_accesslog",
 #"mod_rewrite", 
 #"mod_deflate",
 #"mod_redirect", 
 #"mod_status", 
 #"mod_evhost",
 #"mod_compress",
 #"mod_usertrack",
 #"mod_rrdtool",
 #"mod_webdav",
  "mod_expire",
 #"mod_flv_streaming",
 #"mod_evasive"
)

Anschliessend wurde mod_expire für das Caching von Bildern, Java-Scripts und Stylesheets konfiguriert.

# Expire images, static text in 24 hours 
$HTTP["url"] =~ "\.(png|jpg|gif|js|css)$" { 
  expire.url = ( "" => "access 7 days" ) 
}

Für den Einsatz von SSL in Lighttpd genügt es, mit den folgenden Einstellungen die SSL-Engine auf Port 443 zu aktivieren und auf die .pem-Datei des benutzten SSL-Zertifikats zu verweisen.

$SERVER["socket"] == ":443" { 
  ssl.engine = "enable" 
  ssl.pemfile = "/etc/ssl/certs/lighttpd.pem" 
}

Anstelle des Moduls mod_compress, das die Komprimierung von dynamischen Webseiten nicht unterstützt, soll wie für Apache das Modul mod_deflate zum Einsatz kommen. Da mod_deflate in diesem Fall von der über das Debian-Paketsystem installierten Lighttpd-Version 1.4 noch nicht unterstützt wurde, musste dieses zunächst installiert werden und außerdem ein Patching von Lighttpd vorgenommen werden. Eine sehr genaue Anleitung dazu findet sich unter http://www.howtoforge.de/howto/bandbreite-sparen-mit-mod_deflate-auf-lighttpd-14-debian-etch/. Ab Lighttpd 1.5 ist mod_deflate jedoch bereits integriert und kann direkt eingesetzt werden. Die Aktivierung von mod_deflate erfolgt anschliessend wie üblich durch das Hinzufügen beziehungsweise das Auskommentieren des entsprechenden Eintrages in der Modul-Liste von Lighttpd.

server.modules = ( 
  "mod_fastcgi",
  "mod_access",
  "mod_alias",
  "mod_accesslog",
 #"mod_rewrite", 
  "mod_deflate",
 #"mod_redirect", 
 #"mod_status", 
 #"mod_evhost",
 #"mod_compress",
 #"mod_usertrack",
 #"mod_rrdtool",
 #"mod_webdav",
  "mod_expire",
 #"mod_flv_streaming",
 #"mod_evasive"
)

Die Konfiguration von mod_deflate wurde wie folgt vorgenommen. Dabei sollen, wie auch in Apache, HTML-Seiten, PHP-Seiten, Stylesheets und Java-Scripts sowie XML-Dateien vom Webserver komprimiert ausgeliefert werden.

deflate.enabled = "enable" 
deflate.compression-level = 9 
deflate.mem-level = 9 
deflate.window-size = 15 
# deflate.bzip2 only in patch for 1.4.x 
deflate.bzip2 = "enable" 
# deflate.allowed_encodings only in 1.5.x 
#deflate.allowed_encodings = ( "bzip2", "gzip", "deflate" ) 
deflate.min-compress-size = 200 
#deflate.sync-flush = "enable" 
deflate.output-buffer-size = 4096 
deflate.work-block-size = 512 
deflate.mimetypes = ("text/html", "text/php", "text/plain", "text/css", 
  "text/javascript", "application/x-javascript", "text/js", "text/xml") 
#deflate.debug = "enable"

eAccelerator

Da eAccelerator für den Betrieb von Apache zum Einsatz kommt, soll auch Lighttpd davon profitieren. Die Konfiguration von eAccelerator erfolgt für die CGI-Version von PHP5 in der Datei

/etc/php5/cgi/php.ini

und muss dort ergänzt werden. Die Einstellungen sind identisch mit denen für den Betrieb des normalen PHP.

extension="eaccelerator.so"
eaccelerator.shm_size="32"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

APC

Als Alternative zu eAccelerator bietet sich APC, den Alternative PHP Cache an. Dieser hat den Vorteil, dass er derzeit (Januar 2010) auch unter PHP >= 5.3.1 funktioniert und nicht unerklärliche Fehler verursacht, die PHP an der Ausführung hindern.

Benchmarking

Testumgebung

Die lasterzeugenden Anwendungen Apache Bench und JMeter wurden auf einem vom Test-Server getrennten Rechner, dem Test-Client, gestartet. Der Test-Server enthielt eine parallele Installation der beiden Webserver Apache und Lighttpd, zwischen denen durch einfaches Starten und Stoppen mit

/etc/init.d/apache2 start|stop und /etc/init.d/lighttpd start|stop

umgeschaltet werden konnte. Der Test-Server besaß folgende technische Merkmale:

  • Prozessor: Intel Pentium 4 CPU 2.80GHz
  • Hauptspeicher: 2,6 GB
  • Apache/2.2.3 mit MPM Prefork bzw. Lighttpd/1.4.13
  • Datenbank: MySQL 5.0.51
  • PHP5 bzw. PHP5-CGI mit Suhosin Patch
  • PHP-Beschleuniger: eAccelerator
  • Sicherheit: mod-security2, Shorewall

Apache Bench

Als erster Schritt des Benchmarkings wurden Performance-Tests mit Hilfe von Apache Bench durchgeführt, um erste Ergebnisse über das Antwort-Zeit-Verhalten von Apache und Lighttpd zu erhalten. Dabei wurden Messungen von dynamischen Webseiten, statischen Webseiten sowie zusätzlich Bildern und PDF-Dateien unternommen.

Dynamische Webseiten

Es wurde zunächst ein Benchmarking der Startseite von eStudy mit 1000 Requests und nur einem Thread durchgeführt.

Staudt@estudy-portal:~$ /usr/sbin/ab2 -n 1000 -c 1 http://portal.mni.fh-giessen.de/benchmark/web/index.php

Dabei zeigte sich bereits, dass Lighttpd 30 ms vor Apache liegt.

Apache Lighttpd
Req/s 1,95 2,08
Time/Req [ms] 511 480

Anschliessend erfolgte eine Messung mit 1000 Requests und 10 gleichzeitigen Threads.

Staudt@estudy-portal:~$ /usr/sbin/ab2 -n 1000 -c 10 http://portal.mni.fh-giessen.de/benchmark/web/index.php

Diese hatte zum Ergebnis, dass Lighty ca. 300 ms schneller war als Apache.

Apache Lighttpd
Req/s 2,71 2,96
Time/Req [ms] 3690 3379

Der höhere Speicherverbrauch von Apache war dabei auf die größere Anzahl von gestarteten Prozessen zurückzuführen. Während Lighttpd mitsamt der 8 gestarteten PHP5-CGI-Instanzen nur 87 MB verbrauchte, brachte Apache es mit 20 Prozessen bereits auf satte 260 MB.

Statische Webseiten

Es wurde eine statische HTML-Seite mit 10000 Requests und 50 gleichzeitigen Threads aufgerufen.

Staudt@estudy-portal:~$ /usr/sbin/ab2 -n 10000 -c 50 http://portal.mni.fh-giessen.de/statisch.html

Es zeigte sich, dass Lighttpd auch hier punkten konnte mit knapp 30 ms Vorsprung gegenüber Apache.

Apache Lighttpd
Req/s 292,85 353,24
Time/Req [ms] 171 142

Während Apache 34 Prozesse startete und somit 136 MB Speicher belegte, verbrauchte Lighttpd zusammen mit 8 PHP-CGI-Instanzen nur 39 MB.

Weitere Messungen

Bild (20 KB)

Es wurde ein Bild mit 10000 Requests und 50 gleichzeitigen Threads aufgerufen.

Staudt@estudy-portal:~$ /usr/sbin/ab2 -n 10000 -c 50 http://portal.mni.fh-giessen.de/fh-logo.png

Die durchschnittlichen Messwerte waren hierbei nahezu gleich.

Apache Lighttpd
Req/s 382,99 387,49
Time/Req [ms] 130 129

PDF-Datei (100 KB)

Es wurde eine PDF-Datei mit 10000 Requests und 50 gleichzeitigen Threads aufgerufen.

Staudt@estudy-portal:~$ /usr/sbin/ab2 -n 10000 -c 50 http://portal.mni.fh-giessen.de/dokument.pdf

Dabei zeigte sich wie bereits bei den Messungen mit einem Bild keine besonderen Unterschiede (max. 20 ms).

Apache Lighttpd
Req/s 88,93 91,65
Time/Req [ms] 562 545

Dynamische Webseite ohne Einsatz von eAccelerator

Die Messungen der dynamischen Webseite wurden zusätzlich ohne den Einsatz von eAccelerator vorgenommen. Dazu wurden 1000 Requests mit 10 gleichzeitigen Threads gestartet.

Staudt@estudy-portal:~$ /usr/sbin/ab2 -n 1000 -c 10 http://portal.mni.fh-giessen.de/benchmark/web/index.php

Während die Messungen mit eAccelerator bereits einen Vorsprung von 300 ms ergaben, zeigte sich ohne den Einsatz von eAccelerator mit 400 ms Unterschied ein noch größerer Vorsprung von Lighttpd gegenüber Apache.

Apache Lighttpd
Req/s 1,83 1,98
Time/Req [ms] 5475 5056

JMeter

Lasttests in eStudy

Als zweiter Schritt des Benchmarkings wurden mit JMeter Lasttests von eStudy durchgeführt. Aus den Ergebnissen wurden jeweils die durchschnittliche Antwortzeit und die durchschnittliche CPU-Belastung im Betrieb mit Apache und Lighttpd ermittelt. Für das Server-Monitoring kam dabei das Shell-Script performanceAnalyzer.sh zum Einsatz. Es wurden pro Durchgang und Art des Webservers mindestens vier Lasttests mit einer jeweiligen Dauer von einer Stunde durchgeführt.

  • Der erste Durchgang erfolgte mit einer relativ leichten Last von 15 gleichzeitigen Benutzern, was bei beiden Servern eine CPU-Belastung von ca. 50 Prozent hervorrief. In den Antwortzeiten zeigte sich bereits, dass Lighttpd gegenüber Apache einen geringen Vorsprung von 50 ms bis 100 ms hat.
  • Daraufhin wurde die Last auf 25 gleichzeitige Benutzer erhöht, was auf beiden Servern eine durchschnittliche CPU-Belastung von 84 Prozent zur Folge hatte. Allerdings zeigte sich in den Antwortzeiten nun ein deutlicherer Unterschied zwischen Apache und Lighttpd. Lighttpd war durchschnittlich 300 ms schneller als Apache.

Benchmarking-JMeter.png

Gesamtergebnis

Insgesamt zeigte sich, dass Lighttpd besonders bei dynamischen Webseiten schneller arbeitet als Apache. Der Speicherverbrauch ist aufgrund des Threadings und der geringeren Anzahl gestarteter PHP5-CGI-Instanzen gegenüber der Anzahl der Apache-Prozesse außerdem wesentlich kleiner. Es konnte jedoch kein Vorteil hinsichtlich der CPU-Belastung festgestellt werden. Diese war in allen Messungen fast identisch, was sehr wahrscheinlich darauf zurückzuführen ist, dass der größte Teil des CPU-Verbrauchs in eStudy auf der Ausführung von MySQL-Queries beruht. Benchmarking-Gesamt.png

Fazit

Meinung des Autors: Nach der Auswertung der Test-Ergebnisse des Benchmarkings von Apache und Lighttpd erscheint es sinnvoll, jedoch nicht unbedingt notwendig, Lighttpd zu benutzen. Da die Verarbeitung von dynamischen Webseiten jedoch etwas schneller durchgeführt wird und der Speicherverbrauch von Lighttpd unter hoher Belastung wesentlich geringer ist, zeigt sich darin ein Vorteil für die Lernplattform eStudy, da diese fast ausschließlich auf dynamischen Webseiten basiert. Mit einer Entlastung der CPU ist jedoch nicht zu rechnen.

Weblinks

--Staudt-FSt 12:03, 1. Aug. 2008 (UTC)