Viele von uns WebEntwicklern wurden ja die letzten Jahre Dinge wie MVC und Ajax regelrecht aufgezwungen und da es meist keine trivialen Frameworks sind, muss man sich erstmal anschauen worum es sich dabei handelt. Ich habe mal vor vielen Jahren mit Assembler angefangen und wahr wirklich sehr Systemnah. Das hilft mir auch noch heute ziemlich konkret zu verstehen welche Schichten es bis runter zum Silizium gibt und was optimaler Code aus der Sicht der Maschine ist.

Dinge wie z.B das Symfony MVC Framework sind natürlich auf unterster Ebene ein Albtraum, wenn man sich mal anschaut was da passiert, aber egal. Viel schlimmer finde ich Dinge wie diese unsäglichen Abstraktionlayer die z.B den Versuch unternehmen SQL und DB Schicht von der drüberliegenden Anwendung zu isolieren. Ich kenne derartige Versuche seit Anfang der 90er Jahre und Anfangs war ich auch begeistert, nur als ich es in der Praxis einsetzen wollte,
war es eine pure Zumutung, das blanke Grauen. Heute stehen die alten Zombies in Form von Symfony, Hibernate und Co wieder auf und Legionen von Lemmingen meinen das wäre was tolles. So auch bei derzeitigen Relaunch von ******.** der mal gehörig daneben ging und das ist nicht die einzige Opferseite die ein MVC Framework trotz gar nicht mal so dummer Programmierer in die Knie gezwungen hat.

Beim Masseneinsatz von JavaScript und Ajax deuten sich ebenfalls massive
Probleme an. So vermelden unzählige Laptopbesitzer das manche Seiten
durch intensive JavaScript und Flash Nutzung ihre Notebooks ins schwitzen bringen und parallele Prozesse durch zu hohe Rechenlasst des Browsers massivst erschwert werden. Auch bringt das oftmals anzutreffende Geblinke und Gewackel durch zahlreiche Animationen die Leute ziemlich gegen die
Betreiber auf. Die Programmierer finden es toll, die Anwnder zum kotzen.

Nicht für jede Art Website Projekt sind diese beiden Sachen geeignet. MVC
Drivven Frameworks sind für Sites mit einem hohen aufkommen an parallelen
Nutzern völlig ungeeignet und der Overhead alleine auf HTTP Ebene um auch nur ein kleines bißchen HTML zu rendern sind ennorm und potenzieren sich
bei vielen, parallelen Connections zum HTTP-Client derartig das auch ein zig
tausend EUR teurer SUN-Server am Ende in die Knie geht. Ganz anders verhält sich dieser Aspekt bei einfachen Seiten, ohne Controller und Views oder gar Modelle die durchlaufen werden müssten.

[Artemis]

Willst du damit jetzt eine Diskussion über MVC anstoßen, oder Werbung für die von dir erwähnte Seite machen, oder worum geht es dir?

[Bleistift]

Zitat von Artemis

Willst du damit jetzt eine Diskussion über MVC anstoßen, oder Werbung für die von dir erwähnte Seite machen, oder worum geht es dir?

Frag ich mich auch. Schwenke gerade zwischen Schleichwerbung und Troll...

Zitat von Artemis

Willst du damit jetzt eine Diskussion über MVC anstoßen,

Ein Blitzmerker wie mir scheint. Junge, junge. Du merkst auch alles!

[Jann Hendrik]

Zitat von marc9022

Ein Blitzmerker wie mir scheint. Junge, junge. Du merkst auch alles!

Willst du eine Diskussion oder Leute anpöpeln?

http://www.developers-guide.net/nutzungsbedingungen/
-> §3 (3)

um nur einen Punkt zu nennen!
Also - ein Gang runterschalten.

[dr.e.]

da es meist keine trivialen Frameworks sind

Allein dieses Oxymoron zeigt, dass man den Post nicht wirklich ernst nehmen kann. Du solltest a) deine Argumente überdenken, die Äpfel mit Birnen vergleichen und b) mal performantere MVC-Implementierungen wie die genannten anzusehen.

Zitat von dr.e.

Allein dieses Oxymoron zeigt, dass man den Post nicht wirklich ernst nehmen kann. Du solltest a) deine Argumente überdenken, die Äpfel mit Birnen vergleichen und b) mal performantere MVC-Implementierungen wie die genannten anzusehen.

Nö, eigentlich zeigt das eher das Du nicht in der Lage bist Dich auf die Detailierte Kritik die bis auf die Maschinencodeebene hinab geht einlassen kannst und daher werde ich dazu auch nichts weiter schreiben, es sei denn es kommt mal etwas sachdienliches das zum Thema gehört, denn ich bin eigentlich nicht daran
interessiert die Meinungen von Amateuren ohne Tiefenwissen zu debattieren und dein Beitragt zeigt ja das Du außer Polemik und billigen Denunzierungsversuchen die Ihr Ziel verfehlen nichts gehaltvolles von Dir zu geben hast. Wer so angepisst reagiert nur weil man die für manche Leute heilige Kuh MVC wagt anzuzweifeln kann kein Kenner der Thematik sein und
wird sicherlich nie an größeren Projekten mit signifikanten, konkurierenden Usertraffic befasst gewesen sein.

Ich werde deinen Nonsens sicherlich nicht weiter bewerten in dem ich Dir antworte. Mit sachdienlichen Beiträgen befasse ich mich jedoch gerne, nur beschleicht mich langsam das Gefühl das solche Leute hier rar sein dürften.

Vielleicht sollte das ganze Forum umbenannt werden in Basic und PHP Anfängerforum oder so.

[MrNiceGuy]

Ich denke, dass sich garantiert über die Vor- und Nachteile von MVC diskutieren lässt Dass es sicher auch nicht die performanteste Arbeitsweise für einen Computer darstellt sollte auch klar sein, denn das MVC-Pattern wurde sicher nicht entwickelt, um dem Computer geschwindigkeitstechnisch unter die Arme zu greifen, sondern es den Programmierern einfacher zu machen, wiederverwendbaren Code zu produzieren und bestimmte Segmente voneinander zu trennen (z.B. HTML vom PHP). Die Arbeitsweise finde ich persönlich überaus praktisch, obwohl ich noch nicht so lange mit MVC arbeiten. Die Vorzüge für mich sind jedoch größer, als die vermeidlichen Nachteile: Ich besitze übersichtliche, kleine Code-Teile statt einer riesigen PHP-Datei mit PHP und HTML komplett in einer Datei und ich habe gekapselte Funktionen, die ich variabel überall wunderbar integrieren kann, ohne den Code erneut programmieren zu müssen.

Wenn du nun allerdings rein aus Performance-Sicht MVC verteufeln willst, solltest du glaube ich eher die Programmiersprachen ansich zur Diskussion stellen, denn JAVA / C / PHP / Perl / etc. sind alle deutlich langsamer als ein Gegenstück in Assambler.

Aber: Um deiner Diskussionsgrundlage etwas den Wind aus den Segeln zu nehmen: Niemand wird gewzwungen ein MVC-basiertes Framework zu benutzen, die Entscheidung liegt alleinig beim Programmierer, von daher verstehe ich deine Aufregung nicht so ganz!? Wenn der Programmierer eine Aufgabe zu bewältigen hat, schaut er, wie er dies lösen kann. Entscheidet er sich für die Verwendung eines Frameworks, ist er alleine in der Verantwortung, dass der Code dann a) funktioniert und b) die Systemvoraussetzungen passen. Dazu zählt auch bei zu starkem Traffic genug Power in der Hinterhand zu haben, dies zu kompensieren. Sei es durch gut programmierten Code oder durch die Bereitstellung der notwendigen Hardware. Ich bezweifle jedoch, dass man so stark verallgemeinern kann, wo der Flaschenhals einer Software liegt, ich denke nämlich, dass es nicht unbedingt das Framework sein MUSS, da auch Datenbanken ihre Tücken haben - egal, WIE toll ein Programmierer ist...

Danke für deine Sachbezogene Einlassung zum Thema.

Zitat von MrNiceGuy

Ich denke, dass sich garantiert über die Vor- und Nachteile von MVC diskutieren lässt Dass es sicher auch nicht die performanteste Arbeitsweise für einen Computer darstellt sollte auch klar sein, denn das MVC-Pattern wurde sicher nicht entwickelt, um dem Computer geschwindigkeitstechnisch unter die Arme zu greifen, sondern es den Programmierern einfacher zu machen, wiederverwendbaren Code zu produzieren und bestimmte Segmente voneinander zu trennen (z.B. HTML vom PHP).

Das sehe ich ebenso. Und diese Aussage unterstützt auch das was einer der
Programmierer des populären Symfony MVC Frameworks für PHP5 dazu auch selbst sagt:

If frameworks exist, it is not for the purpose of speed, it is for ease of programming, and to decrease the cost of a line of code. This cost not only consists of the time to write it, but also the time to test it, to refactor it, to deploy it, to host it, and to maintain it over several years.

So the best way to display a “hello, world� in terms of performance is probably:
<?php echo "hello, world" ?>

Quelle:
http://www.symfony-project.org/blog/...al-world-usage

Damit ist dann wohl auch klar, das solche MVC-Frameworks für normale für Coorportate und
Firmen Websites Sinn macht (z.B im Agenturmassengeschäft) in Umgebungen wo VServer oder Rootserver vorhanden ist aber keinesfalls für große Communities mit zig parallelen Anwendern, mit persistenten Verbindungen. Nichts anders habe ich behauptet und damit kann man MVC für eine ganze Reihe von Websites komplett vergessen.

Das Problem ist natürlich, das in den heutigen Stellenangeboten der Unternehmen eben vorwiegend Leute gesucht werden, die eben von MVC (ZendFramework, Symfony, CakePHP) Ahnung haben weil die Verantwortlichen der Meinung sind, das wäre State of the Art. Ein junger, blauäugiger Programmierneuling wird das glauben und sich darauf einlassen und bald Albträume bekommen warum die verdammte Seite so lahm ist und irgendwann, wenn der Hype mal vorbei ist und sich der Nebel gelichtet hat sieht man, es war die Schuld des Frameworks. Da werden dann die Chefs und Verantwortlichen nicht begeistert sein und dem Programmierer erstmal die Schuld gegeben obwohl er alles Lehrbuchmäßig umgesetzt hat. Am Ende bekommen dann die Verantwortlichen das ganze verkauft haben und lange Zeit dogmatisch verteidigt haben einen gehörigen Dämpfer (zu Recht). Und genau in dieser Phase wo es langsam kippt sind wir meiner Meinung nach gerade. Ich werde ganz sicher kein Hightraffic Projekt mit irgend einem MVC-Framework programmieren, ganz egal wie schmackhaft es mir auch einer machen will, denn das es kracht ist nur eine Frage der Zeit.

[MrNiceGuy]

Tcha, da kann ich leider noch nicht mitreden, aber mein aktuelles Projekt setzt auf ein Framework. Mal schauen, wie stark dieses dann frequentiert wird und ob die Server-Power für die Last ausreichend ist. Ich denke aber schon, dass auch große Communities über Frameworks realisiert werden können. Wo da allerdings die Flaschenhälse genau liegen... Tcha, das hängt von dem Programmierer ab, der das Framework nutzt - würde ich jedenfalls behaupten.

