Nach dem Umzug auf Ubuntu kam ich auf die Idee mal wieder zu schauen wie die Performance des vServers so ist.
Vor der Optimierung
Ein geeigner Lasttest ist im Inernet schnell gefunden 1. Er ist kostenlos und simuliert in 10er-Schritten die Auslastung bis zu 50 Usern gleichzeitg. Vor der Optimierung mit einer Standard Apache2 Installation sah das Ergebnis sehr schlimm aus: 
Was sehen wir in dem Graphen?
Nun zunächst fällt einem die wunderbare exponentielle Kurve ins Auge. Wir sehen auf der x-Achse die Anzahl der Clients sowie auf der y-Achse die Antwortzeit des Servers. Um es gleich zu sagen: dies ist eine Beispielkurve. In Realität sah meine Kurve genauso aus, ich habe den Test allerdings bei 40 Usern abgebrochen, weil mein Server merklich den Geist aufgab. Das Problem das wir dort sehen ist auf die Leistungsbegrenzung des Systems zurückzuführen 2. Wie ich festellen musste war es vor allem die CPU Auslastung, welche durch Apache 2 hervorgerufen wurde, die dem System zuschaffen machte. Ich hab absichtlich eine Seite mit vielen Bildern und Informationen gewählt, welche auch in PHP Rechenleistung in Anspruch nimmt.
Wie kann man das System optimieren?
Um das System zu optimieren müssen wir uns überlegen wo die Probleme entstehen: Apache startet für jeden Request einen Prozess der nicht besonders Ressourcenschonend ist. Ziel ist also alle unwichtigen Anfragen (alles außer php Requests) vorher abzufangen und nicht an Apache weiterzugeben. Hierfür eignet sich besonders gut Nginx 3. Nginx wird als Reverse Proxy vor Apache betrieben und fängt eingehende Anfragen ab. Dort werden die Anfragen nach statischen und dynamischen Anfragen sortiert. Statische Anfragen werden direkt von Nginx bearbeitet und nehmen somit nur die Rechenleistung von Nginx in Anspruch. Nginx ist sehr schlank programmiert und genau auf dieses Szenario ausgelegt. Dynamische Anfragen wie PHP Seiten werden von Nginx an Apache per Proxy Request weitergeleitet und dort bearbeitet. Das Ergebnis wird von Nginx empfangen und an den Besucher der Webseite ausgeliefert. Zusätzlich komprimiert Nginx die Anfrage und verringert somit das aufkommende Datenvolumen.
Nach der Optimierung

Für alle die jetzt noch meckern wollen: Mir ist klar, dass der erste Graph deutlich mehr Connections verzeichnet – lasst euch gesagt sein, bei mir der Graph bereits nach 40 Connections so aus. Leider habe ich das Bild nicht gespeichert und habe deswegen auf das Bild aus der Dokumentation zurückgefriffen. Trotzdem denke ich, sprechen die Daten für sich.
Was bleibt zu tun?
Nun, zunächst einmal freue ich mich, dass das funktioniert hat. Bei Interesse werde ich nochmal im Detail auf die notwendige Konfiguration eingehen und einen ausführlichen Post verfassen, wie man Nginx zähmt. Des weiteren gibt es nun noch die Möglichkeit zwischen Nginx und Apache einen Cache einzupflegen, der schaut ob man überhaupt eine neue Berechnung der PHP Seite braucht oder ob sich das Ergebnis in den letzten Minuten überhaupt nicht verändert hat. Hierfür bietet sich Varnish an 4. Sollte ich die Zeit dafür finden werde ich ihn umgehend ausprobieren.