Die Aufgabenstellung: Die Applikationen aus unserem Hause sollen so stabil und leistungsfähig laufen wie möglich. Ein wichtiger Bestandteil der Applikations-Infrastruktur stellen in unserem Bereich die Webserver dar, die PHP-Unterstützung mitbringen müssen.
Bei meinen Versuchen, die bestmögliche, unseren Anforderungen entsprechende Serverkonfiguration zu finden, habe ich ein paar Benchmarks gemacht, die ich hier mit der Welt teilen möchte.
Die Benchmarks
Im ersten Schritt habe ich diverse OpCode Caches und den ZEND Optimizer ausprobiert.
Das Testsystem ist ein DELL PowerEdge R200 Server mit einem Core2Duo E4500 Prozessor und 4GB RAM. Darauf zugegriffen wurde über ein lokales 100 MBit Netzwerk.
Der Server läuft auf Debian Linux (64bit), als Webserver-Software kam Apache 2.2.3 mit PHP 5.2.0 über mod_php zum Einsatz. Allesamt wurden aus den Debian-Paketen installiert.
Für meine Benchmarks habe ich drei verschiedene Scripte verwendet:
- KCAPTCHA
Ein Script, das Captcha-Bildchen erzeugt. Dieses Script verwendet zwar relativ viel die GD2 Grafik-Library, wodurch ein großer Teil des Programmablaufs genaugenommen „fix“ ist, weil die Geschwindigkeit von GD2 nicht durch die Optimierungen verändert wird. Das Programm führt aber auch einige Schleifen und Berechnungen in PHP durch, um die Grafik vor der Ausgabe zu verzerren. - Viel Code, wenig Ausführung
Das zweite war ein eigentlich sehr einfaches, selbst geschriebenes Script, das nicht viel mehr gemacht hat, als die Zahlen von 1 bis 100 in einer Schleife auszugeben. Zusätzlich habe ich allerdings (absichtlich sinnloserweise) eine 20 KByte große PHP-Datei includiert, die einige Funktionen enthält, die ich bei meinen Projekten regelmäßig verwende. Damit sollte sich die reine Aufruf-Geschwindigkeit messen lassen, ohne durch eine Script-Laufzeit groß beeinflusst zu werden. - WordPress
Last, but not least, um etwas praxisnäher zu testen: Eine WordPress 2.3-Installation, in die ich mit ein paar Blindtexten gefüllt habe. Als Datenbank kam eine ebenfalls lokal auf dem Server installierte MySQL-Instanz zum Einsatz.
Als Optimierer kamen zum Einsatz:
- eAccelerator 0.9.5.2
- XCache 1.2.2 (Cache an, Optimizer aus)
- Alternative PHP Cache (APC) 3.0.16
- ZEND Optimizer 3.3.3 (alle Optimierungsstufen aktiviert)
- ZEND Optimizer zusammen mit eAccelerator
An den Einstellungen der verschiedenen Optimizer habe ich nichts geändert, also so weit überhaupt möglich immer die Standard-Einstellungen verwendet.
Was ist ein OpCode Cache?
eAccelerator, XCache und APC stellen OpCode Caches dar. Ohne einen solchen wird bei PHP bei jedem Script-Aufruf das entsprechende Script frisch „compiliert“ und dann ausgeführt. Wenn man aber einen OpCode Cache installiert, so werden die compilierten Scripte im Speicher gehalten, so dass sie bei einem weiteren Aufruf aus der Konserve verwendet werden können. Das spart ab dem zweiten Aufruf die Compilierungs-Zeit.
Einige der Caches bringen auch noch einen Optimizer mit.
Was ist ein OpCode Optimizer?
Der ZEND Optimizer dagegen ist ein OpCode Optimizer, der versucht, PHP-Scripte bei der Compilierung zu optimieren, sie also schneller zu machen. Als Beispiel kann man sich beispielsweise eine „kleine Schleife“ vorstellen:
for ($i = 0; $i < 3; $i++) {
echo 'Schleife<br />';
}
echo 'Schleife<br />'; echo 'Schleife<br />'; echo 'Schleife<br />';
Beide Beispiele ergeben das gleiche Resultat. Das obere Beispiel ist als Programmcode vielleicht ein bisschen „hübscher“ anzusehen. Trotzdem ist die untere Variante etwas schneller. Es müssen keine Variablen initialisiert, verglichen und hochgezählt werden, es muss nicht „im Programm zurückgesprungen“ werden. Klarer Geschwindigkeitsgewinn. Noch schneller wäre es als eine einzelne „echo“-Anweisung.
Solche Muster zu erkennen und zu ersetzen ist die Aufgabe eines OpCode Optimizers.
Benchmark 1: KCaptcha
Jetzt aber zu den Testergebnissen. Um die Geschwindigkeit zu überprüfen kam das Tool Apache Benchmark. Mit diesem habe ich von einem anderen Rechner über’s Netzwerk jeweils 10.000 Anfragen an die drei Test-Scripts abgefeuert, jeweils mit 20 parallel laufenden Anfragen.
Zuerst KCAPTCHA:
Die Skala unten gibt an, wie viele Sekunden für die 10.000 Aufrufe benötigt wurden.
Klarer Gewinner hier: Der eAccelerator.
| zend + eaccelerator | 177,54 Sek. |
| eaccelerator | 177,60 Sek. |
| xcache | 183,39 Sek. |
| apc | 187,46 Sek. |
| none | 190,00 Sek. |
| zend | 225,10 Sek. |
Auf den ersten Blick etwas überraschend mag wirken, dass der ZEND Optimizer sowohl auf dem ersten, als auch auf dem letzten Platz zu finden ist – ja sogar langsamer ist, als wenn man ganz auf den Einsatz einer Optimierung verzichtet. Die Lösung: Im Alleingang ohne OpCode Cache braucht der Optimizer mehr Zeit zum Optimieren, als durch die Optimierungen eingespart wird.
Im Gegenzug dazu kann der Optimizer in Kombination mit dem Cache seine Stärke ausspielen: Hier muss nur ein mal optimiert werden. Bei den folgenden 9.999 Aufrufen wird auf den bereits optimierten Code zugegriffen. Bei KCAPTCHA war die Ersparnis aber eher gering, was an der Struktur des Programmcodes liegt. Hier ist einfach nicht viel zu optimieren.
Benchmark 2: Test-Script „viel Code, wenig Ausführung“
Ein ähnliches Bild ergibt sich beim zweiten Testscript:
Hier tritt noch mehr in den Vorschein, dass der ZEND Optimizer die Laufzeit optimiert. Da dieses Script aber nahezu keine „Laufzeit“ hat, sondern nahezu nur aus Compilieren besteht, liegt der ZEND Optimizer auch dieses mal ganz hinten. Wieder ist der eAccelerator der Gewinner:
| eaccelerator | 2,40 Sek. |
| apc | 2,48 Sek. |
| xcache | 2,51 Sek. |
| zend + eaccelerator | 2,85 Sek. |
| none | 11,60 Sek. |
| zend | 13,80 Sek. |
Man sieht aber eindeutig den Vorteil, den ein OpCode Cache mitbringt. Von 11,6 Sekunden auf 2,4 Sekunden sind durchaus spürbar.
Benchmark 3: WordPress
Zum Abschluss noch ein „praxisnäheres“ Beispiel: Im dritten Durchlauf habe ich noch eine WordPress Installation getestet, indem ich 10.000 mal die Startseite aufgerufen habe. Ziel war es, herauszufinden, ob der ZEND Optimizer an dieser Stelle seine Asse ausspielen kann.
Auch dieses mal liegt der ZEND Optimizer ohne OpCode Cache abgeschlagen hinten. Was mich allerdings ein bisschen überrascht hat: Mit eingeschaltetem eAccelerator schnitt er immer noch schlechter ab, als der eAccelerator alleine.
| eaccelerator | 490,74 Sek. |
| xcache | 501,41 Sek. |
| apc | 501,45 Sek. |
| zend + eaccelerator | 506,40 Sek. |
| none | 873,98 Sek. |
| zend | 928,10 Sek. |
Fazit
Was die OpCode Caches angeht kann man eindeutig feststellen, dass es sich sehr lohnt, einen zu installieren. Der eAccelerator hat bei all meinen Tests als Sieger abgeschnitten, aber auch die anderen beiden Kandidaten haben sich nur unwesentlich schlechter geschlagen. Die Geschwindigkeitsgewinne gegenüber „Kein Cache“ sind schwer in Zahlen auszudrücken, da sie von Anwendung zu Anwendung schwanken (abhängig des Verhältnisses „Compilierung“ zu „Laufzeit“). Gerade bei WordPress, der getesteten Anwendung lag sie aber bei spürbaren 78% Leistungssteigerung.
Dagegen muss ich anhand der Ergebnisse meiner Tests von der Installation des ZEND Optimizers abraten, so lange nicht wichtige Gründe dafür vorliegen, warum er laufen muss. Im Normalfall ist er kontraproduktiv und verbraucht mehr Ressourcen als er einspart.
So viel zum ersten Teil meiner Forschungsreise. Im nächsten werde ich die Performance verschiedene Caching-Mechanismen vergleichen.