Vielleicht ist es auch nicht möglich *schulterzuck* aber das wird wohl ebenso eine Behauptung bleiben, die auch das Gegenteil, solange niemand einen Beweis dafür erbringt!? :)

[mepeisen]

Wer MVC auf einen bestimmten Projekttyp festnageln will, der hat das Prinzip nicht verstanden. MVC ist kein Projekttyp oder ähnliches, sondern eine Philosophie, eine Strukturierung des eigenen Codes. Nicht mehr aber auch nicht weniger.

Klar überlädt ein MVC ein einfaches Hello World. Aber du wirst immer Beispiele finden, wo MVC was überlädt oder umbequem macht. Wenn du MVC richtig einsetzt, spielt es die Stärken völlig woanders aus, eben bei komplexeren Anwendungen und vor allem wird vieles wartungsfreundlicher, wenn du klare Strukturen im Code hast.

Und wer von Anfang an an Performance denkt, der disqualifiziert sich von selbst. Denn jedes System kann gute Performance bieten, denn oftmals sind die Performanceprobleme nicht durch Kniffe zu beheben, auf die die zugrundeliegenden Architektur wenig Einfluss nimmt.

Zitat von mepeisen

Wer MVC auf einen bestimmten Projekttyp festnageln will, der hat das Prinzip nicht verstanden. MVC ist kein Projekttyp oder ähnliches, sondern eine Philosophie, eine Strukturierung des eigenen Codes. Nicht mehr aber auch nicht weniger.

Wir reden hier nicht völlig loßgelöst von einem MVC Framework sondern im
Zusammenhang von PHP, denn diese Rubrik heißt ja nicht ohne Grund:
"PHP > PEAR, PECL und Frameworks".

Klar überlädt ein MVC ein einfaches Hello World. Aber du wirst immer Beispiele finden, wo MVC was überlädt oder umbequem macht.

Es geht nicht um Überladen, nocht nicht mal um unübersichtlich sondern
um das Feature Seitenaufbau, Darstellungsgescwindigkeit, Ressourcen
Nutzung des Hostingservers bei massenhaften, konkurierenden Benutzerzugriffen. Sprich: Um eine Top Website die von vielen USer frequentiert wird und genau bei derartigen (großen) Seiten zwingt ein PHP MVC Framework die Gesammtperformance in den Keller was bis zur unbenutzbarkeit führen kann. Was bringt mir da die tollste Codepflegemöglichkeit, die bessere Strukturierung wenn meine Kunden die
Seite nicht mehr vernünftig benutzen können? Ich weiß nicht ob Du mal vor der Herrausforderung gestanden hast eine deratige Seite zu entstören. Ich habe es und es war kein einfacher Job und da musste ich wirklich alle Register ziehen!

Wenn du MVC richtig einsetzt, spielt es die Stärken völlig woanders aus, eben bei komplexeren Anwendungen und vor allem wird vieles wartungsfreundlicher, wenn du klare Strukturen im Code hast.

Möglich, aber nicht bei Webanwendungen mit PHP5! Der HTTP basierte Ansatz
von PHP5 pro Seiten Aufruf die nächste, anstehende Teiloperation durchzuführen sorgt bei einer PHP5-MVC-Implementierung dazu, dass pro Request ca 3 bis 5 andere ausgelöst werden müssen um das View/Controller/Modell Muster zu durchlaufen. Die absolute Hauptanforderung
für eine schnelle Website ist jedoch die Forderung möglichst wenige Requests
durchführen zu müssen. Das wiederspricht sich diametral. Jetzt weißt Du vielleicht auch, warum ich das Projekt eines PHP Bean-Servers, der völlig vom
HTTP-Layer getrennt operieren kann für so wichtig halte (das ist übrigens
das was Java Servlets/JSP schon lange von Haus aus mit Ihren EJB Beans können).

Und wer von Anfang an an Performance denkt, der disqualifiziert sich von selbst.

Nein! Manche Kunden sehen die Seitenperformance als Keyfeature an und werden keinesfalls auch eine noch so hübsche Seite akzeptieren wenn sie lahm ist. Und nichts lässt sich schlechter optimieren, als eine komplexe Anwendungsarchitektur die auf unverrückbaren Säulen aufsetzt, die man
später nicht mehr anfassen darf. Sehr schönes Beispiel sind ORM Mapper,
die waren schon immer mein absoluter Megaalbtraum wenn es um Performance geht, die Softwarearchitekten Flachzangen lieben sie jedoch. Der Kunde hasst es da es zu 100% zu lahmen Seiten füht. Da kann man dann nur noch durch
sehr teure Hardware und andere Tricks optimieren und häufig hilft noch nicht mal mehr das.

Denn jedes System kann gute Performance bieten, denn oftmals sind die Performanceprobleme nicht durch Kniffe zu beheben, auf die die zugrundeliegenden Architektur wenig Einfluss nimmt.

Dem wiederspreche ich grundlegend! 17 Jahre Berufserfahrung haben mir gezeigt da man bei weitem nicht jeder Anwendung noch nachträglich Performance einhauchen kann, manchmal hilft nur noch ein Cut und kompletter Rewrite und dann muss ab der ersten Zeile Performance immer beachtet werden und Zwischenprüfungen laufen die einem Gewissheit geben.

[pago]

