Was ist möglich mit CMS?

Hallo,
mit Typo3 hast du dir ja was ziemlich großes rausgepickt :D Aber da du hier in einem Drupalforum bist erzähl Ich dir mal was: geht alles mit Drupal ;-)
Damit die Eltern selbst Content anlegen können müssten sie sich regestrieren und du der Userrolle die Rechte geben. Formulare lassen sich mit Inhaltstypen (und eventuell CCK-Feldern) erstellen.
Ich seh so garkein Problem. Leg los und wenn fragen kommen meld dich wieder ;-)
lg
Yava

Jo einfach ein paar Rollen anelgen und diesen die entsprechenden Berechtigungen geben. Das ganze lässt sich eigentlich sehr gut mit Drupal umsetzen.
______________________________
Yet Another Drupal Site (YADS)
http://www.rapsli.ch
******************************

Kann ich bestätigen.

Gruß
Andreas

Und damit melde ich mich wieder. ;)

Ich habe noch ein paar verschiedene Tests durchgeführt (in VMWare) und mich dann tatsächlich für Drupal entschieden. typo3 scheint mir doch etwas zu unausgegoren. Joomla hatte mich fasziniert, dort ist die 1.5 aber noch in der Beta - so kann ich nicht arbeiten. Insofern schien mir Drupal die richtige Wahl, auch wenn ich es - grade im Vergleich mit den anderen beiden CMS - als sehr langsam empfinde. Damit scheint sich etwas zu bestätigen, was ich bereits in einem anderen Projekt, dass ich jedoch nur moderativ betreue, schon abgezeichnet hat. Auch meine Seite, die grade mal eine simple News hat, braucht elendig lange zum laden. Scheint, als hätte man bei der Entwicklung von Drupal sehr wenig Energie in Optimierung und Performance gesteckt. Und ja, ich habe den (normalen) Cache eingeschaltet. Egal, momentan kann ich damit ganz gut leben und die große Vodoo-Bodoo-2Mio-Zugriffe-Pro-Sekunde-Seite will ich eh nicht basteln. ;)

Ich habe mir nun ein Paket bei Strato geholt, obwohl ja zum Teil hier davon abgeraten wurde. Da aber Strato momentan offen und deutlich mit seiner Joomla/Drupal-Unterstützung wirbt(!), schien es mir eine gute Wahl zu sein. Und siehe da, die Installation ging vollkommen reibungslos über die Bühne. Sehr schön. Bis ... ja, bis ich dem Theme von 'Garland' eine andere Farbe verpassen wollte - und eine halb unstrukturierte Seite ohne Pics erhielt. Nach verschiedenen Feldversuchen und Forensuchen konnte ich den 'Fehler' zumindest einkreisen. Es ist - wer hätte das gedacht - die "SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006"-Zeile der .htaccess im /sites/default/files directory.

Wenn ich diese Zeile deaktiviere funktioniert alles einwandfrei. Allerdings habe ich dann laut http://www.drupalcenter.de/node/7944#comment-35084 ein ziemlich großes Sicherheitsproblem. :( Der Post darunter leuchtet mir zwar etwas ein, so richtig bekomme ich das aber noch nicht zusammen. Um nun aber nicht gleich (nach 3 Stunden Bastelei) aufzugeben, möchte ich den Fehler zumindest richtig verstehen. Dazu folgende Fragen:

1) Normalerweise kann ich mir eine Datei in einem Web-Verzeichnis anschauen, wenn diese freigegeben ist (ganz unabhängig davon, ob nun über .htaccess oder Verzeichnis/Datei-Attribute). Oder aber ich kann sie mir eben nicht anschauen, weil keine Rechte dazu vorhanden sind. Diese 'Anschau-Rechte' sind aber unabhängig von einer Referenzierung durch eine andere Seite (Link, CSS, etc.), sofern mit Rewrite...-Commands gearbeitet wird. Ist das korrekt?

