Auf Drupalcenter gab es eine ziemlich hitzige/witzige Diskussion bezüglich der Performance von Drupal. Ich kann mir einfach nicht verkneifen diesen hier zu posten, da doch sehr informativ und auf den Punkt gebracht.

Ich habe bisher leider noch keine Erfahrung mit hochperformanten System, bin jedoch an der Entwicklung eines solchen…

Alexander (22.5.08):

Das Problem mit Drupals Performance liegt mehr in den Reports begründet, die in der Regel (wie auch hier) nicht qantifiziert werden. Damit kann man dann aber in einem deterministischen System nichts anfangen und so wird "Performance" von etwas absolutem, weil messbaren, zu etwas rein subjektivem.

Dazu gibts auch andernorts Beispiele:
Als Windows XP auf den Markt kam, dachten alle es würde schneller starten. Warum? Weil der Dsktop früher angezeigt wird und das Laden diverser Software und Komponenten erst dananch stattfindet. Das Ergebnis ist, dass das System gefühlt schneller startet, man aber wenigstens ebenso lange warten muss, ehe man wirklich damit arbeiten kann. So wurde Performance zu einem Thema, zu dem jeder meinte etwas fachlich fundiert beitragen zu können.

Ähnliche Probleme kenne ich aus meiner Zeit als Java-Entwickler. Client-Anwendungen in Java gelten als langsam, weil das User Interface Swing oft als sehr langsam empfunden wird, nicht reagiert, hakt, … Das Problem ist nicht, dass Java oder Swing langsam sind, sondern weil die Entwickler der Software nich verstanden hatten / nicht umzusetzen wussten, dass das User Interface im Event Dispatcher Thread läuft und das zeitaufwändige Vorgänge in der Software da rausgehalten werden müssen (mittels Threads), um die Signalverarbeitung nicht zum Stocken zu bringen.

Zurück zu Drupal:
Eine Drupal-Website ist, wie jede Webanwendung, eine mittlerweile recht komplexe Angelegenheit. Wir haben die Datenhaltungsebene, umgesetzt über eine realtionale Datenbank und wir haben eine Dateiebene, auf der wir die Programmdateien des CMS, Konfigurationsdateien und allerlei statische Dateien (HTML-Snippets, Template-Dateien, CSS-Dateien, Bilder, Media-Dateien, …). Für die Abarbeitung eines HTTP Requests auf das CMS wird der gesamte benötigte Code auf Dateiebene eingelesen, wird der Code geparst und ausgeführt, werden Abfragen an die Datenbank gemacht und wird Output generiert. Typischerweise finden sich in diesem Output noch reichlich Anweisungen an den Webbrowser zusätzliche Ressourcen zu laden, wie CSS-Dateien, Bilder die im CSS verwendet werden, Bilder die im HTML-Teil verwendet werden, Flash-Dateien, Media-Dateien, JavaScript-Dateien, … Dazu kommen dann vielleicht noch JS-Spielereien, die erstmal geladen sein müssen und dann nochmal den Code umbauen oder Daten nachladen.

Wenn wir nun von einem langsamen Gesamtsystem reden gilt dasgleiche für ein CMS wie auch für eine "normale" Anwendung: Zunächst einmal müssen die Bottlenecks identifiziert werden. Wo also wird im Prozess zwischen dem ersten Request an den Server und dem vollständigen Rendern der Website wieviel Zeit verbraten?

Darin gehen Leitungsgeschwindigkeiten ein, Latenzzeiten für einzelne Aufrufe, Caching auf Dateiebene des Servers beim Einlesen der Dateien, ggf. Caching eines PHP-Moduls um ständige Neuparsen von nicht verändertem Code einzusparen (APC, Zend Cache, …), Caching auf Dateiebene des Servers für die Datenbank, Caching der RDBMS für Abfrgen und Daten, Normierungslevel der Datenbank, Effizienz der Datenbank-Abfragen, Optimierung des PHP-Codes, Wahl der Datenstrukturen durch den Entwickler, Wahl der Algorithemn durch den Entwickler, … die Liste lässt sich noch ne ganze Weile weiterführen.

Was gerne außer Acht gelassen wird, hier im Forum, demonstrieren Aussagen wie, "Ich habe auch andere Drupal-Seiten gesehen die waren total langsam.". Da sage ich: "Okay, ich habe schon viele statische Websites gesehen die auch langsam sind."
Das soll mal verdeutlich, was manche hier gerne tun, nämlich allein auf Basis einer einfachen Beobachtung eine ziemlich heftige Schlussfolgerung zu ziehen, ohne diese auch nur im Ansatz fachlich belegen zu können.

Schnappe ich mir als Laie ein CMS, klatsche alle möglichen Module rein und benutze ein Theme, dessen Entwickler (sollte ich es nicht selbst gewesen sein) vielleicht nicht der cleverste war, klatsche noch Google Maps hier und irgendwelche Web-Preview-JS-Klamotten dort rein und lasse das ganze bei einem Dumping-Hoster laufen, muss ich mich nicht wundern. Und wenn das 1000 Leute machen und ich all deren Websites abgrase liegts dennoch nicht zwingend am System als solchen.

Gerade Shared Hosting hat das Problem, dass die überhaupt für das CMS verfügbare Performance nicht einzuordnen ist. Keiner weiß was für eine Hardware da werkelt, wie das System konfiguriert ist und womit es sonst noch beschäftigt ist, wer da noch drauf gehostet wird und welches Schindluder deren Webanwendungen gerade treiben, wenn ich mal draufschaue. Und da will mir anmaßen die Performance von Drupal zu beurteilen?

Das ist wie Schumi in ein Kettcar setzen und sagen: "So wie der fährt, wird er nie Formel1-Weltmeister!"

Schaut man sich mal an welche Referenz-Websites mittlerweile mit Drupal laufen, ist es schwer vorstellbar, dass Drupal generell Performance-Probleme haben soll. Wir reden da von einer ganzen Reihe von Websites mit zig Millionen Hits. Wenigstens eine Website mit zig Millionen Hits betreiben und hosten wir auch und Performance ist gar kein Problem. Da reden wir noch nicht von Multi-Server Setups, sondern von einer einzelnen Maschine, die sich erst dann mal halbwegs ausgelastet fühlt, wenn sie des Nachts mal alle Daten zusammenrafft und packt, ehe sie sie auf den backup-Server schiebt.

Am Ende ist es wie so oft: Man bekommt, wofür man zahlt.

Wenn also mal wieder wer meint seine Drupal-Site sei langsam, soll er mal mit spezifischen Angaben anrücken, damit man überhaupt mal Anhaltspunkte hat, in welche Richtung man weiterforschen kann.

Aber einfach zu sagen "Drupal ist langsam" ist natürlich einfach.

P.S.:
Man kann mit Benchmarks belegen, dass im Vergleich zu anderen Sprachen Ruby recht langsam ist, was sich wiederum auch auf Ruby on Rails auswirkt. Das hat aber niemanden davon abgehalten performente Lösungen in RoR zu entwickeln.