Was du wahrscheinlich übersiehst, ist, dass es weniger Geld kostet, 2 oder 3 neue Server auf ein Performance-Problem zu werfen, als eBay in Assembler zu warten.
Ein vernünftig angewendetes MVC hilft dabei, Web-Anwendungen besser zu skalieren (d.h. auf mehreren Servern zu lagern, etc.). Das wird bei stark frequentierten Anwendungen immer nötig sein und bei denen, bei denen das nicht nötig ist, verwendet man halt MVC um die restlichen Vorteile zu nutzen.

Also kurzgefasst: Die Lösungsansätze für Performance-Probleme sind:
- caching
- load balancing (mehrere Server, Datenbankserver, mehr RAM, etc.)
- gezielte Performanceverbesserungen

Und zwar genau in der Reihenfolge. Und MVC hilft dabei, diese Dinge etwas zu vereinfachen.

Zu deinem ständig genannten "PHPBeans": Hast du dir mal Caucho Resin angesehen? Das ist ein Java-AppServer mit einer hoch performanten PHP-Implementierung (in Java). Ich vermute, dass man dort auch PHP-Objekte persistent speichern lassen kann.
Übrigens hilft auch hier MVC dabei, eine Anwendung zu einem solchen "neuen" Modell zu portieren.

---------------------------------
Und jetzt nochmal ein Wort zu deinen Ausfällen: Wir legen hier höchsten Wert auf ein positives Klima. Wie Jann dir bereits gesagt hat, gibt es hier einige Regeln, die auch für dich gelten. Halte dich bitte in Zukunft daran.

Zitat von pago

Was du wahrscheinlich übersiehst, ist, dass es weniger Geld kostet, 2 oder 3 neue Server auf ein Performance-Problem zu werfen,

Wie kommst Du auf die merkwürdige Idee, das mehrere Server irgendeine Performanceverbesserung in Punkto dynamische Seitenauslieferung für den Endkunden bringt? Das ist erstmal nichts weiter als eine Verteilung der Bestandteile deiner Website auf verschiedene Systeme.Dann braucht man einen SW oder Hardwareloadbalancer wie z.B BigIP der dann an die Maschine mit der geringsten Auslastung delegiert.Nur weil aber der Loadblancer da etwas weiterleitet wird der Zielserver nicht auf einmal auf magische Weise schneller. das Problem bleibt einfach bestehen, die Seite bleibt aus der Endkundenperspektive schnarchlahm (und auch wenn Du da 100.000 EUR verballerst ändert sich daran nichts).

als eBay in Assembler zu warten.

Meine Aussage bezüglich Assembler bezog sich darauf, das man auf der Assemblerebene sehr schön sehen kann was man da teilweise an unoptimierten Maschinencode bekommt, wenn der ganze Highlevel Kram mal abgearbeitet ist. Als ich jung war, da haben sich die Authoren von Fachbüchern noch darüber lustig gemacht wie schlecht der Pascal oder gängige C/C++ Compiler teilweise optimiert hat. Wenn ich mir aber anschaue was ein PHP Interpreter da vermurkst...

Ein vernünftig angewendetes MVC hilft dabei, Web-Anwendungen besser zu skalieren (d.h. auf mehreren Servern zu lagern, etc.).

Nein.MVC hat mit Verteilung im Netz nicht das geringste zu tun und das solltest Du eigentlich schon herausgefunden haben wenn Du den Thread aufmerksam gelesen hättest.

Das wird bei stark frequentierten Anwendungen immer nötig sein und bei denen, bei denen das nicht nötig ist, verwendet man halt MVC um die restlichen Vorteile zu nutzen.

Genau. Wenn man eine Firmenwebsite baut die eine Art Visitenkarte ist und nicht zig Leute gleichzeitig HTTP-Zugriffe verursachen ist das kein Problem. Große Seiten mit viel Traffic kannst Du damit nicht realisieren ohne Dir riesige Probleme einzuhandeln. Genau das sagen ja auch die Entwickler von z.B Symfony und anderen Frameworks. "Solche Frameworks nur dort einsetzen
wo Performance keine Rolle spielt".

Also kurzgefasst: Die Lösungsansätze für Performance-Probleme sind:
- caching

Hilft Dir bei dynamisch zu generierenden PHP Content überhaupt nichts. Sogar Sachen wie Memcache laufen da ins Leere, weil es nicht wissen kann was als nächstens aus der DB angefragt wird und welche Parameter bei der Abfrage eine Rolle spielen.

- load balancing (mehrere Server, Datenbankserver, mehr RAM, etc.)

Wirkungslos im kritischen (dynamischen) Bereich, siehe oben.

- gezielte Performanceverbesserungen

Genau! Das ist der Dreh und Angelpunkt. Du kannst aus jeder Kiste eine Menge Leistung rausholen, wenn Du unsinnige Queries und beknackte ORM Strukturen und Datenbank Objektserialisierungen komplett rauswirfst und Dich intensiv mit der Funktionsweise des DB-Servers beschäftigst.
Ich lache immer wenn ich sehe das ein paar Leute meinen bei ein paar Millionen Datensätzchen schon einen Slave aufbauen zu wollen. Wer weiß wie so eine DB-Engine funktioniert und was ein Executionplanner und Prepared Statements sind holt aus einem DB-Server auf einer relativ
sparmsam ausgestatteten Kiste noch so einiges raus, aber von sowas haben die Rotzlümmel
von heute offenbar keine Ahnung. Aber glauben das sie den Durchblick haben, das tun ganz
viele. Du bestimmt auch, gell?

Zu deinem ständig genannten "PHPBeans": Hast du dir mal Caucho Resin angesehen? Das ist ein Java-AppServer mit einer hoch performanten PHP-Implementierung (in Java).

