PHP ist eine interpretierte Scriptsprache, d.h. bei jedem Zugriff, der durch ein PHP-Script bearbeitet wird (und das ist bei vielen PHP-basierten Websites fast jeder Zugriff), wird das Script von PHP geladen und interpretiert. Die eigentliche Ausführung erfolgt dann aber in Form von Opcodes im Speicher, so das der Geschwindigkeitsunterschied zu nativem Binärcode ab diesem Zeitpunkt nicht sehr groß ist.

Das Problem: Die erzeugten Opcodes werden nach der Ausführung wieder verworfen, auch wenn sich das aufgerufene Script nicht ändert. Wenn ein Script zehn Mal hintereinander aufgerufen wird, erfolgt auch zehn Mal eine erneute Interpretation, obwohl sie eigentlich nur einmal nötig wäre.

Man könnte eine deutliche Verbesserung erreichen, wenn der Binärcode nach der Ausführung im Speicher verbleiben würde, damit man sich beim nächsten Aufruf die langwierige Interpretation des Scriptes sparen kann. Genau hier kommen die verschiedenen „PHP-Beschleuniger“ in's Spiel – die Opcodes werden in einem Cache vorgehalten und stehen für die nächste Ausführung wieder zur verfügung.

Für diesen Zweck setze ich derzeit XCache ein. XCache ist im Umfeld des lighttpd-Projektes entstanden, ist aber auch in Verbindung mit Apache oder nginx einsetzbar. Die Vorteile bei XCache für mich sind der stabile Betrieb, eine schnelle Anpassung an neue PHP-Versionen und die einfache Installation – unter Debian oder Ubuntu steht XCache als Paket zur Verfügung und kann für PHP5 mit

apt-get install php5-xcache

leicht installiert werden. XCache wird dann als Zend-Extension eingetragen und verhält sich volkommen transparent – d.h. alle bestehenden PHP-Scripte sind unverändert weiter nutzbar. Änderungen an den Scripten, die eine erneute Interpretation erfordern, stellt XCache automatisch fest.

Nach der Installation sollte man einen Blick in die Konfigurationsdatei werfen, z.B. /etc/php5/apache2/conf.d/xcache.ini. Dort ist insbesondere der Wert für xcache.size wichtig – wenn der Server ausreichend Speicher hat, kann man hier 64 (für 64 MB) oder mehr angeben. Der Variablen-Cache xcache.var_size ist nur relevant, wenn man Anwendungen nutzt, die davon mit dem XCache-API auch Gebrauch machen. Mit dem Administrations-Frontend von XCache oder dem Munin-Plugin zur Überwachung der aktuellen Werte kann man die tatsächliche Speichernutzung später auch kontrollieren und die Werte ggf. anpassen. Wichtig: Nach einer Änderung muss Apache neu gestartet werden.

Die Arbeit von XCache macht sich sehr schnell bemerkbar: sobald die Scripte in Form von Opcodes aus dem Cache geladen werden, sind sie je nach Komplexität um den Faktor 2-3 schneller als vorher, da die Zeit für die Interpretation vollkommen entfällt. Auch die Serverlast sinkt deutlich.

Auf http://www.ohardt.com/dev/munin/ findet man auch ein Plugin für Munin, um die Aktivität von XCache im zeitlichen Verlauf beobachten zu können.

Die Einrichtung ist in der mitgelieferten Dokumentation erklärt. Man kopiert ein PHP-Script auf den Webserver, mit dem das Plugin die Daten via HTTP abfragen kann (das ist notwendig, da nur so die Daten der laufenden XCache-Instanz ermittelbar sind) und das Plugin selbst (bestehend aus drei Dateien) in das entsprechende Verzeichnis von Munin. Zusätzlich gibt man in der Munin-Konfiguration die URL für den Zugriff auf das PHP-Abfragescript an, ggf. mit Benutzernamen und Passwort. Dabei ist zu beachten, dass das Passwort in der XCache-Konfiguration als MD5-Prüfsumme angegeben wird, in der Konfiguration des Munin-Plugin aber im Klartext!

Wenn in Munin nach 5-10 Minuten keine Daten angezeigt werden, sollte man das Update-Log von Munin prüfen.

Auf dem folgenden Diagramm in Munin sieht man die aktuelle Nutzung des Cache über die letzten 24 Stunden – es zeigt die Zugriffe pro Sekunde, die aus dem Cache bedient werden: