PHP Beschleuniger beschleunigen PHP Anwendungen dadurch, dass sie die kompilierten PHP Skrite direkt im Shared Memory (RAM) ablegen und von dort aus aufrufen. Somit müssen die Skripte nicht mehr zur Laufzeit generiert werden. Das nimmt der CPU enorm viel arbeitet ab und beschleunigt manche PHP Anwendungen um den Faktor 5. Die freigewordene CPU Zeit kann wiederum an anderer Stelle gewinnbringend eingesetzt werden, so dass der eigentlich Perfomancezuwachs noch höher ist.
Zend-Gründer Zeev Suraski: “…Ein OpCode-Cache kann ein sehr wesentlicher Teil des ganzen Setups sein. Manchmal braucht man zwei zusätzliche Server, wenn man keinen OpCode-Cache verwendet…”
Da wir in den letzten Monaten öfters Probleme mit eAccelerator in Verbindung mit neuen PHP Versionen oder dem PHP Framework Symfony hatten, habe ich mir mal einen kleinen Überblick über die bekanntesten PHP Beschleuniger verpasst:
Zum einen gibts da die hauseigene Zend Platform, die bei kommerziellem Einsatz natürlich lizensiert werden muss. Der oben erwähnte eAccelerator ist die Fortsetzung des Turck MMCache. XCache entstand unter der Regie von lighttpd Entwickler mOo, der zwar ursprünglich versuchte, Erweiterungen und Fehler bei eAccelerator einzukippen – dort aber wohl auf taube Ohren stieß. So startete er seinen eigenen PHP Beschleuniger XCache.
Außerdem gibts noch den IonCube Encoder und das PECL Package Alternative PHP Cache (APC). Der IonCube Encoder ist allerdings kein wirklicher Beschleuniger, er “verschlüsselt” den PHP Code nur und so wird die Ausführung des Codes eher verlangsamt als beschleunigt. APC hingegen wird in PHP6 integriert werden, da dieser Cacher als einziges Produkt am Markt mit einem für das PHP Dev Team verträglichen Lizenzmodell kommt. APC ist schon ein wenig älter, wurde allerdings nicht in PHP5 eingebaut, da es mit der damaligen Version unter Hochlast zu Systemabstürzen führte. In PHP6 wird APC zwar mit dabei sein, ist aber per default deaktiviert.
Eine Zusammenfassung der Features, Unterschiede und Lizenzen findet ihr auf dieser Seite. Die oben aufgeführten PHP Beschleuniger werden zusätzlich hinsichtlich Ausführungszeit von Standard Anwendungen geprüft (phpmyadmin, mediawiki,helloworld).
Mein nächster Kandidat heisst nun erstmal XCache!
Links:
Zend platform
Homepage des eAccelerator
XCache Homepage
IonCube Webseite
Homepage des Alternative PHP Cache (APC)
Interview mit Zend-Gründer Zeev Suraski auf Golem
Faktor fünf? Erstaunlich, wie langsam PHP dann bisher war
IMHO machen Java und Python etwas ähnliches, wenn sie ihren Bytecode auf Platte speichern. Bei Java muss dieser aber nochmals zur Laufzeit in Binärcode übersetzt werden. Das ist aber eh nur alles bei *Server Pages interessant. Da wo richtige Web Application Server laufen (JBoss, CherryPy, …) wirds vom Interpreter gecacht.
btw: The Computer Language Benchmark Game unter http://shootout.alioth.debian.org/ ist lesenswert.
btw2: Moinmoin ist natürlich in Python geschrieben.
Wir wollen hier doch nun kein Kampf der Sprachen oder, gibts oft genug
moinmoin war natürlich falsch, das mediawiki war gemeint, sorry. Nicht mal richtig abschreibe kann der bub
Gibts für Java dann keine Tools, mit deren Hilfe man häufig gebrauchte Skripts ins Memory/tempfs auslagern kann? Macht ja eigentlich immer Sinn, egal welche Sprache nun verwendet wird.
Du weisst doch, erst wenn du widersacher hast, bist du wirklich wichtig
Was das Auslagern angeht: den Maschinencode auszulagern/zu cachen macht imho nur dann Sinn, wenn ich ihn auch häufig wieder importiere; so wie bei PHP oder *Server Pages eben. Eigentlich sollte das aber mod_php machen; das ist die nächst höhere Instanz, welche nicht ständig neu geladen wird. Daher kommen auch die Geschwindigkeitsvorteile gegenüber CGI etc. Wie das bei Java Server Pages läuft, weiss ich nicht. Hoffentlich werden die aber vom Application Server gecacht (so wie bei PHP mit Zend Optimizer oder den ganzen add-ons.)
Klar ist der Ioncode ein Beschleuniger. Encoden ist doch nur noch eine zusätzliche funktion.
Kurz. geguckt. ERSTER Funktionpunkt auf der Herstellerseite:
Encoding PHP scripts with compiled bytecodes for accelerated runtime performance and maximum security.
@Sabine: Der Eintrag ist 3 Jahre alt, der Benchmark noch ein Jahr älter. Damals hat der IONcube encoder eben noch anders ausgesehen, was das Benchmark Ergebniss von damals ja auch belegt.
Falls du aktuelle Zahlen hast so poste sie bitte im Kommentar, danke