BLOG

Kann man Drupal mit eigenen PHP Extensions beschleunigen?

Drupal PHP ExtensionUnser Kerngeschäft ist, wie viele sicherlich wissen, die Arbeit mit Drupal. Da wir nun schon so einige Seiten umgesetzt haben, kommen wir immer mal wieder an den Punkt, über die Performance unserer Seiten genauer nachzudenken. Unter den vielen Ansätzen die man gehen kann, wie Caching oder das Aufräumen von Templates, haben wir auch darüber nachgedacht Drupal an sich zu verbessern. Eine Idee war dabei zu schauen, welche Drupal Funktionen sehr häufig aufgerufen werden und diese dann, anstatt sie in PHP zu schreiben, als eine eigene PHP Extension umzusetzen, die wiederum in C / C++ programmiert werden kann. Der Vorteil hier liegt klar auf der Hand. Anstatt viel PHP Quellcode zu nutzen, der wiederum erst noch verarbeitet werden muss von PHP, schreibt man seine Funktion in schnellem C / C++ Code, welcher dann zu einer Library kompiliert wird und von PHP als nativer Befehl genutzt werden kann.

Ich möchte darauf hinweisen, dass das hier kein Tutorial wird wie man eine Extension schreibt, sondern möchte einfach mal meine Erfahrung, Meinungen und Überlegungen zu diesem Thema zum besten geben.

Ich habe mich also mal 2 Tage damit beschäftigt, wie man eigene PHP Extensions schreiben kann. Meine Recherchen im Netz darüber haben mich schnell ernüchtert. Es gibt nur ein paar wenige Tutorials, von denen einige dann auch noch sehr alt sind. Ich habe ein Buch gefunden, veröffentlicht 2006. Quellen und Links findet ihr unten.

Was kann ich also sagen? Ich kann sagen, dass ich geteilter Meinung bin, was das Tunen des Drupal Cores mit Hilfe von eigenen PHP Extensions angeht. Ich glaube, dass es sich lohnen könnte einige Funktionen neu zu implementieren, aber dass es wie so oft im Leben doch mit einem erheblichen Aufwand verbunden ist.

Der erste Grund dafür ist, mal abgesehen davon, dass es kein Zuckerschlecken ist so eine Extension zu schreiben, dass ich mindestens genauso viele Probleme damit habe überhaupt eine Funktion zu finden die ich in einer Extension umsetzen kann. Warum ist das so schwer? Weil in vielen Funktionen im Drupal Core einfach wieder viele andere Funktionen benutzt werden. Das bedeutet, man müsste ja auch diese Funktionen in seiner Extension umsetzen und anpassen.

Ein weiterer Grund, den man nicht außer acht lassen sollte, ist der dass man die neu implementierten Funktion ja aus dem Drupal Core herausnehmen muss, da man ja nun die Funktion der Extension nutzen möchte. Das wiederum bringt dann das nächste Problem mit sich, Updates! Sobald man ein Update von Drupal machen möchte, müsste man wieder damit anfangen den Core zu patchen um das Nutzen der Extension zu ermöglichen - und wie ja jedes kleine Drupal Kind weiß: don't hack the Core :).

Wie geht es also weiter? Ein möglicher neuer Ansatz wäre der das so hoch gelobte HipHop zu testen. HipHop erzeugt aus PHP Code einen optimierten C++ Code, den man dann entsprechend kompilieren und zu einer ausführbaren Datei machen kann. Diese Datei beinhaltet dann wohl auch gleich einen Webserver, der benutzt wird um das Projekt im Web zugänglich zu machen.

Ich hoffe, ich konnte hier dem ein oder anderen einen kleinen Denkanstoß geben und hoffe, dass vielleicht eine kleine Diskussionsrunde dazu hier entsteht. Aus diesem Grund werde ich die Kommentarfunktion aktivieren und freue mich auf konstruktive Anmerkungen.

Links:

Kann man Drupal mit eigenen PHP Extensions beschleunigen?

Kommentare

Pingback

[...] möchte mich noch einmal bedanken für das Feedback des ersten Blogposts über dieses Thema.Wie ich das Feedback verstanden habe, würden die meisten wohl nicht den Weg über eine Extension [...]

Nur so ein ergänzender

Nur so ein ergänzender Gedanke: Selbst den Theming Layer losgelöst auf eine andere Ebene zu heben, halte ich für nicht machbar, denn dann würden ja die ganzen Hooks auch nicht mehr funktionieren.

