Simple Machine Forum (SMF) mit Apache und Lighttpd

Dieser Artikel wurde am 3.2.2007 in meinem Blog veröffentlicht und 2009 in dieses Wiki übertragen.

Ursprünglich als kleine Fingerübung für die Weihnachtsfeiertage gedacht, entwickelte sich die Suche nach einer optimalen Konfiguration für den Betrieb eines Forums auf Basis der Software Simple Machine Forum (SMF) zu einem kleinen Benchmarkfestival. Wie üblich erhält man als Resultat eine Unmenge an Zahlen, die wenn sie erst ausgewertet und interpretiert sind gar nicht mehr nach allzuviel Arbeit aussehen. Am Anfang stand die Frage was man tun kann um einen Webserver der ordentlich unter Last steht zu optimieren ohne gleich die ganze Hardware auszutauschen. Denn soviel ist klar, mit schnellerer CPU, mehr RAM und schnelleren Festplatten kann man jeden Performance Engpass in den Griff bekommen. Dies hätte aber zur Folge, dass über kurz oder lang eine ganze Menge Hardware sinnlos in der Ecke verstaubt, denn irgendwie muss man ja die Server doch bis zum Ende der Vertragslaufzeit weiterbezahlen. Auf der anderen Seite bietet sich so vielleicht auch die Möglichkeit ältere und somit günstigere Hardware für ein Projekt einzusetzen. In der Szene hört man in letzter Zeit immer lauter den Namen lighttpd, ein schlanker Webserver von dem behauptet wird, dass er Apache in Sachen Geschwindigkeit überlegen ist. Was lag also näher dieses Vermutung zu überprüfen.

Für Benchmarks gilt der gleiche Allgemeinplatz wie für Statistiken, vertraue nichts das du nicht selbst gefälscht hast. Damit kommen wir gleich zur Testumgebung. Diese ist bewusst einfach gehalten und die verwendete Hardware nicht gerade frisch aus der Fabrik. Das ist in diesem Zusammenhang aber auch nicht notwendig, da es nicht um die absolute Höchsleistung sondern um eine qualitative Aussage geht.
Als Server kommt ein Pentium IV mit 2 GB RAM und einem (Hardware) RAID1 aus zwei 40GB ATA Festplatten zum Einsatz, der Client ist ein Athlon XP 2400 mit 1 GB RAM und einer 120 GB SATA Festplatte. Beide Rechner sind direkt über ein Crossover Kabel miteinander verbunden, die Ethernetschnittstellen sind auf 100 MBit/s Übertragungsrate fest eingestellt. Auf beiden Rechnern ist Ubuntu 6.10 installiert (ohne X11!) und alle nicht notwendigen Dienste (Mail, syslog, cron etc.) sind deaktiviert. Um die Leistungsfähigkeit des Servers zu testen wird auf dem Client das Programm ab2 (Apache Benchmark) verwendet.

Die entscheidende Software auf dem Server ist:

• Mysql 5.0.24a (Paketversion 5.0.24a-9)
• Apache 2.0.55 (Paketversion 2.0.55-4ubuntu4)
• mod-php5 5.1.6 (Paketversion 5.1.6-1ubuntu2.1) als php5 Interpreter unter Apache
• php5-cgi 5.1.6 (Paketversion 5.1.6-1ubuntu2.1) als php5 Interpreter unter lighttpd, eingebunden über die fastcgi Schnittstelle
• lighttpd 1.4.13 (Paketversion 1.4.13~r1370-1ubuntu1)
• XCache 1.2.0 (selbst kompiliert)
• SMF 1.1.1 (http://www.simplemachines.org/download/)

Um nicht die Datenbank als Flaschenhals zu haben, wurde jegliches Logging abgeschaltet und der Tablespace in eine 512 MB große Ramdisk verlegt.

Um ein Gespür zu bekommen wie sich der Server unter Last verhält wurden verschieden große html Seiten vom Client geladen. Mit ab2 ist es möglich gleichzeitig mehrere Verbindungen aufzubauen (Parameter -c), die Anzahl der Request (Parameter -n) war 10000. Ausgewertet wurden die Request pro Sekunde, die der Server bei unterschiedlichen Nebenläufigkeiten ausführen konnte. Für jeden Wert des Parameters -c wurden nacheinander drei Läufe ausgeführt und der Mittelwert gebildet. Bevor die Läufe mit dem nächsten -c Wert gestartet wurden ist auf dem Server der apache2 bzw. lighttpd Prozess gestoppt, access.log und error.log gelöscht, anschliessend wieder gestartet worden. Der Benchmark wurde mit und ohne keepalive ausgeführt und getrennt ausgewertet.

In der Grafik oben sieht man das Ergebnis für die Dateigrößen 1kB, 16kB und 128kB. Vergleicht man beide Grafiken so stellt man fest, dass mit keepalive sowohl Apache als auch lighttpd mehr Anfragen verbeiten können. Bei 1kB Dateien kann in beiden Fällen der lighttpd mehr Anfragen verarbeiten als der Apache. Bei 16kB und 128kB Dateien geben sich die beiden Kontrahenten nicht viel. So scheint es zumindest, tatsächlich ist es aber so, dass in diesem Fall das Netzwerk der limitierende Faktor ist. Beide Prozesse würden gerne mehr Dateien ausliefern, das 100 MBit/s Ethernet nimmt aber nicht mehr auf.
Eine Beobachtung während des Benchmarks ist recht interessant. Mehr oder weniger zufällig habe ich auf dem Server mit cat /proc/loadavg die Auslastung des Systems überprüft. Beim Apache konnte ich für dabei Werte von über 40 beobachten während beim lighttpd der höchste Werte bei 1,2 lag.

Betreibt man einen Webserver der vor allem kleine (« 16kB) statische Webseiten verarbeiten muss lohnt es sich aus Gründen der Performance Apache durch lighttpd zu ersetzen. Bei größeren Dateien wirkt sich der Umstieg kaum aus, hier sollte man sich zunächst Gedanken über eine größer Bandbreite der Netzwerkanbindung Gedanken machen. Bringt man die zufällige Beobachtung der Last mit ein, lohnt sich der Umstieg aber dann wenn der Server unter hoher Auslastung steht.

Bevor nun aber jeder gleich loslegt und den Apache von der Platte wirft. So ein Umstieg will reiflich überlegt sein, es ist nicht damit getan nur die Softwarepakete auszutauschen. lighttpd verfolgt eine andere Philosophie was man spätestens bei der anderen Syntax der Konfigurationdateien merkt. Grundsätzlich kann lighttpd fast alles was auch der Apache kann nur eben anders. Z.B. kennt lighhtpd keine .htaccess Dateien, Zugriffsrechte werden direkt in der Konfigurationsdatei des Servers festgelegt. Da die Anzahl der Benutzer von lighttpd nicht ansatzweise an die des Apache heranreichen ist es mit unter schwierig Unterstützung zu finden und kommt nicht umhin sich Problemlösungen selbst zu erarbeiten.

Nun zur ursprünglichen Fragestellung, es ging ja darum für das Simple Machine Forum einen möglichst performanten Unterbau zu schaffen. Wie bereits oben erwähnt lassen wir DB Tuning mal ausser acht. An dieser Schraube zu drehen lohnt sich nur dann wenn man auch Einfluss auf das DB Design nehmen kann, wenn es dort nicht stimmt hilft einem der schnellste Server nichts.
Der Benchmark wird wie bereits bei den statischen Seiten mit unterhschiedlichen Werten für gleichzeitige Anfragen ausgeführt. Zwei Fälle werden untersucht, der Aufruf der Startseite (ca. 19kB) und der Aufruf eines Forenthreads mit 12 Beiträgen (ca. 65kB). Ein erster Druchlauf hat gezeigt, dass lighttpd meist mehr Zugriffe verarbeiten kann als apache, allerdings lag der Geschwingkeitsgewinn nur bei max. 5%. Das ist nicht schlecht, aber deswegen eine Migration durchführen? Immerhin zeigt es, dass lighttpd mit Apache mithalten kann wenn es um php Seiten geht. Ob und wie weiter optimiert wird hängt davon ab wo sich der Flaschenhals befindet. Der Entwicklern von SMF wollen wir mal nichts böses nachsagen und den Quelltext des Forums zu durchforsten wäre auch sehr aufwendig. Was bleibt ist die Datenbank und der PHP Interpreter. Zum Test wurde der Tablespace wieder auf eine Festplattenpartition verlegt und der Benchnmark erneut durchgeführt. Das Ergebnis waren keine signifikant anderen Werte im Vergleich zum vorhergehenden Duchlauf. Es bleibt also nur der PHP Interpreter und das Stichwort hier lautet Opcode Cache. Bei der Recherche zu lighttpd bin ich auf XCache gestossen, ein Opcode Cache der im Rahmen der lighttpd Projekts entwickelt wird. Trotz des Zusammenhangs kann er aber auch mit Apache verwendet werden. Die Installation ist zwar nicht trivial da es keine fertigen Pakete für Ubuntu bzw. Debian gibt, das Ergebnis lohnt aber den Aufwand.

Wie nicht anders zu erwarten war, ist die Anzahl der verarbeiteten Anfrage bei der Anzeige des Forenthreads niederiger als bei der Startseite. Der Grund ist einfach nachvollziehbar, beim Thread wird mehr PHP Code durchlaufen und es sind mehr DB Abfragen notwendig. Was man ebenfalls sieht ist, dass sich Apache und lighttpd nicht viel geben. Der größte Geschwindigkeitsgewinn entsteht erst durch die Verwendung von Xcache. Bei der Starseite sind verdoppeln sich die verarbeiteten Anfragen und beim Forenthread ist immerhin die Hälfte mehr. Um noch mehr Leistung zu erreichen unterstützen die Entwickler von SMF direkt das Cachen von Variablen, verlassen sich also nicht auf den Opcode Cache selbst. Leider erkennt SMF XCache nicht automatisch, um also das letzte Quentchen herauszuholen muss man am Quellcode von SMF Änderungen vornehmen (Forenbeitrag zum Thema XCache und SMF). Das ist nicht jedermanns Sache, wird aber mit weiteren 50% (Startseite) bzw. 17% (Forenthread) belohnt. Bezogen auf den Einsatz von SMF ohne jede Hilfe von XCache sind das 200% bzw. 80% Geschwindigkeitszugewinn.

Für all jene die das letzte Quentchen aus ihrer SMF Installation herausholen wollen ist die Entscheidung klar: lighttpd einsetzen, XCache installieren und den Quellcode von SMF anpassen. Wer sich scheut Apache zu ersetzen oder aus technischen Gründen gar keinen Wechsel des Webservers in Erwägung ziehen darf, kann mit dem Einsatz von XCache im einfachsten Fall bereits eine sichtliche Performancesteigerung erreichen. Wer es sich dann auch noch zutraut am Quellcode von SMF Änderungen vorzunehmen kann mit einem Geschwindigkeitszugewinn rechnen, der sonst nur mit einer Verdopplung des CPU Taktes zu erreichen wäre. Eine Sache sollte man aber nicht aus dem Auge verlieren, XCache benötigt Speicher. Für Server die notorisch an der Grenze des verfügbaren Speichers operieren hilft ein Opcode Cache reichlich wenig. Hier sollte man tatsächlich zuerst eine Erweiterung des RAMs in Erwägung ziehen und dann XCache installieren.