Ich habe mich immer gefragt, wie die Anzahl an Modulen die Drupal Performance beeinflusst. Ich habe mich oft gefragt, ob es besser ist viele kleine Module zu haben, oder aber ein grosses. Endlich bin ich dazu gekommen einen kleinen Benchmark zu machen. Rein der Übersichtlichkeitshalber ist es eigentlich viel besser die ganzen Funktionalitäten in kleine Module zu unterteilen, was aber dann zur Folge hat, dass das Hook System stärker belastet wird.
Der Testumgebung sah wie folgt aus:
- Drupal 6.16
- Drupal Core Module aktiviert (und nur diese, keine anderen), sprich das sind insgesamt 5 Module.
- Cache deaktiviert.
- Ubuntu 9.10
- 11 Nodes im System, welche auf der Startseite erscheinen.
Für die Startseite werden 14 Hooks aufgerufen (boot, init usw.).
Der Test ist wie folgt durchgeführt worden: Mittels “ab”, wurden 1000 Anfragen hintereinander durchgeführt, und die durchschnittliche Antwortzeit gemessen, dabei wurden bei jedem Testdurchlauf mehr und mehr Module aktiviert (10 bis 320).
Hier mal die Resultate. Die Y-Achse ist die Antwortzeit in Milisekunden, die X-Achse die Anzahl an aktivierten Modulen, wobei jede Kurve einer anderen Art von Modulen entspricht.
Empty Modules: Ein leeres Modul, kein Hook, nichts, lediglich “<?php” ist drin. Im Grundzustand braucht ein Seitenaufruf 25 ms, bei 100 leeren Modulen bereits 31 ms (Zunahme um 23%) und dies wohlgemerkt, obwohl überhaupt keine zusätzliche Funktionalität hinzugekommen ist.
Simple 1000x Loop: Gleiches Szenario, wie vorher, aber diesmal ist der hook_init in jedem Modul implementiert, welcher einen einfachen Loop beinhaltet:
$t=0;for($j=0;$j<1000;$j++){$t=$t*2;}
Wie zu erwarten, steigt die Kurve linear, jedoch viel steiler, als vorher. Nach dem Einschalten von 100 Modulen, verlängert sich die Antwortzeit der Seite um 90%
Simple 1000x Loop, with Comment: Jedes Modul, wurde mit Kommentar aufgefüllt (die Testmodules waren danach ca. 23 KB gross). In der Antwortzeit war dadurch keine allzugrosse Veränderung feststellbar. Interessanterweise, waren die Antwortzeiten sogar eher ein bisschen darunter. Keine Ahnung warum.
Simple 1000x Loop, with Comment (no APC): Interessehalber, habe ich mal den APC abgeschalten. Die Antwortzeiten sind um ein vielfaches höher! Ist ja auch klar, denn die ganzen zusätzlichen Dateien müssen jedes Mal frisch geladen werden. Daher: Grosse Installationen brauchen unbedingt einen OPcode cache!!
Fazit
Ich bin mir ehrlich gesagt noch nicht ganz sicher, was diese Grafik aussagen soll, hier aber schon mal meine ersten Gedanken.
Jedes Modul kostet Ressourcen, auch wenn es noch so klein ist. Ich bin jedoch der Meinung, dass die “Grundkosten” relativ gering sind, wenn wir von einer einfachen Seite ausgehen, sprich, wenn ich ein Modul habe, welches lediglich dem Administrator etwas bringt, dann ist die Performanceeinbusse auf Besucherseite relativ gering, aber nicht vernachlässigbar!
Diese steigen natürlich weiter an, wenn es Module gibt, welche zusätzliche Hooks bereitstellen, denn jeder Hook, der “abgefeuert” wird, ist eine zusätzliche Belastung fürs System: Views zum Beispiel stellt zusätzliche Hooks zur Verfügung. Im aktuellen Testsetup werden 14 Hooks aufgerufen, um die Seite zu bauen. Interessant wäre zu wissen, wie sich die Antwortzeiten verhalten, wenn 28 Hooks aufgerufen werden.
Alles in Allem: Je weniger Module desto schneller die Seite, je weniger komplex die Funktionen, desto schneller die Seite.
APC (oder sonst ein OPcode cache) ist ein Muss!!
Dort werden diverse Funktionen gebündet, welche in diversen anderen Modulen immer wieder gebraucht werden (hauptsächlich Panels und Views). Dazu gehören unter anderem: Diese Overlays, Exportmöglichkeiten und das Pluginsystem.