Kategorien
Warum die meisten PHP-Framework-Vergleiche Grütze sind!
PHP Frameworks gibt es bekanntlich wie Sand am Meer. Jeden Tag veröffentlichen enthusiastische Entwickler ihr neues PHP Framework und wollen damit die Welt erobern. Und auch die alteingesessenen Frameworks werden stetig weiter entwickelt. Es liegt in der Natur der Sache, dass die meisten von ihrem Lieblingsframework total überzeugt sind. Und wenn ihnen in einer Diskussion die Argumente ausgehen, warum gerade dieses oder jenes PHP Framework das beste von allen ist, dann passiert was? Genau: es wird schnell ein PHP Framework Vergleich veröffentlicht!
Diese haben meistens das Manko, dass sie nicht wirklich objektiv sind. Und bei jedem Vergleich gewinnt meistens das eigene Lieblingsframework. Ein paar Beispiele:
- Yii Framework ist das schnellste
- CodeIgniter ist am schnellsten
- Adventure PHP Framework ist am schnellsten
- DooPHP ist das schnellste PHP Framework
- Nein, Symfony 2.0 wird das schnellste PHP Framework werden
- Hier gewinnt ausnahmsweise mal das Zend Framework (Ich suche übrigens noch einen ernst gemeinten Artikel, der beweist, dass das Zend Framework das schnellste ist, aber da findet sich wohl nichts, aber ein langsames Framework kommt meinem immer trägeren Denkvermögen natürlich zu Gute 😉
- Und auch CakePHP ist anders, als man beim Lesen der meisten Vergleiche denken könnte, natürlich nicht das langsamste PHP Framework, denn es ist immerhin schneller als Symfony
- usw. usf.
Eine andere Ausprägung dieser subjektiven PHP Framework Vergleiche sind die Feature Vergleiche. Natürlich hat da immer das eigene Framework die besseren, ausgereifteren und natürlich meisteren Features als alle andere. Beispiele? Gerne:
- FLOW3 vergleicht einfach seine neueste Version mit älteren Versionen anderer Frameworks und konzentriert sich dabei nur auf die in FLOW3 enthaltenen Features. Dass andere Frameworks vielleicht auch nette Sachen haben, die FLOW3 (noch) nicht hat, wird da aus Versehen vergessen
- Dieser Vergleich leidet an dem selben Syndrom wie der vorherige, nur hier hat das Adventure PHP Framework plötzlich alle die tollen Features, die sonst niemand hat (gerade Symfony scheint anhand dieser Übersicht noch in den Kinderschuhen zu stecken)
- Manche Vergleiche sind völlig veraltet, aber immer noch prominent in den Suchergebnissen vertreten
- Auch auf dem besten PHP Blog seit Ben Hur, gab es vor kurzem einen Framework-Vergleich
- In der Wikipedia versucht man sich auch an einem Vergleich, der vielleicht etwas objektiver als andere ist
- Ein weiterer Versuch eines objektiveren Feature Vergleiches
- usw. usf.
All diesen Vergleichen, Matrizen und Performance Tests hängen die gleiche Makel an. Sie sind nicht objektiv. Oder veraltet. Oder nicht nachvollziehbar. Die Performance Tests kommen frei nach dem Motto „traue keinen Performance-Test, den du nicht selber manipuliert hast“ zu völlig anderen Ergebnissen. Bei den Feature-Vergleichen wird meistens nur ein Stichwort in den Raum gestellt und dann mit einem Häkchen oder keinem Häkchen, einem Ja oder einem Nein, einem Knick oder einem Knack versehen. Bietet das Framework MVC? Haken dran oder nicht. Bietet es ORM? Haken dran oder nicht. Und oft werden andere, weichere Faktoren wie Entwicklungsgeschwindigkeit, Wartbarkeit, Aufbau der Klassen (viele kleine, oder wenige große), Flexibilität und Erweiterbarkeit, Dokumentation, Größe der Community, Verfügbarkeit von Entwicklern, die sich damit auskennen, Verbreitung oder bekannte Websites, die auf diesem Framework basieren, völlig außer Acht gelassen.
Deshalb meine Behauptung, dass alle PHP Framework Vergleiche Grütze sind. So!
Anhand dieses Beitrags habt ihr sicher erkannt, dass ich die Weisheit mit Löffeln gefressen haben und mindestens den Heiligen Gral gefunden haben muss. Deshalb möchte ich natürlich auch meine Vorstellungen für einen objektiven Framework-Vergleich zum Besten geben.
- Der Vergleich darf nicht federführend von einem Framework Lager durchgeführt werden. Eher wäre es sinnvoll, wenn der Vergleich aus den verschiedenen Lagern gefüttert wird.
- Der Vergleich muss laufend aktualisiert werden, da nichts so alt ist, wie ein alter Vergleich.
- Eine Feature Matrix muss erklärender sein, als nur MVC ja oder nein. Die Kriterien müssen eindeutig und greifbarer sein. Ein nettes Kriterium, das nur von einem Framework verwendet wird, hat in einer Vergleichsmatrix nichts zu suchen, es sei denn, es ist was wirklich tolles wie „enthält künstliche Intelligenz zur Modellierung einer kompletten Website anhand von sieben Tags“. Diese Zusatzkriterien gehören in die Fußnote! Basta!
- Ein Performance-Vergleich macht als „Hello World“ Test keinen Sinn, da er einfach gestrickte und unflexible Frameworks bevorzugt. Es sollten einige HTML-Seiten vorgegeben sein, die jeweils mit dem Framework 1:1 umgesetzt werden. Z.B. eine Homepage, die verschiedene Inhalte angezeigt, eine Suchbox darstellt und an der linken oder rechten Seite so lustige kleine Boxen mit unterschiedlichem Gedöns enthält. Und eine Liste in Tabellenform mit ganz vielen Einträgen, die man selektieren und sortieren kann. Und eine Seite, welche einen Beitrag mit Zusatzinfos, Bildern und so weiter enthält. Und natürlich ein komplexes Formular, mit dem man tolle Sachen machen kann. Solche Seiten erwarte ich für einen Performance-Vergleich und kein „Hello World“ Gefrickel. Selbstredend sollte klar sein, dass die technischen Voraussetzungen (PHP Version, Datenbank, Webserver) identisch sein müssen.
Die Arena ist nun eröffnet. Was haltet ihr davon? Anmerkungen, Diskussionsbeiträge, Beschimpfungen in meine Richtung und Ankündigungen von Geldzuwendungen bitte in die Kommentare zu diesem Beitrag einstellen.
Ben Hur? Ich wusste, dass mir Nils immer bekannt vorkam. 😉
@Ralf Super Artikel und ich gebe dir völlig Recht!
Im Endeffekt muss das jeweils eingesetzte Framework die gestellten Anforderungen erfüllen können (was sie wahrscheinlich alle können) und vor allem den Entwicklern gut „von der Hand gehen“. Mehr ist es nicht.
Die Überschrift ein einem deiner Links bringt es ja gut auf den Punkt:
PHP Framework Benchmarks: Entertaining But Ultimately Useless
Die geschilderten Abhängigkeiten zwischen Features, Performance und ease-of-use führen alle Benchmarks ad absurdum. Und so ist auch dein „objektiver“ Benchmark zum Scheitern verurteilt, da jeder Nutzer für sich selbst entscheiden muss, wie viele Features er nutzen möchte und in welchem Maß „ease-of-use“ und damit verbunden die Entwicklungsgeschwindigkeit einen Einfluss hat.
In vielen Fällen wird es billiger sein einen zusätzlichen Server hinzustellen, als ein paar Personentage in der Entwicklung zu verlieren.
Am schlimmsten sind die Geschwindigkeits-Vergleichsartikel. Wie dämlich kann man sein?
Entweder ich vergleiche zwei vollkommen wunderhüpsch gecodete Applications mit genau dem selben Umfang auf Wartungsaufwand, Einlernaufwand für neue Teammitglieder und Dollars per User Interaction oder ich lasse es. Wenn ich schon sehe wie Tipps gegeben werden den Bootstrapper zu tunen und dann vielleicht das Zend Framework etwas schlechter abschneidet und später sich Entwickler auf diese Mentalgrütze berufen krieg ich den chronischen Würfelhusten und muss schnell weg egal wohin.
Wie wäre es ein Framework zu entwickeln das genau dies ermöglicht. Objektiv verschiedene Frameworks zu vergleichen 😀 Das müsste nicht mal nur auf PHP bezogen sein. Die Problematik gibt es ja auch bei den JavaScript Libraries, Java Webframeworks, … . Einmal definierte Regeln/Vorgaben für ein bestimmten Bereich und jedes Entwicklerteam kann sich selbständig dranhängen. Ist die Frage wie man die Qualität dabei kontrolliert.
Fabien Potencier hat doch immer seinen Standardsatz bei seinen Präsentationen. Symfony ist bei einem „Hello World“-Benchmark eines der langsamsten Frameworks. Was schließen wir daraus? Kein Hallo-World mit Symfony programmieren. Über alles andere sagt es nichts aus.
Auch wenn ich ihn sonst nicht sonderlich mag, damit hat er recht.
Wenn jemand die Seiten für die vorgeschlagenen Benchmark-Tests in 5+x Frameworks programmiert (ZF, Symfony, Cake, CI und Flow3 + x), der sollte seine Zeit lieber andersweitig einsetzen. In der gleichen Zeit sollte man einen ersten Prototypen einer mittel großen Applikation lauffähig haben. Und selbst dann kann man mit jedem Framework gewisse Ziele vollkommen unterschiedlich erreichen (bsw. beim ZF Nutzen der Form-ViewHelpers usw.).
Aber PHP ist eben noch nicht wirklich professionell. An solchen Sachen sieht man dies, wie auch bsw. an den vorhandenen Tools & Angeboten bei MyHammer & Co. Zu Java ist noch ein Stück aufzuholen.
Ich denke der beste Vergleich entsteht einfach, indem jedes für jedes Framework kurz und objektiv beschrieben wird was seine Vor- und Nachteile sind. Eine Featurematrix an sich ist gut und schön, aber jedes Framework hat eben auch Nachteile (zu viele Abhängigkeiten, zu große Klassen, hoher Lernaufwand, …). Und als Entwickler ist man ja (idealerweise) auch nicht nur auf ein Framework versteift sondern prüft vor jedem neuen Projekt ob es eventuell ein anderes Framework gibt, was dieses Projekt vielleicht besser umsetzt. Besser im Sinne von es geht schneller und flüssiger zu entwickeln. Das Porblem, dass man sich in ein Framework festbeisst und es bis auf das Letzte verteidigt ist doch eher, dass man sich eingearbeitet hat und irgendwie zu faul ist sich in ein neues Framework einzuarbeiten. Deshalb muss man natürlich dokumentieren, dass das eigene Framework allen anderen haushoch überlegen ist 😉
Mich als Entwickler interessiert ja nicht ob die Seite 5, 10 oder 20ms braucht bis sie durch ist. Sondern vor allem wieviele Klassen muss ich zwingend implementieren um meinen gewünschten View auf den Bildschirm zu bringen.
Barebone-PHP. Ohne Schnörkel (und leider auch ohne nachvollziehbare Sicherheitsmechanismen) – vermutlich das allerschnellste überhaupt. Um die Java-Fraktion mal wieder mächtig über PHP abkotzen lassen zu dürfen schreibt man am besten ohne Funktionen einfach simpelste PHP-Befehle von oben nach unten wech. Klassen bremsen auch nur aus. Variablen prüfen? Blödsinn, geht doch nur an die Performance. 🙂
Vielleicht wäre ein sinvoller Vergleich mal folgendermaßen umzusetzen:
1. Projektaufgabe stellen (nicht zu schwer)
2. Ergebniswertung klar definieren (Bsp. Zeit eines Seitenaufrufes vom eintreffenden Request bis zum Versand des letzten Bytes an den Browser; Speicherverbrauch für einen Aufruf)
3. Umsetzung mit diversen Frameworks
Da würde mich echt mal ein Ergebnis interessieren. Ich glaube mal ein Beispiel mit einem Taschenrechner gesehen zu haben. Dort musste man nur eine Formel „1 + 1“ oder so eingeben und als Ergebnis kam das korrekte mathematische Ergebnis zurück. Und das ganze unter Last (muss natürlich definiert sein: Anzahl paralleler Anfragen, Prozessorlast im Ruhezustand, …)
Dann könnten man das Projekt auch mal rein prozedural umsetzen und mal schauen, ob es wirklich schneller oder langsamer / besser oder schlechter mit der jeweiligen Umsetzung ist.
Also ich persönlich halte von diesen Vergleichen anhand von Features, Geschwindigkeit, Anzahl der Klassen usw. nix. Dann müßte ich das ZF sofort in die Tonne treten. Das Einzige, was es meiner ?objektiven? Meinung nach von den Anderen abhebt, sind die Features. Trotzdem verwende ich es lieber als alle anderen genannten. Hat wohl was mit meiner selektiven Wahrnehmung zu tun 🙂 und vor allem damit, das ich mit dem Dingens am schnellsten zum Ziel komme. Was andere benutzen? Ist deren Sache.
Solche Test sind wie Statistiken, die alles sagen, aber nichts konkretisieren. Ein bisschen Marketing, ein Hauch von Selbstüberschätzung und vor allem ne Menge Eigenlob.
Die Laufzeit wird mit dem lösen von Aufgaben verschwendet, nicht mit Framework code. Grad bei PHP isses doch eh schon wurscht, es suckt einfach wenn es um Performance geht, da muss ich mich ned über die Frameworks beschweren die die Quadratur des Kreises versuchen und eine interpretierte sprache nicht schnell bekommen 😉
Wir haben hier eines der ach so gescholtenen langsamen Frameworks am laufen und nach Reichweite isses nur eine der größten Sites in D.
Wieso sich alle immer ausmalen was sie machen würden wenn sie ein Facebook wären das weis ich auch nicht, aber wenn Webkrams langsam wird dann ist das FRAMEWORK eine der letzten Stellen wo es hakt.
Ich persönlich halte den neueren Ansatz ebenso für ungeeignet.
Er berücksichtigt nur „FullStack“-Frameworks. Das sind die Monotheisten unter den Frameworks, die behaupten „Du sollst kein Framework neben mir haben“. Ich glaube das ist alles Quatsch!
Wir haben Frameworks für Templates, für JavaScript, für UnitTests, für’s Deployment, für Datenimport und -export … für jeden ZWECK das richtige Werkzeug.
Zum Beispiel: Wir arbeiten mit Yana. Natürlich fragte so ein „Judas“ warum wir nicht Zend nehmen. Antwort: warum nehmen wir nicht beides?
Auch @Roberts Taschenrechner-Idee bringt nicht viel. In Yana: public function add($a, $b) { return $a + $b; }
Versuch das gleiche jetzt mal mit einer Personaldatenbank die auf IBM DB2 und Oracle laufen muss, dann sieht der Vergleich differenzierter aus. In Yana ist die Formularerzeugung ein Zweizeiler.
Jedes Werkzeug hat seinen Anwendungsfall, für den es geschaffen ist und vor diesem Hintergrund sollte man es vergleichen.
Ansonsten vergleicht man einen Hammer mit einer Zange und fragt, welches Werkzeug „besser“ ist.
Zend, Beste !!
Zend ist das beste für WAS? Für UnitTests? Für Templates? Für Deployment? Für Datenimport? Für Persistenzschichten? Für CRUD-Pages? Für Anbindung an JavaScript? Für Business Intelligence Server? Für SAP-Unterstützung?
Ich glaube einfach nicht, dass Zend UnitTests besser kann als PHPUnit, Logging besser als Log4PHP, Deployment besser als PEAR, Templates besser als Smarty, JavaScript besser als JQuery, Business Intelligence besser als Pentaho oder Birt.
So etwas wie das „beste“ Framework gibt es nicht.
@Ulf
>Wenn jemand die Seiten für die vorgeschlagenen Benchmark-Tests in 5+x
>Frameworks programmiert (ZF, Symfony, Cake, CI und Flow3 + x), der sollte
>seine Zeit lieber andersweitig einsetzen. In der gleichen Zeit sollte man
>einen ersten Prototypen einer mittel großen Applikation lauffähig haben.
Vielleicht ein Missverständnis. Es geht nicht darum, dass jemand, der auf der Suche nach einem Framework ist, diese Benchmark-Tests jedes Mal selber programmiert. Das wäre in der Tat zuviel des Guten. Es geht eher um einen unabhängigen Test. Dort soll jedes Lager dann seine dokumentierte Implementation einbringen können. Diese sind wiederum öffentlicht, so dass fiese Optimierungstricks eben entdeckt werden.
@Tom
es geht bei diesem Thema aber nun mal um PHP Frameworks. Und nicht um Template-Engines, Javascript-Bibliotheken oder HasteNichtGesehen. Und natürlich steht es jedem frei, ähnliche Vergleichstests auch für Template-Engines, Javascript-Bibliotheken oder HasteNichtGesehen zu machen.
@Ralf
Ok, da kann sicherlich eine objektivere Betrachungsweise herauskommen, aber das macht natürlich meine spezielle Webapplikation auch nicht schneller bzw. bedeutet das meine Anwendung mit Framework X schneller ist als mit Framework Y. Und dann kommt sicherlich noch hinzu, dass Steigerung von Ladezeiten von 0.05 Sekunden oder weniger auch kaum etwas wert ist wenn der Entwickler dafür eine Woche länger für die Implementierung benötigt. Und ich sehe bei solch einen „Vergleich“ schon die Optimierung der Performance der Frameworks auf genau diesen Use-Case.
@Tom: Gefährliches Halbwissen?
> Ich glaube einfach nicht, dass Zend UnitTests besser kann als PHPUnit,
Das Zend Framework (!= die Firma „Zend“ ;)) nutzt selbst PHPUnit für UnitTests. Das steht etwas im Widerspruch dazu, dass es behauptet, es mache bessere Tests. Es existiert keine Komponente „Zend_Test“ 😉
> Deployment besser als PEAR
Es gibt kein (fertigen) Deploy-Mechanismus im ZF
> Templates besser als Smarty
Die „Template-Engine“ vom ZF ist PHP 😉 Und ja, das ist besser, als Smarty
> JavaScript besser als JQuery
Ich hoffe, das issn Witz 😀 ZF ist in PHP geschrieben und steht somit in keiner Konkurrenz zu einem JS-Framework. Nebenbei gibt es sogar mit „ZendX_Jquery“ eine JQuery-Integration.
@Ralf Viele Leute verstehen unter „Framework“ ausschließlich einen speziellen Subtyp: das FullStack-Application-Framework. Daneben gibt es aber mehr:
Eine der Kategorisierungen, basierend auf Lüecke kennt mindestens 4 Subtypen:
– Application Framework
– Domain Framework
– Class Framework
– Component Framework
Wende unterscheidet zwischen White-Box und Black-Box Frameworks, nennt jedoch ein halbes Dutzend Kriterien, nach denen man weitere Subtypen unterscheidet.
Und Wohlgenannt schließlich, redet auch von „Gray-Box-Frameworks“ und unterscheidet zusätzlich zwischen:
– System Infrastructure Framework
– Middleware Integration Framework und
– Enterprise Application Framework
Am Ende findet sich bei Lüecke der weise Satz, dass es bisher noch niemandem gelungen ist den Begriff „Framework“ abschließend eindeutig zu definieren oder zu klassifizieren.
Quellen:
– Lüecke: „Frameworks kurz und gut“, Hannover 2005.
– Wende: „Klassifikation und Bewertung von Webframeworks“, Leipzig 2007.
– Wohlgenannt: „Application Frameworks in der Praxis“, Wien 2004.
@KingCrunch Du hast die Ironie in meinem Post überlesen. Ja: es war ein Witz. 😉
Mir sind die Dinge, welche du schreibst, absolut bewusst. Ich wollte damit ausdrücken, dass es für jeden Zweck ein passendes Werkzeug gibt. Es gibt nicht das „beste“ Werkzeug für alle Zwecke.
Im Übrigen nutzt ZF für das Deployment ebenfalls PEAR 😉 Also auch das war absichtlich provokativ gemeint.
So völlig abwegig ist der Vergleich aber dennoch nicht: PHPUnit ist ein Domain Framework. Smarty ist ein Component Framework (wie auch Swing). JQuery ist ein Class Framework für JavaScript. PEAR ist ein Class Framework für PHP.
Wenn man also von Frameworks spricht muss man normalerweise erst einmal klären welchen Subtyp und welche Domain man vergleicht. Zum Beispiel: Enterprise Application Frameworks für E-Commerce B2C.
Ansonsten betreibt man Kaffeesatzleserei: genau wie Ralf das in dem Artikel bereits beschrieben hat.
@Tom,
ich denke aber, dass die meisten Leser hier schon wissen, was ich meine, wenn ich von PHP Frameworks spreche. Zumal ich explizit einige genannt habe. Und ich habe eben nicht von Template-Engines, ORMs oder Javascript Bibliotheken gesprochen.
Hallo Ralf,
über den Sinn und Unsinn von Vergleichen wurde bereits im Englisch-sprachigen Raum ausführlich diskutiert. Je nach Fokus eines Framework-Suchenden machen die von dir kritisierten Vergleiche trotzdem Sinn. Suche ich beispielsweise ein Framework, das in seiner Basis-Struktur verdammt schnell ist, weil ich eine Seite mit einem Traffic-Aufkommen wie z.B. Facebook hosten möchte, sind viele als „Grütze“ bezeichneten Vergleiche ein guter erster Indikator für die Auswahl. Hier werde ich sicher kein Framework auswählen, das nicht bei mindestens fünf dieser Vergleiche unter den TOP10 war.
Geht es um das Feature-Set, der Möglichkeit schnell und effektiv entwickeln zu können oder gar ein Framework, das es erlaubt wiederverwendbare Komponenten ähnlich dem JSF-Ansatz in JAVA zu schreiben, werde ich als Suchender sicher andere Kriterien ansetzen.
Man könnte sich als Leser nun auch so weit aus dem Fenster lehnen und die Behauptung aufstellen, dass dem Artikel ebenso ein wenig Objektivität hinsichtlich der Bewertung der Vergleiche fehlt. Denn es ist nicht wenig unverständlich, dass ein Produkt seine eigenen Vorzüge immer hervorheben möchte. Das ist im kommerziellen Bereich nicht weniger der Fall. Und gerade im Bereich der PHP Application Frameworks ist der Markt sehr gesättigt – wie zu Beginn des Artikels angesprochen.
Noch ein Wort zu „Adventure PHP Framework ist am schnellsten“: in diesem 2007 geführten Vergleich wurde (siehe verlinkte Seite) – exakt wegen einiger der im Artikel aufgeführten Kritik-Punkte – eine komplexere Bewertungs-Matrix definiert, die auch einige der in den Kommentaren als vermisst deklarierten Kriterien umfasst. Den präsentierten Link sollte man also besser durch http://adventure-php-framework.org/Seite/103-Yii-vs-APF ersetzten um das im Artikel vorgeführte Klischee besser zu unterstreichen. 😉
Noch ein persönlicher Punkt: ich befasse mich mit der Performance von PHP Frameworks schon seit Ende 2004 im Hosting-Umfeld näher und möchte den Gegnern derariger Vergleiche mitgeben, dass gerade im Hosting von großen PHP-Applikationen oft einige Milli-Sekunden einen entscheidender Kostenfaktor darstellen können. Sicher wiegen diese Zeit in kleinen Applikationen ein größeres Feature-Set nicht auf, ich möchte jedoch diesen Aspekt in der Diskussion nicht unberücksichtigt wissen.
Natürlich gewinnt das eigene Framework bei jedem Test – Wie käme das auch sonst? Man will ja Benutzer bzw. Kunden gewinnen und sie davon überzeugen, das eigene Framework zu verwenden – Ihnen nicht 10 Gründe nennen, wieso Framework XYZ wesentlich besser und schneller ist als das eigene.
In der Werbung wird auch das eigene Produkt als die Revolution dargestellt und nicht erklärt, wieso das Produkt XYZ das eigene in Punkt A/B/C übertrifft.
Was erwartest Du also?
Aber dafür wäre es doch sinnvoll einfach unabhängige Tests zu definieren und diese vom jeweils zu testenden Framework durchlaufen zu lassen…wobei „einfach“ relativ ist.
http://matrix.include-once.org/framework/
Ich hab mich mal daran versucht. Aber es ist übelst schwer objektive Kriterien und Auszeichnungen zu finden. Die Liste enthält viele Details die ausschlaggebend sein könnten, aber wird mit jedem Eintrag unübersichtlicher. Und sehr viel weiter lässt es sich kaum ausbauen. Der Aufwand wird zu hoch, wenn man wirklich einen Vergleich will. Außer man beschränkt sich mal wieder auf die altbekannten und fünf großen Frameworks (aber da brauch man dann auch eigentlich keine Matrix).
Das beste was man erreichen kann sind relative Vergleiche, grobe Kategorisierungen. Es reicht für eine Vorauswahl, in die Details muss man sich selbst reinlesen. Insbesondere die API ist ausschlaggebend, aber auch die kann man nicht minutiös in einer Tabelle erfassen. Und auch ein Abstraktions-Level (neu) lässt sich nur subjektiv abschätzen; schon weil es keine einheitliche Terminologie für sowas gibt.
Hallo,
mal unabhängig von Zahlen empfehle ich http://www.phpbar.de/w/crvcl oder http://en.cr-solutions.net/p/projects da man hier auch eine integrierte Lastverteilung für MySQL und Co. hat. Somit bekommt man auch keine Performance-Probleme. Diese Framework ist vor allem in erster Linie auf Performance entwickelt.