2) In dem Kommentar wird die sicherheitsrelevante Möglichkeit angesprochen, php-Code durch einen Upload auszuführen. Wie soll es aber möglich sein, dies zu unterbinden, obwohl sie gleichzeitig dann praktisch lediglich im Quellcode(?) angeschaut werden kann? Hat das auch etwas mit den Rewrite...-Commands zu tun?

3) Um den Fall zu verdeutlichen: http://www.drupalcenter.de/files/Logo4.gif
Darauf kann ich problemlos zugreifen. Wenn dort jetzt eine php.1 Datei liegen würde, darauf nicht? *kopfkratz* Irgendwie fehlt mir da eine Info.

Ich würde mich über Aufklärung sehr freuen, danke im Voraus.

Mein letzter Kommentar, versprochen! ;)

Mir ist klar geworden, dass Drupal für einen Otto-Normalverbraucher wie mich nicht das Wahre ist. Schade, dass man diese Tatsache nicht irgendwo groß drangeschrieben hat, das hätte mir einige lange Nächte erspart.

CMS' generell sind möglicherweise Lösungen für große, professionelle Seiten oder aber für Leute, die sich mit ihrem ganz speziellen CMS schon sehr lange beschäftigt haben und es in- und auswendig kennen. Aber nichts für jemanden, der zwar in der Softwareentwicklung und Projektplanung nicht ganz unbeleckt, aber eher Noob im Webdesign ist und eine neue Website aus der Taufe heben will. Der ist auf selfhtml.org besser bedient und hat es auf die herkömmliche Weise wesentlich leichter.

CMS stecken (meiner Meinung nach) noch in den Kinderschuhen, sind in der Handhabung übermäßig kompliziert, lassen sich nur mangelhaft bedienen und bieten zudem kaum Hilfe bei der Erstellung des INHALTES(!) der Seiten. Für jemanden, der bereits eine Website am Laufen hat ist ein CMS sicherlich eine Überlegung wert. Wer aber noch an der Erstellung seiner Seiten sitzt, kann sich nicht noch mit der komplexen Steuerung von Drupal und der ständig wandelnden Art und Weise der Zusammenarbeit der Blöcke, Module, Themes, User, Menus, etc. auseinandersetzen. (Selbst drupal.org sieht heute schon wieder ganz anders aus - keine Beständigkeit zu sehen, eine sehr wichtige Sache für jede Art von SE). Außer, wie gesagt, man kennt sich aus - dann mag das Ganze schon etwas spaßiger sein.

Bei Drupal wird im Gegensatz zu typo3 der Einstieg besonders erschwert. Hat mich bei typo3 das Beispiel mit dem Fußballverein regelrecht fasziniert (sowohl das leichte, elegante Aufsetzen der Typo3-Installation als auch das wirklich starke, einfach und leicht zu lesende und nachzuvollziehende Handbuch zu dem Example), so kann man das 'Kochbuch' hier auf der Seite nur als Ausrutscher abtun. Ganz abgesehen von der wirklich äußerst langsam aufbauenden Seite hier (wie auch drupal.org). Und ich glaube nicht, dass es an den hohen Zugriffen liegt (die ich der Seite durchaus zugute halte). Denn andere mir bekannte auf Drupal fußende Systeme reagieren ebenso träge.

Mit einem echten Beispiel würdet ihr - meiner Meinung nach - wesentlich mehr Kunden, Leute, Programmierer, Designer, etc. erreichen. Selbst google findet bei "Drupal Tutorial" momentan nichts wirklich Vernünftiges.

Vielleicht schaue ich irgendwann nochmal vorbei, wenn ich meine Seite halbwegs brauchbar zurechtgeschneidert habe. Nur werde ich dann wohl schon genug eigene php-Skripte eingebaut haben, die Anbindung zur mySQL-Datenbank anders gelöst haben und Formulare gestrickt haben. Aber vielleicht kann mich Drupal ja dann doch noch überzeugen.