Ich komme aus der Java EJB Enterprise Ecke. Ich kenne AppServer von denen hast Du mit Sicherheit noch nie etwas gehört geschweige denn das Du wüsstest wie man sie richtig buchstabiert, Da brauchst "DU" mir nun wirklich ganz sicher keine Tipps zu geben, jungchen ;D

Ich vermute, dass man dort auch PHP-Objekte persistent speichern lassen kann.

Ok, das reicht! Du bist echt der OberSpezi! Wer hat gesagt das es bei dem PHPBeans Objekt Sever darum gehen soll?? Ich nicht und andere auch nicht. Ein AppServer ist nicht für billige Serialisierungen da. Die Stichworte nach denen Du suchst heißen Marschalling, RMI, JNDI, EJB, CORBA dann weißt Du worum es in dem Projekt geht. Junge, junge...

cu

[Bleistift]

Zitat von marc9022

Wie kommst Du auf die merkwürdige Idee, das mehrere Server irgendeine
Performanceverbesserung in Punkto dynamische Seitenauslieferung für den
Endkunden bringt?

Jeder Server kann eine bestimmte Menge an Requests innert nützlicher Frist verarbeiten. Wenn die Requests zunehemen, sinkt die Performance. Wenn man die Anzahl Requests also auf mehrere Server verteilt, wird die Performance wieder zunehmen... Wenn die Anwendung schon lahm ist, wenn nur wenige User rumklicken, dann ist definitiv etwas falsch gegangen (das hat dann aber nichts mit MVC zu tun...).

Es ist nun mal günstiger, einen oder zwei Server mehr hinzustellen, als Code zu haben, für dessen Wartung man teure Spezialisten braucht...

Zitat von marc9022

Keiner hat was von Assembler gesagt.

Das war natürlich etwas übertrieben... Gut wartbarerer Code ist heute nun mal wichtiger, als gefrickelter Code, der auf einem einzigen Server sehr schnell läuft. Nicht ohne Grund macht man Code-Reviews...

Zitat von marc9022

Ich komme aus der Java EJB Enterprise Ecke, ich kenne sogar aus dem Bereich
AppServer dessen Namen Du noch nicht mal richtig buchstabieren kannst, Da brauchst mir nun wirklich keine Tipps gehen, jungchen ;D

Dein Ton hat sich noch immer nicht gebessert.

Zitat von marc9022

Ok, das reicht! Du bist echt der Spezialist!

Du hältst dich wohl für das schlauste Wesen auf diesem Planeten...

[dr.e.]

Zitat von marc9022

Ich werde deinen Nonsens sicherlich nicht weiter bewerten in dem ich Dir antworte. Mit sachdienlichen Beiträgen befasse ich mich jedoch gerne, nur beschleicht mich langsam das Gefühl das solche Leute hier rar sein dürften.

Sorry, aber das ist schlicht lächerlich. Mich einerseits zu beschimpfen und andererseits auf deine fundierte Argumentation zu verweisen...

[FloB]

Zitat von dr.e.

Mich einerseits zu beschimpfen und andererseits auf deine fundierte Argumentation zu verweisen...

Kann nur zustimmen … fundiert bitte in Anführungszeichen.

Wo sind deine Belege? Du postest hier wild Behauptungen, die niemand so einfach nachprüfen kann … klar, wenn man sich das auf unterer Ebene anschaut usw. ok, aber das hat nicht unbedingt was mit MVC oder anderem zu tun. Und was du alles herbeiführst, das mit diesem EINEN Argument belegt werden soll, halte ich für "etwas" übertrieben.

Man kann im übrigen auch diskutieren, ohne zu polemisieren und persönlich anzugreifen … ich zitiere aus deinem Vorwurf an dr.e:

Zitat von marc9022

dein Beitragt zeigt ja das Du außer Polemik und billigen Denunzierungsversuchen die Ihr Ziel verfehlen nichts gehaltvolles von Dir zu geben hast.

… so hat man einfach keine Lust mitzudiskutieren.

[pago]

*sfz*

Ich frag vielleicht mal gerade heraus: Möchtest du diskutieren oder dein Ego ein bisschen aufpäppeln?

Inhaltlich hat Bleistift dir ja nun bereits erklärt, was ein Load Balancer tut und warum es durchaus sinnvoll ist, Server auf ein Problem zu werfen.

Auch dynamische Inhalte lassen sich übrigens cachen. Das hängt natürlich vom Anwendungsfall ab und manchmal lassen sich auch nur einzelne Teile einer Webseite cachen, aber im Normalfall ist das durchaus möglich. Eventuell magst du dich da ja mal reinlesen in diese Thematik?

Als ich jung war, da haben sich die Authoren von Fachbüchern noch darüber lustig gemacht wie schlecht der Pascal oder gängige C/C++ Compiler teilweise optimiert hat.

Ja. Und inzwischen haben wir mehr als 16MB RAM und auch die Prozessoren sind um ein vielfaches schneller geworden, so dass diese ganzen tollen Diskussionen völlig unwichtig geworden sind (bzw. sich um einige Schichten nach oben verlagert haben).

Du kannst aus jeder Kiste eine Menge Leistung rausholen, wenn Du unsinnige Queries und beknackte ORM Strukturen und Datenbank Objektserialisierungen komplett rauswirfst und Dich intensiv mit der Funktionsweise des DB-Servers beschäftigst.

So schlimm sehen die Queries, die Doctrine und co. generieren, für mich gar nicht aus. Davon unabhängig ist es aber doch gar kein Problem, ineffiziente vom ORM generierte Queries im Model-Layer durch manuelle zu ersetzen, wenn das Problem auftritt. Und stell dir vor: Durch die Verwendung des MVC-Musters und der Verlagerung der Persistenz-Schicht in den Model-Layer, wirkt sich diese Optimierung ganz ohne weitere Code-Änderungen auf die komplette Anwendung aus.