Zur Frage, ob sich ein Umschreiben überhaupt lohnen würde, wären natürlich mal Benchmarks interessant. Also insbesondere wieviel langsamer ist OpCode-Caching gegenüber Binaries. Ohne konkrete Zahlen klingt die Überlegung ansonsten eher sehr theoretisch.

Tuning und Optcode Cache

Danke für die vielen Kommentare.

@Jochen @Manuel

Ich kann gut verstehen, dass man auch auf der PHP Seite von vieles tun kann bzw. meine Tests zeigen, dass es eher immer darum geht, dass man besser cached und weniger lädt. Aber warum sollte man denn keine Turbo-Ente bauen? Wir verwenden ja auch solr und nicht MySQL zum suchen, auch wenn MySQL mit PHP noch eine ganze Menge mehr können. Ich denke, man sollte da verteilt arbeiten und alle Möglichkeiten ausloten. Allerdings haben wir mit dem Anschauen auch erkannt, dass es uns zur Zeit einfach zu aufwändig ist. Man müsste das gesamte Theming in C kippen. Und das sind dann bei allen Abhängigkeiten wohl mindestens 50% von Drupal. Und das ist dann auch das, warum HipHop interessanter ist. Man müsste velleicht einen Teil von Drupal machen, der HipHop sein kann, und der Rest ist echtes PHP. Mal schauen. Mit Drupal 20 geht das dann alles ;)

@Jürgen

OptCode Caches hatten mal Optimierungen für den Quelltext, sind aber immer noch keine Binaries. Wie Johannes Schlüter im Podcast auch erzählte, kann man da bei PHP eine Menge noch machen. In Java und in .Net werden die Binaries im Speicher gehalten und können so sehr gut angesteuert werden und laufen. Der Artikel hier ist zwar eher eine Ente, da es sich nicht durchsetzen wird - zeigt aber, dass man mit Methoden die .Net verwendet noch eine ganze Menge an Leistung holen kann. Läuft PHP auf .NET schneller?

Ein interessanter Ansatz! Wie

Ein interessanter Ansatz! Wie dir sicher auch bekannt ist, hat bereits Facebook diesen Ansatz bis zu einem Produkt verfolgt. "HipHop" und heute die HipHop Virtual Machine verfolgen ja genau diesen Ansatz. PHP wird zu nativem C Code compiliert. Leider funktioniert das nicht, wenn die "eval" PHP Funktion verwendet wird, was bei Drupal der Fall ist.
Wie Jochen aber auch schon schreibt, gibt es so viele andere Stellschrauben, die auch in der Zukunft noch kompatibler sind als das Auslagern der Funktionen in eigene Extensions. Denke mal dran, wenn Drupal 8 erscheint, müssten im schlimmsten Fall all diese Funktionen erneut ausgelagert werden.
Mögliche Stellschrauben sind dann auf jeden Fall Op-Code Caching (z.B. mit APC) und dann diverse Caching Systeme wie Varnish (Pressflow) oder auch das Drupal-eigene Caching-System. Wir haben mit diesen Systemen bei hoch frequentierten Seiten sehr gute Ergebnisse erzielt.

OP-Code Caching

... könnte vieles davon automatisch bieten. Der gesamte PHP Code wird eingelesen und wird zur Runtime (vor-)compiliert, so dass ab dann der optimierte Code ausgeführt werden kann. Ich kenne keine aktuellen Benchmarks aber es klingt so als ob dies sehr nahe an den oben beschrieben Ansatz heran reicht ohne den ganzen Aufwand der (1) Programmierung, (2) Testing und (3) Updating.

Grüße
Jürgen

Von außen her optimieren

Sicherlich ein interessanter Gedanke. Meiner Erfahrung nach gibt es allerdings in den äußeren Schichten der "Drupal-Zwiebel" so viel Tuning-Potenzial, dass Eingriffe wie die hier beschriebenen erst dann wirklich Sinn ergeben, wenn alle anderen Möglichkeiten (Caching, Eliminierung schwacher DB-Anfragen usw.) ausgeschöpft sind. Sonst ist das meines Erachtens ähnlich vergebliche Liebesmüh' wie das Einbauen eines Porschemotors in eine Ente.

Herzliche Grüße,
Jochen

Kommentar hinzufügen

Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Mit dem Absenden dieses Formulars, akzeptieren Sie die Datenschutzrichtlinie von Mollom.