CMS stecken mitnichten in den Kinderschuhen. Aber mir scheint du erwartest, dass du ein CMS findest, dass deine Gedanken lesen kann, noch ehe du sie gedacht hast, um sich 120%ig deinen Skills, deiner Denkweise und Sicht der Dinge anzupassen und das selbst alle möglichen Experten integriert, die dank ihrer Gedankenleserfähigkeiten nicht mit dir kommunizieren müssen (oder vielmehr du mit ihnen) und dir deine WÜnsche auch so von den Augen ablesen können.

Wir sind hier nicht auf der Enterprise und selbst dort musste Data mitunter viel Zeit investieren um Holodeck-Programme zu entwickeln :P

Es mag hart klingen, aber meistens sitzt das größte Problem vor dem Computer. Es würde ja auch keiner sagen "Atomkraftwerke sind total unausgereift, weil ich noch nicht geschafft habe mir mein eigenes zu bauen."

Nimms mir nicht übel, wenn ich gerne mal etwas überspitzt ausdrücke, das soll nur der Verdeutlichung dienen ;-)

Wenn ich schon was lese wie "Mir ist klar geworden, dass Drupal für einen Otto-Normalverbraucher wie mich nicht das Wahre ist.". Was ist denn bitteschön ein Otto-Normal-Verbraucher? Seit wann brauchen Otto-Normal-Verbraucher ein CMS? Und seit wann bauen Verbraucher Websites mit CMS? Ich bau mir als Verbraucher auch nicht die Sachen, die im Supermarkt im Regal stehen, ich konsumiere sie lediglich und verbrauche sie.

Mir stehen die Haare zu Berge, wenn ich sowas lesen muss. Wenn alles im Leben für jeden absolut intuitiv zu schaffen wäre, könnten wir alle Schulen und Universitäten dicht machen...

Über deine übrigen Punkte und subjektiven Eindrücke und den daraus resultierenden Schlussfolgerungen von dir mag ich mich an dieser Stelle nicht auch noch aufregen.

"Mein letzter Kommentar, versprochen! ;)" - Ich könnte damit leben.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Ach Alexander, ich liebe deine Beiträge ;), aber ich muss auch sagen, wo du recht hast, hast du recht. Aber schlussendlich hat zum Glück jeder die freie Wahl und die Wahl ist ja relativ Gross (http://en.wikipedia.org/wiki/List_of_content_management_systems). Also da sollte eigentlich für jeden etwas dabei sein.

Ich muss sagen, dass ich bei meinem ersten Annäherungsversuch auch einen Bogen um Drupal gemacht habe. Erst beim zweiten Mal hat es richtig geklappt. Also, falls es jetzt nichts wird, ist noch lange nichts verloren ;)

Punkte Geschwindigkeit muss ich Tris recht geben. Das ganze Hook System macht Drupal ein bisschen träge, was sich halt vor allem bei kleineren Seiten bemerkbar macht. Ich denke jedoch Skalierung ist eigentlich eine Stärke von Drupal (ich habe noch nie so grosse Seiten gebaut, als dass ich da etwas merken würde).

Und ja, der Otto-Normalverbraucher wird mit Drupal nicht sehr viel zustande bringen, was über den Tellerrand hinausgeht. Wenn jemand jedoch ein bisschen Programmierkenntnisse hat und sich mit der API vertraut macht, der wird Drupal relativ schnell ins Herz schliessen.

Punkte Literatur. ... Falls du kein Otto-Normalverbraucher bist, dann wirst du sicher der Englischen Sprache mächtig sein. Daher wirst du relativ viel Infos auf Drupal.org finden. ... Was sollte ein Drupal Tutorial beinhalten? Die Möglichkeiten sind sehr breit gefächert. Die besten Tutorials finden sich jedoch hier: http://theartlab.net/podcast/drupal-school

Gute Bücher: http://www.drupalbook.com/ und das geht dann eben auch über das Drupal Cookbook hinaus.

Also Tris, es wäre interessant für welches CMS du dich schlussendlich entscheiden wirst/entschieden hast, oder ob du dein eigenes baust.