Wer hat gesagt das es bei dem PHPBeans Objekt Sever darum gehen soll?? Ich nicht und andere auch nicht.

Mhm. Okay, dann hab ich deine anderen Äußerungen zu dem Thema wohl falsch interpretiert.

Soo... jetzt zu den persönlichen Angriffen gegen mich.

von sowas haben die Rotzlümmel
von heute offenbar keine Ahnung. Aber glauben das sie den Durchblick haben, das tun ganz
viele. Du bestimmt auch, gell?

Ich hab von einigen Dingen Ahnung, ja. Es kommt ja nicht von ungefähr, dass ich in meinem "jungen" Alter schon an mehreren Büchern mitgewirkt habe (als Ratgeber und auch als Co-Autor), die an meiner Uni als Lehrmaterial verwendet werden.
Aber natürlich habe ich auch Bereiche, in denen ich mich nicht so wirklich gut auskenne. Ich kann z.B. kein Assembler (bzw. nur sehr wenig), weil es mich nie interessiert hat. Als ich mit der Programmierung angefangen habe, war Java bereits schnell genug für die meisten Desktop-Anwendungen und PHP mehr als ausreichend für meine Web-Projekte.
Generell verfolge ich bei Diskussionen den Ansatz, dass ich, falls ich in irgendeinem Punkt eine andere Meinung als mein Gesprächspartner habe, davon ausgehe, dass dieser sich in dem Gebiet besser auskennt. Dann kann ich die Argumentation nochmal in Ruhe analysieren, mir Gedanken dazu machen, meine eigenen Preis geben und hoffen, dass mein Gesprächspartner mir meine Denkfehler aufzeigt - und so letztlich dazu lernen. In deinem Fall habe ich aber leider keine Argumentation finden können (abgesehen vom Argument der Form "Assembler ist schneller" - und "Assembler" dient mir hier nur zur Verdeutlichung der Form deines Arguments. Natürlich sagst du nur, dass PHP ohne MVC schneller ist, als PHP mit MVC, aber C++ ist nunmal auch schneller als PHP ohne MVC und C ist schneller als C++ und Assembler ist nunmal noch schneller als C.).
Daher muss ich erstmal davon ausgehen, dass ich (und die ganzen Leute, die sich mit dem Problem der Skalierung von Webseiten befasst, das Problem bewältigt, und dann darüber geschrieben haben und meiner Argumentation entsprechen) sich in dem Punkt ein bisschen besser auskennen, als du. Ich lasse mich aber gerne eines besseren belehren.

Ich kenne AppServer von denen hast Du mit Sicherheit noch nie etwas gehört geschweige denn das Du wüsstest wie man sie richtig buchstabiert, Da brauchst "DU" mir nun wirklich ganz sicher keine Tipps zu geben, jungchen ;D

Mhm... ehrlich gesagt wage ich das zu bezweifeln. Also alle 3 Aussagen.
Ich hab zwar mit den meisten davon noch nicht gearbeitet, aber kennen tu ich doch so einige.

Da du aber so fit bist, dürfte dir ja bekannt sein, dass du über Resin/Quercus Zugriff auf all die von dir genannten wunderbaren Technologien Zugriff hast. Gratis dazu gibts eine (laut Benchmarks) tolle Performance und was man sonst noch so gebrauchen kann.
Warum das Rad neu erfinden, wenn es schon ein wunderbar rundes gibt?

Mal zum nachdenken:
Wie vermeidest du, ohne separate Model-Schicht, dass dein Code nur schwer zu testen ist? Wie schreibst du Tests dafür? Was machst du, um Code-Duplizierung zu vermeiden? Welchen Ansatz schlägst du stattdessen vor (Page Controller? Eine PHP-Datei inkl. View, wie zu PHP3-Zeiten?)? Wo nimmst du das Geld her, um die deutlich verlängerte Entwicklungszeit deines Projekts zu finanzieren? Wie finanzierst du die Wartung des Projekts?

------------------------------------------
Das Thema, dass du ansprichst, ist im Prinzip ein interessantes, aber die Art, wie du deine Meinung kommunizierst (und bislang ist es nur deine Meinung, die nicht von Argumenten begleitet wird), ist ziemlich nervig.
Mag sein, dass du viel Erfahrung hast, aber deswegen sind andere Leute mit anderen Meinungen noch lange nicht dümmer als du.
Das hast du leider immer noch nicht ganz überwunden, daher nun nochmal eine Aufforderung: Halte dich an die Diskussionsregeln.
Hier gibt es ausschließlich sehr clevere Leute, die mit einander diskutieren möchten - und das in einer freundlichen, aufgeschlossenen und vor allem produktiven Art und Weise.

Deine abwertende Art ist hier nicht erwünscht. Bitte halte dich an die Regeln. Das ist jetzt auch das letzte Mal, dass ich dich darauf Hinweise. Klappt es nicht, werden wir entsprechende Maßnahmen ergreifen müssen.

Ich gehe jetzt mal nicht auf diese ganzen Lebensweisheiten eines jungen Mannes ein, denn dieses belehren wollen führt irgendwie zu nichts, lass uns über die Sache reden, das ist eh interessanter.

Zitat von pago

Auch dynamische Inhalte lassen sich übrigens cachen.

