Benchmarking von Apache und Lighttpd
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.
Inhaltsverzeichnis
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.
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.
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)