PS: Dies ist mein 1000 Post. Boa. Ich hoffe, dieser Beitrag ist einem solchen Jubiläum würdig.
______________________________
Yet Another Drupal Site (YADS)
http://www.rapsli.ch
******************************

Ja, die Geschwindigkeit. Obwohl ich von den Drupalmöglichkeiten auch schwer begeistert bin, welche die Geschwindigkeitseinbußen wieder ausgleichen, frage ich mich doch, ob es wirklich so langsam sein muss, wenn eigentlich nichts passiert. Hat dazu jemand eine professionelle Antwort? Geschwindigkeit ist in Drupla suboptimal, ich hoffe dass sich das noch ändert, in den zukünftigen Versionen.

Ist die Jubiläumsfeier dort wo die Taschenmesser herkommen? :-)

Hier noch ein Link zu einer etwas größeren opensource CMS Übersicht, als bei wikipädia, mit features-Vergleichs-Möglichkeit:
http://www.cmsmatrix.org/

@Tris

Ich wünsche dir viel Erfolg mit Typo3 oder einem selbstgemachten CMS, falls du jedoch wieder bei Drupal landest wäre es doch nett, wenn du einfach selbst das "Example" für einen Fußballverein hier im Kochbuch beschreibst. :-)

[/quote]

Es ist nicht wirklich das Hook-System, das die Probleme verursacht. Die wirklichen Übeltäter sind (zu)viele Module (= viele Datenbankzugriffe+RAM Probleme durch extrem viel und oft auch unnötigem PHP Code im Speicher) und das ständige Parsen der (vielen) verfügbaren bzw. durchzuführenden Hooks. Das Drupal oft auf viel zu kleinen Systemen(RAM, kein opcache - wobei das auch teils an Drupal selbst liegt, nur ein Server statt mind. 2, kein load balancer, mieser Datenbank Cache bei MySQL...) läuft hilft da natürlich nicht wirklich.

kurz gesagt : die Flexibilität die Drupal liefert hat einfach ihren Preis, dazu gehört auch die mangelnde Performance im Amateur-Bereich, als "Amateur" sehe ich da alles was auf einem "Server" läuft (laufen kann..., braucht ja nicht jeder eine hohe Verfügbarkeit, Lastverteilung, etc. und ist bereit das nötige Kleingeld dafür auszugeben)

Drupal ist eher ein Framework als "nur" ein CMS, das trifft im Übrigen auf praktisch alle "großen" CMS zu. Dazu kommt noch meine ganz persönliche Meinung, dass vielfach Drupal trotz besserer Alternativen eingesetzt wird. Braucht man für einen simplen E-Shop gleich Drupal ? Braucht man für eine Schul-Homepage (Verein, Club, etc.) gleich Drupal ? Ich denke da oft an die berühmten Kanonen für die Spatzen ;-) WP, Tx, Etomite etc. scheint jedenfalls oft die bessere Wahl vor allem aus der Wartungssicht.

Falls jedoch für Drupal 7.0 wie angekündigt der Bootstrap Prozess verbessert wird (statt Scan bzw. Parsen aller verfügbaren PHP-Funktionen, werden diese dann bei Modulaktivierung in der Datenbank gespeichert - nur die Namen) dürfte sich da einiges tun. Zusammen mit den ständigen Verbesserungen was die Datenbankzugriffe angeht, rechne ich mit ca. 20-30% Verbesserung für "kleine" Seiten. Bei Projekten mit recht vielen Modulen wird aber auch das nicht allzuviel bringen, weil da die Datenbank (und/oder ineffiziente caching Strategien) so ziemlich das einzige Problem darstellt.

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.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Und wie stehts damit? :D

Ne, Spass bei Seite. War echt interessant deine Ausführungen. Dann mal nur so nebenbei, auf was für einem System läuft das DC?
______________________________
Yet Another Drupal Site (YADS)
http://www.rapsli.ch
******************************

