Serendipity und lighttpd
Dieser Artikel wurde am 3.2.2007 in meinem damaligen Blog veröffentlicht und 2009 in dieses Wiki übertragen.
Das Zusammenspiel des Simple Machine Forum (SMF) und lighttpd habe ich ja bereits behandelt. Dabei war lighttpd dem Apache nicht gerade haushoch überlegen, die Nasenspitze hatte er zumindest vorn. Die Blogsoftware serendipity (s9y) steht ja in dem Ruf nicht gerade zimperlich mit den Ressourcen umzugehen, auch wenn ich selbst in der Hinsicht noch keine schlechten Erfahrungen gemacht habe.
Testumgebung
Die Testumgebung entspricht bis auf Serendipity der vom SMF Benchmark, der Vollständigkeit halber ist sie hier noch einmal beschreiben.
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)
- serendipity 1.1
Um nicht die Datenbank als Flaschenhals zu haben, wurde jegliches Logging abgeschaltet und der Tablespace in eine 512 MB große Ramdisk verlegt.
Benchmark
ab2 ruft über mehrere parallele Verbindungen (Parameter -c), die Startseite ein s9y Blogs auf, 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.
Die passende Konfiguration von lighttpd mit entsprechenden Regel für das URL-rewriting und die Zugriffsbeschränkung sah so aus:
$HTTP["host"] == "host.domain.tld" {
server.document-root = "/www/host.domain.tld/htdocs/"
server.errorlog = "/www/host.domain.tld/logs/error.log"
accesslog.filename = "/www/host.domain.tld/logs/access.log"
url.access-deny = (
".tpl",
".inc.php",
".sql",
".db",
)
url.rewrite-once = (
"^/approve/(.*)/(.*)/([0-9]+)" => "/index.php?url=approve/$1/$2/$3",
"^/archive$" => "/index.php?url=/archive",
"^/archives([/A-Za-z0-9]+)\.html" => "/index.php?url=/archives/$1.html",
"^/authors/([0-9]+)" => "/index.php?url=/authors/$1",
"^/categories/([0-9]+)" => "/index.php?url=/categories/$1",
"^/delete/(.*)/(.*)/([0-9]+)" => "/index.php?url=delete/$1/$2/$3",
"^/feeds/(.*)" => "/index.php?url=/feeds/$1",
"^/htmlarea/(.*)" => "/htmlarea/$1",
"^/index\.html?" => "/index.php?url=index.html",
"^/plugin/(.*)" => "/index.php?url=plugin/$1",
"^/search/(.*)" => "/index.php?url=/search/$1",
"^/unsubscribe/(.*)/([0-9]+)" => "/index.php?url=/unsubscribe/$1/$2",
"^/(admin|entries)(/.+)?" => "/index.php?url=admin/",
"^/([0-9]+)[_\-][0-9a-z_\-]*\.html" => "/index.php?url=$1-article.html",
"^/(serendipity\.css|serendipity_admin\.css)" => "/index.php?url=/$1",
"^/(index|atom|rss|b2rss|b2rdf).(rss|rdf|rss2|xml)$" => "/rss.php?file=$1&ext=$2",
"/(.*\.html?)" => "/index.php?url=/$1",
)
}
Im Vergleich zum SMF Benchmark ist hier der Vorspung von lighttpd deutlicher, er verarbeitet ca 10% mehr Anfragen pro Sekunde als der Apache. Richtig Würze kommt aber auch hier erst ins Spiel wenn der PHP Opcode Cache XCache verwendet wird. Er bringt in jedem Fall eine Steigerung von 150%. Geht man davon aus, dass eine Migration von Apache zu lighttpd inkl. XCache erfolgt, beträgt die Steigerung sogar 170%. Da ich die letzten Updates seit Version 1.0 verschlafen habe, nutzte ich die notwendigen Updates um die Performance der einzelnen Versionen zu testen. Der Schritt von 1.0 auf 1.0.4 und dann auf 1.1 brachte jeweils Einbußen von ca 9%, der Schritt von 1.0 auf 1.1 folglich ca. 17%. Wer also fleissig sein s9y auf dem neuesten Stand hielt konnte miterleben wie sein Blog immer langsamer wird. Ein Glück, dass mit lighttpd + XCache wieder etwas Leistung gewonnen wird.
Wer sich die Event-Plugins schon einmal durchgesehen hat, hat sicher das Simple Cache Plugin (Einfache Cached/Pregenerated Seiten) entdeckt. Das hört sich nach „mehr Power“ an. Tatsächlich ist es auch so, dass im Benchmark beim Zugriff auf die Startseite um den Faktor 6 mehr Zugriffe pro Sekunde möglich sind vorausgesetzt XCache wird verwendet. Ist XCache nicht aktive wird die Anzahl der Zugriffe lediglich verdoppelt. Leider hat sich dieses Plugin nicht nachvollziehbare Fehler, z.B. fehlende Seiten und falsche Seitendarstellung, produziert. Bei aller Freude über mehr Leistung, sie hilft einem nichts wenn der Seiteninhalt nicht oder verkehrt angezeigt wird. Zur Ehrenrettung muss man aber auch sagen, dass in der Beschreibung des Plugins auf den experimentellen Status hingewiesen wird.
Zum Schluß noch ein Tip bzgl. Mysql. Bei den Installationen diverser Hoster ist mir aufgefallen, dass ab und an (ich habe noch keine Regel erkannt) in der Konfigurationsdatei my.cnf log_bin aktiviert ist. Sofern man keine Replikation verwendet und seine DB regelmässig sichert kann man darauf getrost verzichten. Auf den Benchmark hier übertragen bringt das Deaktivieren von log_bin immerhin 1% mehr Zugriffe pro Sekunde. Mühsam ernährt sich der Benchmarker 
