Benchmarks

Unter der großen Hand von Terminal.21 ist gerade ein neues Projekt am entstehen. In der Vorbereitung wollte ich wissen, wie sich so verschiedene Webserver unter den diversen Unix- und Linuxsystemen anstellen und was Apache und Co. an Performance in unterschiedlichen Umgebungen bringen.

Dabei sind ein paar ganz erstaunliche Zahlen herausgekommen, und da sich die Frage immer mal wieder stellt, werde ich hier mal kurz von meinem kleinen Experiment berichten.

Zum Test standen die Webserver Apache in Version 2 sowie Lighttpd unter den Systemen OpenSolaris, Solaris, Debian GNU/Linux und Gentoo Linux.
Testumgebung

Es ist klar, dass auf großen Serverkisten mit vielen Prozessorkernen Solaris seine Vorteile ausspielen wird. Es ist für Schrankwände konzipiert. Auf kleinen Systemen verschlechtert sich jedoch das Verhältnis von Overhead für die Verwaltung vieler Kerne und Nutzen. In Zeiten von Virtuallisierung wird man allerdings häufig auf Umgebungen mit weniger Ressourcen stoßen, die explizit für eine bestimmte Aufgabe bereitgestellt werden. Dazu kommt der Umstand, dass Webserver eher auf kleinen dedizierten Maschienen, als auf Großrechnern laufen. Ich habe mich daher für einen relativ ollen Rechner entschieden. Die Webserver sollten schnell an die Grenzen der Maschiene stoßen, um so zu sehen, wie die Systeme unter Last reagieren.

Als Testsystem diente ein AMD-Duron PC mit etwa 1GHz, 512MB RAM und einer älteren 20GB IDE-Festplatte. Das ganze wurde ohne Switches per CrossOver-Kabel an meine Arbeitsstation angebunden, auf der die eigentlichen Messungen stattfanden.

Die Tests

Unter jeder Installation wurden 3 Tests ausgeführt: Ausliefern einer statischen Website mit einer "Hallo Welt"-Überschrift. Die Anzeige von phpinfo() als Test des PHP-Interpreters und schließlich der Aufruf eines PHP-Scriptes, welches 10 unabhängige Einträge in eine PostgreSQL-Datenbank vornimmt.

Getestet wurde mit dem Benchmark-Tool des Apache-Projekts, welches in einem Testlauf 1000 Anfragen, jeweils 50 parrallel,  an den Webserver stellte:

ab -n 1000 -c 50 http://192.168.X.Y/test

Als interessante Werte wurden die vollständigen Antworten pro Sekunde sowie die durchschnittliche Reaktionszeit pro Request aufgenommen.

Die Tests eignen sich nicht, um Rückschlüsse auf die Auslegung von Serverhardware zu ziehen. Für eine solche Einschätzung ist die Betrachtung weiterer Faktoren (Größe der Website / Webapplikation, verwendetes Framework, Festplatten-Controller, Anbindung ans Netz, ...) nötig. Auch ein Rückschluss auf das Verhalten der Webserver bei Überlastung ist nicht möglich. Unter anderen Umgebungen sind grundlegend andere Ergebnisse zu erwarten. Die Tests sollen nur einen Vergleich von Webservern unter verschiedenen Betriebssystemen auf Systemen mit sehr geringer Performance darstellen.

Solaris

Solaris wurde in der aktuellen Version 10 5/09 getestet. Als Webserver kam Apache2.2 und PHP5 aus dem GlasFish Web Stack von SUN zum Einsatz. PostgreSQL 8.3 wurde direkt von den Solaris CD-Quellen installiert. Da wenig RAM zur Verfügung stand, wurde das sparsamere UFS-Dateisystem gewählt. Solaris unter ZFS sollte mit den von OpenSolaris erziehlten Werten vergleichbar sein.

"Hallo Welt"-Test: 540 Antworten / s = 1,8ms pro Antwort
"phpinfo"-Test: 78 Antworten / s = 12,8ms pro Antwort
"postgres"-Test: 14 Antworten / s = 71,5ms pro Antwort

Interessant stellte sich unter Solaris der Postgres-Test dar. Während Linux kontinuierlich Daten auf die Festplatte schreibt, schient Solaris einen Caching-Mechanismus zu verwenden. In regelmäßigen Abständen blinkte die Festplatten-LED kurz auf.

OpenSolaris

Zum Einsatz kam die aktuelle Version OpenSolaris 2009.06. OpenSolaris richtet sich zur Zeit in erster Linie an Desktop-User. Apache2.2, PHP5 und PostgreSQL 8.3 wurden direkt über den Packetmanager installiert. OpenSolaris bietet keine Auswahlmöglichkeit bzgl. des eingesetzten Dateisystems, sondern nutzt ZFS. Um die Messungen nicht durch den Verbrauch des GNOME-Desktops zu verfälschen, wurde die grafische Benutzeroberfläche deaktiviert. Leider konnte ich trotz einiger Bemühungen die PHP-Bibliothek für Postgres nicht davon abhalten, statt einer Verbindung zur Datenbank einen seltsamen Fehler von sich zu geben, der mir mitteilt, dass nicht mehr als 0 Verbindungen gleichzeitig aufgebaut werden könnten. Eine Suche im Internet führte nur zu einer Sammlung Bug-Reports, brachte aber auch keine Lösung. Daher konnte der PostgreSQL-Test nicht durchgeführt werden.

"Hallo Welt"-Test: 472 Antworten / s = 2.1ms pro Antwort
"phpinfo"-Test: 83 Antworten / s = 12ms pro Antwort
"postgres"-Test: nicht durchgeführt

