WordPress Lasttest mit PHP Accelerator
04.05.2010 | Kategorie: Lasttests | Keine Kommentare | Kommentar Feed | Trackback

In dem letzten Artikel hatte ich die diverse WordPress Optimierungen untersucht. Die Ergebnisse der Lasttests zeigten, dass dort ein sehr großes Optimierungspotential besteht, welches durch einfache Maßnahmen ausgeschöpft werden kann.
Die Resultate hatten mich dann auch veranlasst einen dedizierten Root Server zu mieten und alle meine Webseiten dorthin zu verlagern. Das Ergebnis kann sich sehen lassen. Lagen die Antwortzeiten bei meinem alten Web Hosting Provider im Schnitt bei 4 Sekunden, werden die Seiten nun in der Regel innerhalb einer Sekunde ausgeliefert.
Eine weitere Möglichkeit besteht nun darin die Verarbeitung des PHP Codes selbst zu beschleunigen. Dies Aufgabe wird von einem PHP Accelerator erledigt. Ohne diese wird eine PHP Datei durch den Interpreter bei jedem Seitenaufruf neu übersetzt. Dies ist meistens unnötig, da die Skripte sich in der Regel nie ändern. Außerdem kostet die Übersetzung des Codes viel Performance und belastet somit unnötig den Server.Ein Blick in das W3 Total Cache Plugin zeigt, dass dieses alternativ zu der von mir bis jetzt genutzten Page Caching Methode Disk (enhanced) diese OpCode Caches unterstützt:
Meine Wahl viel hier auf APC. An diesem OpCode Cache arbeiten auch PHP Entwickler von Zend mit und es soll Bestandteil von PHP 6 werden: PHP 6: Was uns erwartet. Weiterhin ist APC im Debian Repository enthalten. Außerdem zeigt ein Vergleich der Kandidaten, dass sie sich letztlich nicht groß unterscheiden. Auf 2bits.com findet sich dazu ein Benchmark. Zu eAccelerator sei gesagt, dass dort Funktionalitäten entfernt wurden, so dass dieses nicht mehr von dem W3 Total Cache Plugin angesprochen werden kann. Näheres ist hier zu finden.
Um den Alternative PHP Cache (APC) unter Debian zu installieren, genügt ein simples
sudo apt-get install php-apc
sowie ein Neustart des Webservers
sudo /etc/init.d/apache restart
Damit ist der OpCode Cache aktiv und wir kommen zu den Ergebnissen der WordPress Lasttests. Die Messungen wurden unter den gleichen Bedingungen wie beim letzten Mal durchgeführt. Zunächst wurde WordPress ohne das W3TC Plugin unter Last gesetzt, danach mit aktiviertem W3TC Plugin und der Page Caching Methode Disc Cache (enhanced). Zum Schluss habe ich dann das W3TC Plugin so konfiguriert, dass es den APC OpCode Cache als Page Caching Methode benutzt. In der folgenden Tabelle sind die Ergebnisse dieser und zum Teil der Messungen vom letzten Mal zu finden:
| 100 PR/m | 200 PR/m | 300 PR/m | 400 PR/m | 500 PR/m | |
| Kein APC, kein W3TC | 301 ms | 324 ms | 344 ms | n.a. | n.a. |
| APC, kein W3TC | 200 ms | 199 ms | 228 ms | 283 ms | 540 ms |
| Kein APC, W3TC Disc Cache | 21 ms | 22 ms | 20 ms | 20 ms | 25 ms |
| APC, W3TC Disc Cache | 11 ms | 11 ms | 9 ms | 8 ms | 8 ms |
| APC, W3TC OpCode Cache | 13 ms | 12 ms | 11 ms | 10 ms | 10 ms |
Erfreulich ist, dass APC ohne das W3TC Plugin die Performance so steigert, dass nun 500 PR/m möglich sind. Zum Vergleich: Ohne OpCode Cache und ohne W3TC Plugin war letztes Mal schon nach 300 PR/m Schluss. Selbst das W3TC Plugin, welches mit rund 20 Millisekunden schon gute Antwortzeiten zeigte, konnte durch APC nochmals gesteigert werden. Interessant ist, dass das W3TC Plugin mit dem Disc (Enhanced) einen Tick schneller arbeitet, als mit dem OpCode Cache.

Fazit
Der Alternative PHP Cache (APC) sollte auf jeden Fall eingesetzt werden. Er beschleunigt jede PHP Anwendung um ca. 1/3. Einen Anwendungscache wie W3TC ersetzt es aber nicht. Beide zusammen ergeben aber eine Performance, die kaum verbessert werden kann. Das W3TC Plugin arbeitet am schnellsten mit dem Disk Cache zusammen.
Ist der Cache einmal gefüllt, so werden die Seiten vom Webserver innerhalb von wenigen Millisekunden ausgeliefert. Natürlich bedeutet dies nicht, dass die Seiten nun auch so schnell beim Benutzer angezeigt werden. Dort spielen noch weitere Faktoren eine Rolle, wie z.B. die Anbindung des Benutzers, sowie die Gestaltung der Webseite als solches. Je mehr Artefakte, dazu gehören Bilder, Stylesheets und Javascriptdateien, der Browser herunterladen muss, desto länger dauert dies.
Kommentar hinterlassen
Es kann sein, dass dein Kommentar zuerst in die Kommentar-Warteschlange gelangt, danach muss er zuerst von mir freigeschaltet werden. Dies geschieht im Normalfall nach maximal 24h.