Jetzt wollen wir mal die Kirche in Dorf lassen, von wegen man kann dynamische Elemente cachen.
Schon aus der Definition "dynamisch erstellt" geht hervor das man hier nicht wirklich irgend etwas
adäquat cachen kann. Es gibt zwar Opcodecaches wie APC oder XCache, die haben aber nichts damit zu tun Content zu cachen sondern kompilieren die PHP Seiten vor, so das nicht beständig das ganze Script neu übersetzt werden muss (Java Servlets und JSP machen das schon ewig so) Besonders sinnvoll ist so etwas bei wiederkehrenden Routinen, deswegen nutzen viele Profis das auf ihren Produktionssystemen ja auch und erzielen damit gute Ergebnisse.

Das hängt natürlich vom Anwendungsfall ab und manchmal lassen sich auch nur einzelne Teile einer Webseite cachen, aber im Normalfall ist das durchaus möglich. Eventuell magst du dich da ja mal reinilesen in diese Thematik?

Vielleicht ließt eher Du Dich mal rein, wo man sowas nicht einsetzt oder wo es kontraproduktiv ist. Es macht z.B keinen Sinn (obwohl ich auch schon Leute gesehen haben die das gebracht haben) Daten aus der DB im Frontend (Script) zu cachen und dann von dort die Daten zu bestimmen. Das ist wirklich verrückt, denn einfache DB-Server wie MySQL oder bessere wie Postgres oder hochkomplexe wie ORACLE 11g und IBM/DB2/400 haben ein hervoragendes Data und Query Caching System das man mit solchen Maßnamen eher behindert und ins Stocken bringt als das man nennenswert irgendwo davon profitieren kann. Diese Leute beschäftigen sich bei ein und zweischichtigen Applikationsmodellen (n-Tier auf PHP gibts ja noch nicht) einfach nicht mit dem zum Einsatz kommenden RDBMS und glauben sogar im Gegenteil das Dinge wie ORM toll sind. Nein, sind sie nicht. Diese Sachen kenne ich seit vielen Jahren und was da generiert wird ist einach nur unbrauchbar.Sobald Du die ORM-Statements versuchst zu verändern, kann es sein das der Rest des ORM Mappings nicht mehr passt und man muss dann dort ebenfalls Änderungen durchführen. Die hochkomplexen RDBMS Systeme wie ORACLE und DB2 erwarten eine Menge von den Abfrageanwendern. Alleine die ORACLE OCP Manuals und Best Practices Bücher können eine ganze Ragalwand füllen. Mit simplen, generischen Verständis von ANSI SQL 89/92 ist es da bei weitem nicht getan. Nur mal so zu Info: Wenn Du ORACLE 11g installierst, dauert die Installation ca. 1 Stunde. Da wird praktisch deine ganze Linux oder Unix Distri tangiert, kompiliert, gelinkt und unter hoher CPU Last das System erst mal vorbereitet.Wenn die Idleinstance dann nach der installation erstellt wird, dauert es noch mal ca 10 Min bis 20 Min um die 400 MByte leere Startdatenbank zu erstellen. ORACLE kennt zwar die grundlegenden SQL Befehle, aber eher alibiartig und halbherzig. Wer hier die DB effektiv einsetzen will, muss sich in die Objektorientierte Abfragesprache PL/SQL/SQLPlus einarbeiten und erstmal die ganzen Spezialitäten Step by Step lernen. Wer das nicht macht, den bestraft die DB durch tückisches Verhalten und schlechte Performance.

Und jetzt frage ich Dich: Woher soll ein solcher ORM Mapper das alles wissen? In ORACLE habe ich an die gut 2000 Function Calls im SQL Context die weit über SELECT, DELETE, INSERT, UPDATE hinaus gehen. Und ORACLE ist da keinesfalls alleiniger Exot. Da gibt es TransactSQL beim MS-SQL
Server, IBM/DB2 Queries und unter PostgreSQL pg/plSQL. Und selbst wenn man diese properitären Erweiterungen nicht einsetzt (obwohl es gute Gründe geben kann wie z.B Spatial und Geodatenanalyse oder polymorphes, dynamisches Partitioning wie es z.B Postgres seit einiger Zeit gibt) sind die unterstützten SQL Dialekte alles andere nur nicht einheitlich. Das heisst im Klartext: ORM Mapper können nie 100% korrekt CrossDB funktionieren und die generierten SQL-Queries sind in jedem Fall generisch, suboptimal und lassen sich nicht ohne Anpassungen verwenden.

Wenn das aber so ist, warum den ganzen unnützen Kram lernen? Warum sich damit belasten wenn Du doch weißt das Du überall nachkontrollieren, nachjustieren, verändern und teilweise abschalten musst und das ganze am Ende sogar noch schwerer wartbar ist? Es bringt überhaupt keinen Vorteil im Gegenteil: Wenn man die SQL Statements und das was man an speziellen
Dingen benötig zielsicher selbst schreibt hat man einen schnellen, Fehlerunanfälligeren Arbeitsablauf mit besserer Berechenbarkeit. Ich und meine Kollegen konnten in vielen Fällen Zeit dadurch sparen, das wir nicht auf Dinge wie ORM zurückgegriffen haben. Hier sage ich nur: Theorie (hört sich schön an) und Praxis weichen manchmal extremst voneinander ab. Das wiederum kann nur wissen wer schon lange in diesem Bereich programmiert.

Ja. Und inzwischen haben wir mehr als 16MB RAM und auch die Prozessoren sind um ein vielfaches schneller geworden, so dass diese ganzen tollen Diskussionen völlig unwichtig geworden sind (bzw. sich um einige Schichten nach oben verlagert haben).