Das schlechtere Ergebnis des Hallo-Welt-Tests führe ich auf die erhöhten Hardwareanforderungen von ZFS zurück. Das Ergebnis des PHP-Interpreters ist mit dem von Solaris vergleichbar.

Debain + Apache

Spannende und damit wichtigste Frage war, ob der solide Unix-Kernel von Solaris auf kleinen Systemen seine technischen Finessen auspielen kann, oder auf Grund des Overheads gegenüber Linux das Nachsehen hat.

Debian GNU/Linux wurde in aktueller Version 5.02. installiert. Apache2, PHP5 und PostgreSQL 8.3 wurden direkt über den Packetmanager als Binärpakete eingebunden. Hier die Ergebnisse:

"Hallo Welt"-Test: 765 Antworten / s = 1,3ms pro Antwort
"phpinfo"-Test: 128 Antworten / s = 7,8ms pro Antwort
"postgres"-Test: 8 Antworten / s = 118,6ms pro Antwort

GNU/Linux ist Solaris deutlich überlegen. Interessant allerdings der überaus schlechte Wert im PostgreSQL-Test. Ein Vergleich mit Gentoo-Linux wird zeigen, ob es ein spezifisches Problem des Debian-Paketes ist, oder ob der direkte und im Gegensatz zu Solaris ungepufferte Zugriff auf die Datenbank (und damit die schlechte Bandbreite der Festplatte selbst) zu einer solch schlechten Performance führt.

Debian + Lighttpd

Durchaus interessant lesen sich die Ergebnisse der Tests unter dem kleinen Webserver Lighttpd in Version 1.4, welcher auch über den Paketmanager von Debian installiert wurde. PHP wird unter Lighttpd nicht als Modul. sondern als FastCGI-Server eingebunden.

"Hallo Welt"-Test: 1760 Antworten / s = 0,6ms pro Antwort
"phpinfo"-Test: 136 Antworten / s = 7,4ms pro Antwort
"postgres"-Test: 8 Antworten / s = 125,1ms pro Antwort

Die Ergebnisse des PHP- und PostgreSQL-Tests sind vergleichbar. Das Ausliefern von statischem Inhalt gelingt Lighttpd allerdings um mehr als das Doppelte schneller als dem Apache-Webserver.

Darüber hinaus stieß ich bei den Tests unter Lighttpd auf einen mehr als interessanten Effekt: Erhöht man die Anzahl paralleler Zugriffe über einen bestimmten Wert (bei mir um die 280), steigt die Performance des PHP-Testes plötzlich rapide an. Hier der gleiche Test unter 500 statt 50 parallelen Requests:

"phpinfo"-Test: 775 Antworten / s = 1,3ms pro Antwort

Dies ist eine Verfünfachung der Performance. Ein solches Verhalten konnte ich unter Apache nicht hervorrufen. Eine Erhöhung der parallelen Anfragen führt dort zu keinen Veränderungen der Ergebnissen. Ich freue mich über Erklärungen dieses Phänomens.

Gentoo + Apache

Unter Gentoo GNU/Linux werden alle Pakete aus den Quellen compiliert. Auch der Kernel wird selbst erstellt und an die Hardware angepasst. Ich war neugierig, ob sich diese Tatsache auf die Performance des Webservers auswirkt.

Zum Einsatz kam die etwas angestaubte, aber aktuelle Version 2008.0 in der Hardened-Variante. Die gcc-flags wurden auf den Duron-Prozessor optimiert, Apache2, PHP5 und PostgreSQL mit dem Gentoo-Paketmanager aus den Quellen compiliert. Das PostgreSQL-Paket ist in Version 8.3 maskiert, sodass die Version 8.1 zum Einsatz kam. Als Kernel wurden sowohl die Standard-Gentoo-Quellen, als auch die Hardened-Quellen compiliert. Die verschiedenen Kernel führten zu keinen Unterschieden in den Ergebnissen.

"Hallo Welt"-Test: 742 Antworten / s = 1,4ms pro Antwort
"phpinfo"-Test: 114 Antworten / s = 8,7ms pro Antwort
"postgres"-Test: 40 Antworten / s = 25,3ms pro Antwort

Die Ergebnisse fallen wider Erwarten leicht hinter den Messwerten von Debian zurück. Das Ergebnis des PostgreSQL-Testes weicht allerdings deutlich von den vorangegangenen Messungen ab. Die Frage, ob die Ursache in der älteren Version des PostgreSQL-Servers liegt, oder das Debian-Paket vermurkst ist, können nur weitere Nachforschungen beantworten.

Fazit

Auf kleinen oder älteren Systemen hat Linux deutlich die Nase vorn, was den Einsatz als typischen Webserver (Webserver, PHP/Perl, Datenbank) anbelangt. Ab einem gewissen Punkt wird Solaris seine längere Tradition auf großen Mehrprozessor-Systemen ausspielen können, aber auch Linux holt in diesem Bereich massiv auf. Nicht geklärt werden konnte die schlechte Performance von Debian im Zusammenspiel mit PostgreSQL-Datenbanken. Die Ergebnisse unter Gentoo zeigen, dass es sich nicht um ein grundsätzliches Linux-Problem handelt. Mehr als überraschend auch das unerwartete Verhalten von Lighttpd unter erhöhter Last. Grundsätzlich kann beim Hosting von kleinen oder statischen Websites zum Einsatz von leichtgewichtigen alternativen Webservern geraten werden.

Über diese Seite

Diese Seite enthält einen einen einzelnen Eintrag von Stefan vom 30.07.09 19:08.

Ubuntu, suPHP und der suPHP_UserGroup Fehler ist der vorherige Eintrag in diesem Blog.

Medienkunst Pimp ist der nächste Eintrag in diesem Blog.

Aktuelle Einträge finden Sie auf der Startseite, alle Einträge in den Archiven.