Ich denke ich verrate keine großen Geheimnisse, ansonsten bekomme ich nun von bv und/oder mdwp was aufn Sack, aber DC läuft derzeit auf nem größeren Shared Hosting Paket eines nicht unbekannten Dienstleisters.

Es hat etwas gedauert (erste Gespräche hatten wir um die Jahreswende), aber nun sind die Weichen gestellt für eine bessere technische Basis. Kurzum: DC wird auf einen dedizierten Root-Server umziehen, der gerade entsprechend von uns eingerichtet wird. Einen konkreten Zeitplan gibts nicht, weil die Einrichtung wieder so eine Freizeitgeschichte ist, aber natürlich soll nicht auf ewig doppelt gezahlt werden.

Vorab ein paar Eckdaten des neuen Servers:
- Athlon64 X2 5600+
- 2 GB RAM
- 2 x 400 GB HDD (Software RAID 1)

Zum Einsatz kommt Debian Etch (4.0) in der 64 Bit Version als Betriebssystem und ganz normal Apache, PHP 5, MySQL 5. Zusätzlich gibts noch nen Opcache für PHP, ModSecurity für Apache und diversen anderen Krims ;)

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Super Sache das.

Mal zur Performance von Drupal:

Es ist nämlich durchaus so, dass Drupal jede Menge Unsinn bei vielen Seitenaufrufen (besonders fühlbar als angemeldeter User und noch mehr im Admin-Bereich) doppelt und dreifach aufruft. Kann ja jeder hier noch einen Hook reinknallen und irgendwas aufrufen. Habe mal eine Diskussion mitbekommen, wo einer das mit Devel alles nachgeguckt und gemessen hat und dann immer wieder meinte: was soll das, warum wird das hier aufgerufen, das brauchen wir doch da gar nicht.

Für Drupal 7 gibt es Pläne einer "Introspective Code Registry" http://www.garfieldtech.com/drupal-7-registry die vor allem den Bootstrap Prozess (was immer das genau ist ;) ) ins Visier nimmt, der die meiste Zeit verbrät. Soll heissen, man ist sich der Probleme immerhin bewusst und schraubt dran. In einem Test in der Internet Pro vor einer Weile gegen Typo3 und Joomla war Drupal immer noch klar das schnellste System. Ist vielleicht aber eine schlechte Testbasis.

Wenn man durch Ruby-Seiten wie http://venteria.com surft, kriegt man schon feuchte Augen. Ruby ist offensichtlich sehr viel stringenter durchgeplant als PHP, und z.B. diese Seite läuft DEUTLICH schneller als jede Drupal-Seite, die ich besucht habe. Auch als angemeldeter User. Es geht also.

Drupal - too unorganised to be a system

Ruby-Seiten? Ich nehme an, du meinst Rails? Rails so sehr zur Sprache/Plattform Ruby, wie Drupal zu PHP. Sprich, es baut lediglich darauf auf. Von daher wäre "Rails-Seiten" korrekter.

Was die Performance angeht gibt es eine Reihe von Leuten, die sehr einfache selbst gestrickte Benchmarks geschrieben und verglichen haben. Es ist die Mühe nicht wert sich die Ergebnisse anzuschauen, weil Mikrobenchmarks der Form "ich sortiere 20.000 Strings und messe die Zeit und das ist es dann auch" kaum eine Aussage über die Anwendungsperformance zulassen.

Die Anwendungsperformance wiederum lässt kaum direkte Rückschlüsse auf die Geschwindigkeit des Interpreters zu. Man findet im Web diverse Benchmarks beispielsweise zwischen Symfony, Ruby on Rails und Django. Selbst das RoR Wiki enthält dazu einen Test, der in Bezug auf die Performance die Aussage macht Django (Python) > Rails (Ruby) > Symfony (PHP). Das gilt dann aber auch nur für das jeweilige Szenario.