Nein, ist es nicht. Weil wenn sowas dazu neigt besonders Resourcenhungrig zu sein und den Speicher vollmüllt, dann entsteht bei vielen Parallelen Prozessen das gleiche, es stackt gewissermaßen und der Verarbeitungsaufwand ist z.B Energielastiger und die Prozesszyklen insgesamt ziehen sich in die Länge. Beispiel: Es dauert länger 32MByte im Speicher zu transformatieren als z.B nur 512 KByte oder 1 MByte. Bei 2.000.000 Transaktionen pro Tag beträgt dann die zeitliche Differenz wohl schon mehrere Stunden und eine derartige Ineffizienz befürworten sicher die wenigsten.

Wer hat gesagt das es bei dem PHPBeans Objekt Sever darum gehen soll?? Ich nicht und andere auch nicht.
Mhm. Okay, dann hab ich deine anderen Äußerungen zu dem Thema wohl falsch interpretiert.

Genau, aber Fehler können passieren und es ist ja gut das Du Ihn eingesehen hast, bin Dir deswegen auch nicht weiter böse, also keine bange

[pago]

Geh doch mal auf diesen Absatz von mir ein:

Wie vermeidest du, ohne separate Model-Schicht, dass dein Code nur schwer zu testen ist? Wie schreibst du Tests dafür? Was machst du, um Code-Duplizierung zu vermeiden? Welchen Ansatz schlägst du stattdessen vor (Page Controller? Eine PHP-Datei inkl. View, wie zu PHP3-Zeiten?)? Wo nimmst du das Geld her, um die deutlich verlängerte Entwicklungszeit deines Projekts zu finanzieren? Wie finanzierst du die Wartung des Projekts?

Das würde mich nämlich wirklich interessieren.

Zum ORM (der übrigens nichts, aber auch gar nichts mit MVC zu tun hat):
Die meisten davon generieren für jedes Datenbank-System unterschiedlich strukturierte Queries. Da ist es dann auch möglich, in einer Query bestimmte Features zu verwenden, die ein anderes System nicht hat.
Beispielsweise werden für die Primary Keys bei MySQL auto_increment verwendet, während bei Oracle eben Sequences und Trigger zum Einsatz kommen. Das geht natürlich beliebig so weiter.
Wie effizient das in der Praxis ist, kann ich dir natürlich trotzdem nicht sagen.
Es bleibt aber dabei, dass ich bei guten ORM in der Lage bin, ineffiziente Abfragen durch optimiertes, natives, SQL zu ersetzen.

Um ein Beispiel mit Doctrine zu geben:
Wenn ich einen bestimmten Nutzer aus der DB lesen möchte, mache ich das wie folgt:

PHP-Code:

$user = Doctrine::getTable('User')->findById(7); 


Die findById-Methode ist dabei eine automatisch generierte. Stelle ich nun fest, dass sie ineffizient ist, implementiere ich innerhalb meiner UserTable-Klasse einfach die Methode:

PHP-Code:

class UserTable ... {
    public function findById($id) {
        // ... Objekt per nativem SQL finden
    }
//...
} 


Und das kann ich machen, ohne den aufrufenden Code überhaupt in irgendeiner Form beachten zu müssen.
Das Beispiel ist natürlich trivial, aber es ging mir ja auch nur darum, zu verdeutlichen, dass es wenig Aufwand bedeutet, an dieser Stelle von ORM-generierten zu nativen Queries zu wechseln. Das funktioniert ja in komplexeren Fällen weitgehend genauso.

Dann zum caching: Alles lässt sich sicher nicht cachen, aber bei den meisten Webseiten ist es nunmal so, dass sie wesentlich häufiger gelesen als geschrieben werden.
Daher wäre es z.B. überhaupt kein Problem, einen Großteil dieses Forums zu cachen (z.B. die Forenübersicht, die Themenübersicht, sogar die Themenansicht).
Bei sehr dynamischen Inhalten kann man vielleicht nur über einen zeitlich stark begrenzten Cache (20 Sekunden oder so) nachdenken - aber selbst der hilft bei tausenden konkurrierenden Anfragen schon sehr.
Opcode-Caches haben mit der ganzen Thematik ja gar nichts zu tun. Das so einer verwendet wird, ist bei Verwendung von PHP ja sowieso Grundvoraussetzung, bevor man über irgendwelche andere Performance-Optimierungen nachdenken sollte.

Nein, ist es nicht. Weil wenn sowas dazu neigt besonders Resourcenhungrig zu sein und den Speicher vollmüllt, dann entsteht bei vielen Parallelen Prozessen das gleiche, es stackt gewissermaßen und der Verarbeitungsaufwand ist z.B Energielastiger und die Prozesszyklen insgesamt ziehen sich in die Länge.

Und trotzdem läuft Beispielsweise Twitter in der wohl langsamsten Programmiersprache der Welt: Ruby. (Ruby-Fans: Nicht böse nehmen, ist natürlich übertrieben ;) )
Okay, die haben jetzt ihre MQ auf Scala umgestellt, aber das läuft ja auf der JVM, die ja nun auch schnell genug für sowas ist.
Es bleibt dabei: Natürlich ist es toll, wenn jeder Layer perfekt optimiert ist, aber es ist einfach nicht mehr so unbedingt notwendig, wie vor 20 Jahren.
Wir sind heute an einem Punkt angekommen, an dem Programmiersprachen bewusst Features enthalten, die die Produktivität der Programmierer erheblich steigern, aber zwangsläufig eine effiziente Implementierung der Programmiersprache verhindern.
Und genauso ist der Stand auch bei der Wahl der Technologien. MVC kostet ein bisschen was, aber das tut OOP an sich ja auch schon. Inzwischen können wir uns das leisten. Hardware ist billig und der Vorteil in Sachen Wartbarkeit, Testbarkeit und Produktivität ist einfach viel wichtiger.