Was bei professionellen RoR Anwendungen auffällt ist aber ganz einfach, dass die Systeme dahingehend optimiert sind. Da wird ein Mongrel Cluster mit mehreren Frontend-Servern auf lighttpd-Basis aufgesetzt, während man bei PHP-Anwendungen einfach den Server von der Stange nimmt (mit Apache), ggf. noch APC/eAccelerator/.. installiert und das ist es dann. Das hat natürlichm viel damit zu tun, dass PHP überall ganz eifnach verfügbar ist, während man vom Deployment von RoR schon Ahnugn haben muss, was die Serverkonfig angeht. Und Leute die Ahnung haben, können etwas eben besser tunen, als solche, die einfach alles lauffähig vorfinden und nur noch die Anwendung einspielen müssen.

Von daher ist deine Beobachtung bzgl. venteria.com nicht überzubewerten. Du wirst vermutlich nämlich auch nicht wissen, was für ein Server-Setup die fahren ;)

Schaut man sich in der RoR Szene mal etwas um, gibt es dort zuhauf auch kritische Stimmen bzgl. der Performance und Stabilität von RoR, bzw. Mongrel & Co. Da RoR Anwendungen derzeit aber noch einen eingebauten N00b-Abwehrmechanismus beherbegen, ist das Netz noch weitestgehend frei von schlecht designten (Im Sinne des System-Designs) RoR-Anwendungen, während wir uns hier im Forum ja immerwieder mit Kommentaren von Lieschen Müller beschäftigen müssen, der ihr Drupal mit 87 Modulen auf dem 50-Cent-im-Monat Web bei Billigheimer&Co. schlecht performt.

Dass RoR gut skaliert ist nicht zuletzt auch eine Folge des Gedankens hinter RoR, für 90% der Fälle gerüstet zu sein und bewusst die übrigen 10% gar nicht abdecken zu wollen. Es handelt sich also um ein System, dass für sich nicht den Anspruch erhebt alles und jeden befriedigen zu wollen, was das Design entsprechend auch vereinfacht.
Ich denke das kennt jeder ausm Projektgesachäft. Die meisten Projekte wären innerhalb der angepeilten Zeit problemlos umsetzbar, wenn nicht der Kunde auf einmal noch ein paar Kleingkeiten mehr hätte, die das ganze angedachte Design in Frage stellen.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

P.S.:

Der Vergleich RoR mit Drupal ist auch nicht ganz fair, denn RoR ist kein CMS, sondern ein Framework zur Erstellung von Webanwendungen. Während bei Drupal Daten- und damit auch Datenbank-Strukturen vorgegeben sind, sind diese bei RoR erst noch zu erstellen.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Yep - eigentlich mal ganz erfrischend, hier über was anderes als das belgische Blue System zu sprechen ;)
Es zählt jedoch, was am Ende rauskommt. Und viele Drupal Seiten performen definitiv schlecht, auch die teurer gehosteten. Und den Kunden, der sich dann ne Seite wie venteria oder wasauchimmer anguckt, ist es definitiv egal, wie es dazu kommt, wenn du es ihm erklärst, sagt er am Ende trotzdem "Machen sie mir die Seite schnell, wie, das ist ihr Problem".

Es muss definitiv was getan werden, und man darf gespannt sein, was diese Code Registry bringt.

Drupal - too unorganised to be a system

Der Wunsch ist aus Kundensicht legitim. Nicht legitim ist die Schlussfolgerung von der Gesamtperformance einer Black Box auf die Leistungsfähigkeit der einzig bekannten Teilkomponente.

Ohne harte Fakten gibt es keine Vergleichbarkeit. Wer als Kind Quartett gespielt hat, weiß was ich meine ;)

Man sollte es sich nicht so einfach machen und alle Vernatwortung auf die Core-Coder von Drupal schieben.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Nochmal zum Theme Performance von Webanwendugen:

Six Revisions hat dazu gerade einen schönen Artikel online, "15 Tools to Help You Develop Faster Web Pages".

http://sixrevisions.com/tools/faster_web_page/

--
"Look, Ma, I'm dead!"
Cell, Stephen King