[MrNiceGuy]

OK, vielleicht bin ich der Einzige, der bei den vielen Abkürzungen und Fachbegriffen jetzt ein bisschen in die Röhre schaut, aber irgendwie finde ich hat das wenig mit dem eigentlichen Thema zu tun.

Behauptung ist, dass MVC aus performancetechnischer Sicht nicht funktionieren soll. Ich frage mich also, warum hier über Java, Assambler oder Datenbanken diskutiert wird!? Dass Datenbanken unterschiedlich schnell arbeiten können und bestimmtes Optimierungspotential bieten (egal, wie lange die Installation dauert - das ist für mich jedenfalls keine Entscheidungsgrundlage "Ich nehme doch lieber Linux, die Installation dauert 30 Min länger, als Windows, also muss es besser sein"!? *rolleyes* ) ist kein Geheimnis und eigentlich ein Thema für sich. Es sollte ja aber eigentlich nicht um die Unterschiede bei den DBMS gehen, sondern um den Geschwindigkeitsnachteil von MVC!

Also: Back2Topic!

Ich kann die ganze Aufregung leider noch nicht so ganz nachvollziehen, da ich erst seit Kurzem mit MVC arbeite, aber das, was ich bereits gemacht habe, zeigt mir eindeutig Potential auch für große Projekte! Ob das nun auch so klappt oder nicht wird sich aber wohl erst dann zeigen *schulterzuck* Je nachdem, wie gut die Geshcwindigkeits-Test funktionieren.

Aber: Noch kurz zur angesprochenen Thematik Caching und Load-Balancing (hat ja auch nichts mit MVC zu tun finde ich!?): Wenn man unter Load-Balancing versteht, dass man einen Server hat, der alle Anfragen entgegen nimmt und dann - ob per Zufall, festgelegter Reihenfolge oder gar per tatsächlicher Auslastung - entscheidet, welcher der Webserver die Anfrage letztendlich bearbeiten soll aber im Hintergrund nur ein DB-Server steht, der zu schwach auf der Brust ist / nicht optimiert ist / was auch immer, dann sollte man sich nicht wundern, dass die Anwendung immernoch langsam ist, selbst wenn man statt zwei 20 Web-Server hinstellt, der Flaschenhals ist hier eindeutig woanders. Das hat dann aber nichts mit MVC zu tun.
Zum Caching: Wer sagt, dynamische Inhalte ließen sich nicht cachen, der hat - was die eigentliche Definition von "dynamisch" angeht - eigentlich recht. Aber: Es gibt bestimmte Inhalte, die sich trotz Dynamik gut cachen lassen. Beispiel: Ein Bekannter von mir betreibt eine Single-Community, bei der es eine Freunde-Liste, eine Besucher-Liste und eine Anzeige gibt, in der steht, wieviele User es gibt, wieviele online sind und wer gerade im Chat ist. Nun würden bei jedem Seitenaufruf alle Informationen aus der Datenbank kommen und einiges an Ressourcen verschlingen, nur um dem User ein paar Informationen zu präsentieren, die sich nicht jede 1/100 Sekunde ändern. In diesem Falle werden die Statistiken nur jede Minute generiert und dann aus dem Cache geladen, statt bei jedem Aufruf die Datenbank zu konnektieren. Ein include() ist da doch deutlich schneller als z.B. mysql_query() ;)

Für mich ergibt sich daraus folgendes: Caching ist - wie bereits beschrieben - möglich, auch für dynamische Inhalte. Es kommt dabei immer auf die Daten selbst an. In einem Chat würde ein Caching zum Beispiel weniger Sinn machen. Ein Blog, der vielleicht nur alle 2 Stunden gefüllt, aber zig tausende Male gelesen wird, wäre mit einem Caching jedoch gut beraten, zumal auch die Interpretation von BBCodes gespart werden kann.

BTW: Ich selber habe in einer Firma gearbeitet, die NICHT nach MVC programmiert hat und der Chef wollte von uns soetwas auch nicht sehen "quick & dirty" war an der Tagesordnung. "Hautsache es läuft". Ende vom Lied: Als ich aus der Firma raus war sollte das CMS von mir nochmal umprogrammiert werden und endete in einer Neuprogrammierung, die den Kunden erneut 10.000 € gekostet haben. Für das Geld kann man aber etliche Server einige Jahre laufen lassen...

--------------------------
Auch wenn du es vielleicht nicht gerne sehen magst, marc, aber das Eine oder Andere bereits gebrachte Argument ist eben doch nicht ganz so haltlos. Man muss alles in eine gewisse Relation setzen und ich für meinen Teil finde, dass MVC dabei hilft, den Kosten/Nutzen-Faktor auf ein gesundes Maß zu reduzieren - sowohl für die Firma, als auch für den Kunden. Allerdings muss das jeder für sich selbst wissen und wenn deine Kunden mit einer "quick & dirty"-Lösung zufrieden sind und deine Kollegen und du gut damit umgehen und daran arbeiten können, dann tut es um Gottes Willen doch bitte! Niemand zwingt euch, MVC zu nutzen oder es gar zu lieben.
Aber verteufeln muss man MVC deswegen noch lange nicht. Und schade ist, dass ein derart gutes Thema durch proletenhafte Auftritte, bei denen in jeder zweiten Zeile ein Schwanzvergleich angestrebt wird verschandelt wird. Das hilft nun wirklich niemandem weiter und zieht die ngestrebte Qualität dieses Forums unfairer Weise nach unten.

Philosophieren kann man über so ziemlich alles, aber man sollte auch immer daran denken: Meinungen sind wie Arschlöcher - jeder hat eins. Und niemand ist ein schlechterer Mensch, nur weil er eine andere Meinung vertritt - vollkommen unabhängig vom Alter oder der Erfahrung.

[QUOTE=MrNiceGuy;69612]OK, vielleicht bin ich der Einzige, der bei den vielen Abkürzungen und Fachbegriffen jetzt ein bisschen in die Röhre schaut, aber irgendwie finde ich hat das wenig mit dem eigentlichen Thema zu tun.

Behauptung ist, dass MVC aus performancetechnischer Sicht nicht funktionieren soll. Ich frage mich also, warum hier über Java,

Weil Java zwar ebenfalls MVC kennt, aber einen viel effizienteren
builtin Mechanismus besitzt um Code/Design/Datenabstraktion (Servlets/JSP)
trennen der um ein vielfaches schneller ist als MVC.

Assambler

Zu Veranschaulichung was nach zig highlevel Operationen am Ende unten
für die Maschine heraus kommt, es ging hier nicht um Assembler Programmierung (lesen hilft).

oder Datenbanken diskutiert wird!?

Weil Datenbanken nun mal zu 99% in jeder HTTP MVC Anwendung eine wichtige Rolle spielen?

Dass Datenbanken unterschiedlich schnell arbeiten können und bestimmtes Optimierungspotential bieten (egal, wie lange die Installation dauert - das ist für mich jedenfalls keine Entscheidungsgrundlage

Wohl war, damit kann man auch DB-Applikationen schreiben. Nur gehe ich
davon aus, das jemand der einen Datenbankgiganten wie ORACLE installiert
hat und sieht wie viele Forks und Subsysteme daran beteiligt sind etwas
bescheidener wird, wenn er als Vergleich nur so etwas billiges wie MySQL
kennt, das jeder 5 jährige installieren und administrieren kann.Ich kenne
genug FreeBSD und Linux Admins die auch meinten von ihrer MySQL Erfarung ausgehend dass das doch nicht so schwer sein könnte - da haben sie sich
dann getäuscht und sie sind voll damit auf ihre vorlaute Schnautze gefallen.
(Stichwort: Theorie und Praxis -> wurde auch schon öfters erwähnt hier).

"Ich nehme doch lieber Linux, die Installation dauert 30 Min länger, als Windows, also muss es besser sein"!? *rolleyes* ) ist kein Geheimnis und eigentlich ein Thema für sich.

Linux ist ein Betriebssystemkern und das ganze hat nun nicht viel mit MVC
zu tun. Aber da Du es schon mal ansprichst: FreeBSD/Solaris anstatt Frickellinux.

Es sollte ja aber eigentlich nicht um die Unterschiede bei den DBMS gehen, sondern um den Geschwindigkeitsnachteil von MVC!

Vielleicht muss man das hier präzesieren: Performancenachteilge von MVC
over HTTP! Deshalb wird hier ja auch MVC nicht für sich sondern im Zusammenhang mit PHP Frameworks diskutiert in einem Thread der genau für ein deratiges Thema vorgesehen ist.

Ich kann die ganze Aufregung leider noch nicht so ganz nachvollziehen, da ich erst seit Kurzem mit MVC arbeite, aber das, was ich bereits gemacht habe, zeigt mir eindeutig Potential auch für große Projekte!

Keine Ahnung wer hier aufgeregt ist, wir diskutieren halt, da gibts schon
mal kontroverse Meinungen, so is dat nun mal.

aber im Hintergrund nur ein DB-Server steht, der zu schwach auf der Brust ist / nicht optimiert ist / was auch immer, dann sollte man sich nicht wundern, dass die Anwendung immernoch langsam ist, selbst wenn man statt zwei 20 Web-Server hinstellt, der Flaschenhals ist hier eindeutig woanders. Das hat dann aber nichts mit MVC zu tun.

In der Theorie ja in der Praxis nein. Du triffst MVC niemals ohne Modellschicht und damit ohne eine SQL-Datenbank an. In WebApplikationen wird eigentlich ausschließlich MVC over HTTP eingesetzt und diese Implementierung macht in der Praxis (gerade beim Zusammenspiel mit dem DB-Server) einen erheblichen
Teil des Problems aus. Wie schon erwähnt, explodieren bei MVC die notwendigen HTTP Requests um Modell, Controller, View + zusätzliche Schritte zu durchlaufen.Also Seite ruft Seite, ruft Seite via Include die irgendetwas tut. HTTP-Performance und damit schnelle Datenübermittlung
zum HTTP-Client basiert aber nun mal darauf HTTP-Requests zu minimieren.
Hier geht Schere nun komplett auseinander und die eine Anforderung lässt
sich nicht mit der anderen arrangieren. Das schlimmste in dem Zusammenhang
ist dann noch, das zwischen den HTTP-Requests auch noch DB Anfragen
abgewickelt werden müssen und wenn die dann dank Serialisierung und
ORM nochmals verlangsamt werden kann es sein, das man schon bei 10
gleichzeitigen Website Usern in ernsthafte Performanceprobleme kommt.
Apache2 bringt auch noch Architektur bezogene Probleme mit, die
das ganze erheblich verschärfen. Aus diesen Grund wurden ja NGIX und
Ligttpd entwickelt um deratige Probleme auf Hightraffic Seiten zu umgehen.

diesem Falle werden die Statistiken nur jede Minute generiert und dann aus dem Cache geladen, statt bei jedem Aufruf die Datenbank zu konnektieren. Ein include() ist da doch deutlich schneller als z.B. mysql_query() ;)

Sowas kann man auch aus Session Variablen oder wie im Fall von Java
aus einer an die Session angeklebten Instanz einer Klasse (SessionBean)
lesen.

[FloB]

Zitat von marc9022

Wie schon erwähnt, explodieren bei MVC die notwendigen HTTP Requests um Modell, Controller, View + zusätzliche Schritte zu durchlaufen.Also Seite ruft Seite, ruft Seite via Include die irgendetwas tut. HTTP-Performance und damit schnelle Datenübermittlung
zum HTTP-Client basiert aber nun mal darauf HTTP-Requests zu minimieren.
Hier geht Schere nun komplett auseinander und die eine Anforderung lässt
sich nicht mit der anderen arrangieren. Das schlimmste in dem Zusammenhang
ist dann noch, das zwischen den HTTP-Requests auch noch DB Anfragen
abgewickelt werden müssen und wenn die dann dank Serialisierung und
ORM nochmals verlangsamt werden kann es sein, das man schon bei 10
gleichzeitigen Website Usern in ernsthafte Performanceprobleme kommt.

Nach meinem Kenntnisstand werden include()'s nicht über einen zusätzlichen HTTP-Request gestartet, sondern sind interne Abläufe. Ich kann über einen Request 10.000 Dateien includen, oder auch gar keine, es bleibt bei dem einen Request. Somit kann ich deine Argumentation nicht verstehen.

[MrNiceGuy]

Erstmal: Zu einer guten Diskussion gehört für mich auch ein gepflegter Umgangston. Da dieser hier in weiten Teilen zu fehlen scheint -> Aufregung. Das aber nur nebenbei.

Ob per include() oder aus der Session... Es ging nur um ein Beispiel. Das viele Wege nach Rom führen ist wohl jedem klar.

Was deine Argumentation bzgl. HTTP-Requests angeht, so kann ich dir allerdings nicht wirklich folgen, denn ob ich nun ein MVC-basiertes Framework oder ein "normales" Script benutze: Für den Fall eines Hello-Worlds oder einer Seite imt z.B. Bloginformationen, komme ich lediglich auf einen Request für genau eine HTML-Datei. Was das System dahinter macht via include() usw. interessiert ja im Grunde nicht, da für z.B. ein include() kein HTTP-Request ausgeführt wird!?

[edit]FloB war ein bisschen schneller ^^ ;)[/edit]

Vielleicht ist PHP noch nicht bereit für MVC basierte Entwicklung und dementsprechend ein bisschen langsamer, allerdings sind das bislang - im Übrigen "immer noch" - lediglich Vermutungen. Nur weil du sagst, dass du die Erfahrung mit einem oder vielleicht auch zwei Frameworks gemacht hast, heißt das ja aber noch lange nicht, dass das allgemeingültig ist und beweist hier schonmal garnichts. Wenn du meinst, dass dem so ist, ist deine Aussage genauso richtig oder falsch, wie meine, wenn ich behaupte, dass es eben genau andersrum ist.

[pago]

Weil Datenbanken nun mal zu 99% in jeder HTTP MVC Anwendung eine wichtige Rolle spielen?

Das ist doch für 99% der Web-Anwendungen insgesamt auch wahr, oder? MVC oder nicht MVC, das hat doch nichts damit zu tun, dass eine Web-Anwendung irgendwann mal Daten aus einer Datenbank lesen oder schreiben muss.

MVC ist ein Design-Muster, bei dem es darum geht, seine Anwendung in mehrere Schichten aufzuteilen. Die Implementierung des Controller-Layers mag bei Symfony und auch beim Zend Framework nicht besonders effizient sein (das dispatching ist da sicher recht aufwendig - dafür aber extrem flexibel), aber es hindert ja niemand den anderen daran, stattdessen einen eigenen FrontController zu schreiben, der wesentlich einfacher (und effizienter) aufgebaut ist.
Für die views wird einfach eine PHP-Datei eingebunden, das dürfte eigentlich effizient genug sein.
Und den Model-Layer unabhängig von diesen Dingen zu halten ist ohnehin eine gute Idee, schon allein um die Testbarkeit des Codes zu verbessern.

Der tatsächlich dem MVC geschuldete Overhead ist absolut minimal (in Proportion zu den tatsächlichen Bottlenecks einer Anwendung - DB-Zugriff, etc.). Wie das nun die einzelnen Frameworks umsetzen, das ist eine andere Frage.
Symfony und ZF (falls nicht als einfache Klassenbibliothek verwendet) sind Frameworks, die sich primär um den VC-Part kümmern und dort durch Callbacks, Events, Plugins, ViewHelpers, usw. sehr viele Möglichkeiten eröffnen, dabei aber natürlich auf die Geschwindigkeit gehen.
Hier muss man abwägen, ob die Geschwindigkeitsnachteile die Vorteile bei der Entwicklung (Time to Market, Zeit der Entwickler, etc.) überwiegen und dann eventuell eine andere Implementierung wählen (die weniger flexibel, dafür aber schneller ist).
Beispielsweise soll Yii sehr schnell sein und zumindest in seinen eigenen Benchmarks landet Christians APF auch immer sehr weit vorne.

Lutz hat aber vollkommen recht, wenn er sagt, dass Themen wie Datenbanken, ORM, Caching usw. hier nichts verloren haben. Ich hab mich da ein wenig zu sehr auf diese hier nicht hingehörende Diskussion eingelassen, weil ich dachte, darüber kommunizieren zu können, dass es wesentlich einfachere Möglichkeiten gibt, eine Web-Anwendung performanter zu machen, als ein paar Methodenaufrufe und Objektinstanziierungen zu vermeiden.

Du triffst MVC niemals ohne Modellschicht und damit ohne eine SQL-Datenbank an.

Das ist genau genommen Quark. MVC ohne Modellschicht ist kein MVC, insofern ok, aber wozu braucht man beim MVC eine SQL-Datenbank?
Auch ein Model, dass einen RSS-Feed modelliert, ist ein Model. Die Datenbank ist lediglich die üblichste Datenquelle für Web-Anwendungen (egal ob PHP oder Java oder .NET).

Zum Thema HTTP-Requests wurde dir ja nun schon was gesagt.

Sowas kann man auch aus Session Variablen oder wie im Fall von Java
aus einer an die Session angeklebten Instanz einer Klasse (SessionBean)
lesen.

Jetzt weiß ich wieder, wie ich darauf kam, dass es dir nur um nen billigen Objekt-Store geht, wenn du über AppServer redest...

Zitat von pago

Zum Thema HTTP-Requests wurde dir ja nun schon was gesagt.

Ja und "was" da gesagt wurde ist bullshit und bedarf keiner
weiteren Erwähnung.

Jetzt weiß ich wieder, wie ich darauf kam, dass es dir nur um nen billigen Objekt-Store geht, wenn du über AppServer redest...

[ ] Du hast verstanden was EJB's, RMI, JDNI, CORBA machen und was
Marschalling bedeutet.

[pago]

Okay... also, um das festzuhalten:
Du glaubst, dass die PHP Direktive "include" eine PHP-Datei mithilfe eines HTTP-Requests einbindet?
Wie genau macht die das denn dann auf meinem lokalen Computer, wenn ich keinen Apache laufen habe, der diese HTTP-Anfrage verwerten kann, sondern mein Skript in der Kommandozeile ausführe?

Junge, ganz ehrlich? Du hast keine Ahnung von den Dingen, von denen du da redest. Deine ganze "Argumentationsstruktur" ist darauf ausgelegt, zu provozieren. Du ignorierst beharrlich jedes Argument, dass deine Position zwangsläufig schwächt oder du beleidigst diejenigen, die dir was erklären wollen.
Du hast jetzt noch eine Möglichkeit, deinen Stand mithilfe von Argumenten darzustellen, andernfalls ist der Thread hier dicht.

[mepeisen]

Zitat von marc9022

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).

Das liegt aber grundsätzlich nicht an einem MVC-Schema. Das eine hat mitdem anderen zwar zu tun und es ist auch richtig, dass potentiell die Performance in den Keller geht. Aber das liegt auch an anderen Einflussfaktoren, die mit MVC rein gar nichts zu tun haben.

Zitat von marc9022

Nein!

Ich meinte das nicht so, dass man performance aus den Augen lassen sollte. Vielmehr meinte ich das so, dass du nie genau weißt, wie die Performance aussieht vor dem Schreiben der ersten Codezeile. Gute Grundlagen zu legen ist zwar wichtig aber immer wieder wird dich irgendwann die Realität einholen und trotz der guten Grundlagen wird die Performance miserabel sein. Und das ist der spannende Punkt, denn die Wartung und das Refactoring, sowas geht extrem ins Geld. Und auch hier gibt es wieder viele Einflussfaktoren, die mit MVC wenig zu tun haben.

Zitat von marc9022

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.

Das ist ja alles richtig. Aber ich muss dir auch ob meiner mehr als 10 Jahre Erfahrung grundlegend widersprechen. Für die Performance sind mehrere Faktoren wichtig:
a) Antwortzeit
b) Ressourcenverbrauch
c) Skalierbarkeit
d) Preis-/Leistungsverhältnis
Je nach Anwendung und Projekt gibt es unterschiedliche Schwellwerte. Bei einem Projekt ist der Seitenaufbau innerhalb einer Sekunde akzeptabel, bei einem anderen Projekt innerhalb von 5 Sekunden. Nehmen wir mal an, dass man die absoluten Schwellwerte nie überschreitet, das geht auch mit MVC, wenn man sich an entsprechende Einfachheit hält.
Den Projekten gemeinsam ist dann aber nur noch folgender Umstand: Bei gutem Preis-/Leistungsverhältnis (was auch immer das für das Projekt bedeutet) muss das System gut skalierbar sein. Eine gute Skalierbarkeit wird immer dann erreicht, wenn man proprtional skaliert. Vereinfacht ausgedrückt: Doppelte Userzahl bedeutet doppelte Last. Das ist zunächst einmal der Idealzustand. Denn dann ist es eine Frage der zur Verfügung stehenden Hardware und ob absolut gesehen das preis-/Leistungsverhältnis OK ist. Daran kann man durch Performance-Maßnahmen drehen, auch mit einem MVC-Modell. Es gibt wie gesagt genug Einflussfaktoren (DB-Indices, unperformante Queries, zu viel Daten in der Session, die man für einen Request gar nicht braucht, zu lange Initialisierungsphase etc. pp.)
Die wirklich schlechte performance wird sich immer dann auswirken, wenn das System nicht mehr proportional skaliert. Und jedes System wird irgendwann einen Schwellwert erreichen, wo es nicht mehr proportional skaliert. Was nützt dir beispielsweise der tollste schnellste Prozessor, wenn er irgendwann ob der Speicherauslastung Däumchen dreht, weil das Betriebssystem Festplattenorgien veranstaltet? So gibt es viele Punkte, an denen ein System plötzlich völlig in den Keller gezogen wird, weil es nicht mehr proportional skaliert, sondern sich mit ein paar neuen Besuchern plötzlich für alle eine drastische Verschlechterung einstellt.
Und genau das ist der Punkt, der wichtig ist. Und ich gebe dir Recht, marc. Mehr als einen Server auszustellen ist dann nicht immer des Rätsels Lösung auch wenn man hier mit einem kleinen Cluster immer recht schnell Abhilfe schaffen kann bei PHP-Seiten. Das liegt vor allem auch in der Tatsache begründet, dass PHP-Webseiten eben keinerlei Synchronisierung brauchen. Solange also beispielsweise ein dicker Datenbankserver die Masse an Queries noch schnell verarbeiten kann, kannst du hundert Webserver in ein Cluster schalten und kriegst damit zeitgleich bei einer hoffentlich optimierten Webseite auch problemlos zehntausende User befriedigt. Auch vorausgesetzt, man muss nicht bei einem Request immer Megabytes an Daten zwischen Datenbank und Webserver hin- und herwälzen. Im übrigen ist es nie die absolute Userzahl die wichtig ist, sondern eher die Zahl der parallel anfragenden User. Aber ich denke das versteht sich von selbst ;)

Eines darf man auch nicht vergessen: Wer mit einem Standard-PHP hochfrequentierte Seiten betreiben will, ist selbst Schuld. Extensions wie spezialisierte Caches, um beispielsweise Scripte nicht ständig neu zu parsen, sondern bereits vorcompiliert drauf zuzugreifen, sind bei sowas auch wichtig, um die absolute Performance pro Request deutlich zu steigern. Dazu kommen weitere, wie beispielsweise memcache.

So, ich habe mir jetzt nicht alles durchgelesen, auch wenn ich die Diskussion als solches interessant finde. Aber ich hoffe mal, ich konnte mit einigen Vorurteilen bzgl. Performance aufräumen. Und auch mit einigen Vorurteilen bzgl. PHP. Mich interessiert es auch nicht, wer hier wieviel Jahre Berufserfahrung aufzuwarten hat. Ich habe mich gut genug auf Performance-Tunings, insbesondere von Webprojekten (nicht nur PHP!) spezialisiert.
Ich bin Mitglied in einem Projekt, bei dem über 100.000 Arbeitsplätze auf einen Serververbund zugreifen und wo über 100 Mio Requests pro Tag performant abgearbeitet werden müssen. Und das in einem insgesamt sehr kritischen Bankenumfeld. Ich möchte mal mit recht behaupten, dass ich mich mit richtig großen Dimensionen soweit als möglich auskenne. Wer irgendwie der Meinung ist, nur anhand einer Systemarchitektur sofort auf die Performance zu schließen, der ist in meinen Augen völlig ahnungslos. Ich habe oft genug erlebt, dass genau jene dann sehr verwundert die Augen reiben, wo man dann plötzlich Performance rausholt und an welchen Ecken man was verändert um plötzlich das System um 95% schneller zu bekommen.

Zitat von pago

(blödsinniges Gequatsche gelöscht)
...
wenn ich keinen Apache laufen habe, der diese HTTP-Anfrage verwerten kann, sondern mein Skript in der Kommandozeile ausführe?

[ironie]
Hmm, nutzt Du da denn auch ein mod_php oder einen Interpreter? (Achtung: Ironietags)
[/ironie]

Auch merkwürdig das manche Leute entfernte include() Statements cross
Domain setzen und die sogar funktionieren (dürften die ja gar nicht, deiner
Meinung nach).

Junge, ganz ehrlich? Du hast keine Ahnung von den Dingen

Tip:
Glashaus und Steine und so.

Tip2: Hausaufgaben:
JNDI, RMI, EJB, CORBA damit Du nicht immer so einen Unsinn verbreitest und auch mal bei den Erwachsenen mitreden kannst.

Ich meinte das nicht so, dass man performance aus den Augen lassen sollte. Vielmehr meinte ich das so, dass du nie genau weißt, wie die Performance aussieht vor dem Schreiben der ersten Codezeile. Gute Grundlagen zu legen ist zwar wichtig aber immer wieder wird dich irgendwann die Realität einholen und trotz der guten Grundlagen wird die Performance miserabel sein. Und das ist der spannende Punkt, denn die Wartung und das Refactoring, sowas geht extrem ins Geld. Und auch hier gibt es wieder viele Einflussfaktoren, die mit MVC wenig zu tun haben.

Jo, das stimmt. Die bessere Wartbarkeit und Refactoring hilft schon ungemein,
daher setze ich seit PHP5 auch eher z.B ZendStudio und Eclipse PDT ein,
da einfache Editoren da nicht so effizient sind. Wichtig ist und bleibt wohl
nur die Aussage, das man die Performance in der Tolleranz hält, wenn das
geling ok, wenn aber nicht, dann muss man an dem Punkt wo man ist so
lange stoppen bis eine Lösung möglich ist.

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.

Aber ich muss dir auch ob meiner mehr als 10 Jahre Erfahrung grundlegend widersprechen. Für die Performance sind mehrere Faktoren wichtig:
a) Antwortzeit
b) Ressourcenverbrauch
c) Skalierbarkeit
d) Preis-/Leistungsverhältnis

Naja, manche Singlestage Anwendungen müssen nur auf einem einzigen
Rechner gut skalieren und Preisleistung ist nur dann relevant, wenn es
sich um einen externen Kundenauftrag handelt. Wenn Du intern an
Mission critical Sachen rumschraubst ist es für gewöhnlich egal was es kostet
und wie lange es dauert, weil es erledigt werden muss.

Die wirklich schlechte performance wird sich immer dann auswirken, wenn das System nicht mehr proportional skaliert. Und jedes System wird irgendwann einen Schwellwert erreichen, wo es nicht mehr proportional skaliert.

Das ist richtig und besonders schwer in Netzwerken wo die Resourcen verteilt
gelagert sind. Das sieht man z.B an Blizzards WOW-Servern. Die verkraften
max 20.000 konkurierende, statefull TCP Socket Connects, das ist natürlich
ein ätzendes Design und die Leute oberhalb des Wertes landen in Warteschlangen oder die gesammt Serverperformance sackt ab und es kommt
zu Laggs.

Ich kann Dir im großen und ganzen auf jeden Fall recht geben.

[pago]

Ja, man kann mit include auch Dateien auf anderen Servern einbinden, ja, dann benötigt man mehrere HTTP-Requests (oder FTP oder was auch immer). Aber: Dieses Feature kann deaktiviert werden (siehe Doku) und wird nur dann benutzt, wenn es sich beim Parameter um eine URL handelt, statt um einen lokalen Pfad. Lies die Doku...

Auf den Rest gehe ich mal per PN ein...

[Jann Hendrik]

@marc9022: Die kommenden 2 Wochen darfst du gerne damit verbringen die Forenregeln dieses Forums zu studieren. In dieser Zeit ist für dich erstmal Funkstille angesagt.
Sollte sich danach keine Besserung in deinem Tonfall einstellen, dann wird die Sperre auf 'dauerhaft' verlängert.
Bis dahin haben wir Zeit in Ruhe und dem sonst hier freundlichem Ton an dem Thema weiter zu diskutieren, sofern daran Interesse besteht.

Du wurdest mehrfach auf die Forenregeln hingewiesen, aber nun ist meine Geduld am Ende!
developers-guide ist ein Angebot, welches von usern genutzt werden darf, die das kleine 1x1 der Benimmregeln schon gelernt haben. Leider hast du mit deinen Beleidigungen immer wieder dafür gesorgt, dass wir nicht den Eindruck gewinnen konnten, dass du schon dazu gehörst.

In 2 Wochen geht es für dich weiter - und dann hat sich dein Tonfall verbessert - oder wir haben dauerhaft Ruhe vor deinen Beleidigungen, die hier keiner hören will!

[xardias]

Ähm. Ich habe die ganze Diskussion nicht komplett gelesen.

Meines Wissens nach ist MVC doch nichts weiter als ein, äußerst abstraktes, Entwicklungspattern und damit doch erstmal recht wenig mit der Performance zu tun.

Und wenn mich nicht alles täuscht arbeiten die als "bessere Alternative" genannten Java Server Anwendungen doch ebenso über das MVC Pattern (Beans->Model, JSP->View, Servlet->Controller). Ich würde sogar fast sagen, dass MVC eine der verbreitetsten Pattern überhaupt ist, nicht nur im Web Bereich.

Also verstehe ich den Gegenstand der Diskussion nicht wirklich, werden hier nicht Äpfel mit Pferdeäpfeln verglichen?
Das ganze erinnert mich ein wenig an die "Diskussion" über OOP vor einiger Zeit. Die ist im selben Stil abgelaufen.

[pago]

Japp. Genau so ist es - hatte ich aber irgendwo auf dieser Seite des Threads auch mal erwähnt.
Hätte man sich die Diskussion also sparen können? Joa... zumindest in der Art, wie sie gelaufen ist, mit Sicherheit.

[mepeisen]

Die Diskussion geht teilweise in eine andere Richtung. So wie PHP derzeit normalerweise aufgestellt ist, musst du dir bei jedem einzelnen Request erst die Daten und Objekte neu zusammensuchen.
Und genau das macht einen gewaltigen Unterschied zu der Java-Welt aus, wo du die JSP Pages zum Beispiel vorkompiliert hast, wo du also gewissermaßen einen echten Anwendungscontainer da hast, der "immer" läuft.

Und die Behauptung war, dass genau deswegen MVC nix taugt, weils von vornherein in der PHP-Welt nicht ausbrechen kann und du damit immer Kompromisse eingehen musst, die zu Lasten der Performance gehen.

Das Problem ist hier, dass zunächst einmal ein Haufen Mißverständnisse existieren, was "Performance" wirklich bedeutet. Und es besteht die Annahme, man könne Performance irgendwie absolut in Zahlen ausdrücken. Das kann man nach meiner Erfahrung eigentlich nie. Selbst das Gefühl, ob eine Webseite langsam oder schnell ist, ist ein subjektives Empfinden. Die Frage, ob sie kostengünstig ist, setzt sich aus derart vielen Faktoren zusammen, dass du nur schwer vergleichen kannst.

Das zweite Problem ist, dass man Entwurfsmuster auf Systemarchitektur eins zu eins umsetzt und dass man da dann eins zu eins Performance ablesen will. Das funktioniert in der Praxis grundsätzlich nie. Und alleine deswegen, weil das in der Praxis nie funktioniert, wird jeder eine andere Meinung vertreten, je nachdem was er für Erfahrung gemacht hat. Und erst wenn man genug Erfahrung gesammelt hat, wird man aber von selbst lernen, dass Performance ein hochkomplexes Thema ist. Und das liegt in den seltensten Fällen am Code selbst. jeder, der über Performance diskutieren will, sollte nie den Fehler machen und sich zu irgendeiner qualitativen Aussage hinreißen lassen.

Ich kann nicht anders als einige hier müde zu belächeln. Das hat nichts damit zu tun, dass ich hier irgendwem die Kompetenz abspreche oder so. Es ist nur so, dass ich mal genauso naiv war wie ihr beim Thema Performance. Und glaubt mir wirklich: Ich habe nicht umsonst darauf hingewiesen, dass Performance von so viel Faktoren abhängt, dass man kaum Chancen hat, irgendeine qualitative Aussage zu tätigen. Und jede Software, jedes Projekt, jede Hardware, jedes Betriebssystem, ja sogar teilweise die RZs selbst, verhält sich immer wieder etwas anders. Bei Performance diskutiert sich immer am besten an konkreten Messwerten zu einem konkreten Projekt auf einer konkreten Hardware und zu konkreten Userzahlen/Besucherzahlen.

Alles andere ist genauso als würde man diskutieren, ob Äpfel besser schmecken als Birnen. Der hat gelernt, dass ihm Äpfel besser schmecken, der andere hat gelernt, dass Birnen besser schmecken. Der Dritte wird nur Birnen kennen und sagen "Die schmecken mir so gut, da können die Äpfel nur schlechter sein." Genau das ist mit dieser Diskussion passiert...

[xardias]

Zitat von mepeisen

Die Diskussion geht teilweise in eine andere Richtung. So wie PHP derzeit normalerweise aufgestellt ist, musst du dir bei jedem einzelnen Request erst die Daten und Objekte neu zusammensuchen.
Und genau das macht einen gewaltigen Unterschied zu der Java-Welt aus, wo du die JSP Pages zum Beispiel vorkompiliert hast, wo du also gewissermaßen einen echten Anwendungscontainer da hast, der "immer" läuft.

Das ist auch ein Grund warum ich Webanwendungen lieber in Appservern entwickle (Mir liegt PHP als Sprache aber auch allgemein nicht so). Ich habe keine Erfahrung damit ob es wirklich performanter ist, aber es fühlt sich für mich vom Entwicklungsstil her einfach besser an. Gerade wenn es in Richtung Browsergames o.Ä. geht wo viele Berechnungen unabhängig von den Anforderungen bearbeitet werden.

[pago]

Okay. Also halten wir fest: Die Diskussion über MVC ist keine über MVC, sondern über das Execution Model von PHP (nämlich shared nothing) und die daraus (möglicherweise) entstehenden Probleme bei Verwendung von Mustern wie z.B. MVC.

Und das ist doch wieder eine völlig andere Diskussion.
Da ist dann für mich die Frage, welche Art von Objekten man denn nun eigentlich im AppServer am leben halten würde, um die entsprechende Objekt-Hierarchie nicht jedesmal neu aufbauen zu müssen. Also an welcher Stelle würde man diese Fähigkeit verwenden? Mag mir da jemand ein Beispiel geben?

Ich hab leider mit dem Java-Ansatz kaum Erfahrungen gemacht. Das eine Mal, wo das der Fall war (winziges JSF/JPA/EJB3-Projekt), habe ich kaum einen nutzen dafür gefunden. Allerdings hab ich auch nur den JSF-Layer gebastelt (das Wort triffts recht gut) und hab die Business-Logik-Schicht nur verwendet. Insofern weiß ich nicht, ob da irgendwas davon gebrauch gemacht hat.

Jedenfalls würd ich mich über ein (oder gern auch zwei ;) ) Beispiel(e) freuen.
Rein vom Gefühl her kann ich mir vorstellen, dass es vorallem dann nützlich ist, wenn die Hierarchien auf etwas komplexere Art und Weise zusammengestellt werden (bspw. über einen DI Container) und dabei für jeden Aufruf gleich bleiben.

Ansonsten dürften doch "die paar Objekte" nicht so schwer wiegen, oder?

[mepeisen]

Nehmen wir mal einen einfachen Shop. Da gibt es eine Vielzahl an Objekten, die man verwalten kann und muss. Im einfachsten Fall ein paar Kategorien, Artikeldaten, Warenkörbe. Das übliche halt.
Im Normalfall würdest du in PHP so vorgehen, dass du die Daten bei einem reinkommenden Request jeweils aus der Datenbank ausliest und dann verarbeitest. Soweit klar.

Jetzt folgende Anforderung, die ich mir ausgedacht habe:

1) Anhand der betrachteten Artikel soll es möglich sein, Produktempfehlungen herauszuarbeiten. Diese Empfehlungen werden als Links angeboten. Dabei soll berücksichtigt werden, dass man Alternativen angeboten bekommt, wenn besonders viele die gleichen Artikel in ihren Warenkörben haben aber noch keine Bestellung abgeschickt haben.

2) In einem Live-Support-System soll einem Admin die Möglichkeit gegeben werden, die Warenkörbe zu betrachten. Er soll die Möglichkeit haben, einen User auf Anfrage zu beraten, um ihm so auch Artikel zu empfehlen. Vielleicht eine Hardware-Beratung?

3) Es gibt - wenn wir mal bei der Hardware bleiben - auch Sonderangebote und Komplettsysteme. Diese setzen sich aus anderen Einzelartikeln zusammen.

4) Dann soll natürlich, wenn ein User längere Zeit inaktiv ist, der Warenkorb gelöscht werden.

5) Zu allem Überfluss gibt es eine Lagerverwaltung, die in der Lage sein soll, über externe Software höher priorisierte Einkäufe aus einem Abholshop zu berücksichtigen.

6) Um zukunftssicher zu sein, sollen im Bundesgebiet mehrere Filialen verfügbar sein, alle mit eigener Lagerverwaltung. Je nach Wunsch des Käufers kann er bevorzugt alternative Artikel kaufen, wenn sie in einem Shop, der in der Nachbarstadt beheimatet sind, aktuell vorrätig sind.

So. Klingt kompliziert. Vor allem das Datenmodell wird ziemlich kompliziert, um all die kleinen Bedürfnisse zusammenzubringen. Viele Bedürfnisse, um im Grunde nur eines zu tun: Im richtigen Moment Alternativen anzubieten.
Und nun könntest du das alles natürlich in komplizierte Webscripte verbauen, die immer wieder nur eines tun: Bei jedem Request aufs neue komplizierte Regeln durchlaufen um zu schauen, ob der Warenkorb noch aktuell ist oder überholt wird.

Deutlich schöner (und auch performanter) wäre es, die Webseite nur das tun zu lassen, was sie soll: Sie bietet Alternativen an. Wo diese Alternativen herkommen und was das System im Hintergrund tut, ob die gleichen Requests damit zu tun haben oder ob ein ganz anderer Request bewirkt, dass die Alternativen sich ändern, sollte die Webseite nicht interessieren.

Langer Rede, kurzer Sinn. Wenn man Web-Anwendungen erst einmal soweit hat, dass man die Präsentation (also die Websseite) von Teilen der Business Logic (also jenem Teil, was das Lager verwaltet, Alternativen vorbereitet) trennt, dann läuft man irgendwann mal auf ein Problem mit PHP. Lösen kann man sowas natürlich schon, was aber zumeist in sehr komplexen Datenstrukturen und Cronjob-Exzessen resultiert. Wirklich schön und wartbar siehts am Ende meist nie aus.

Wenn man nun wieder auf einen Application Container schaut, ist es dort problemlos möglich, beispielsweise durch Objekt Sharing entsprechend auch auf fremde Warenkörbe zuzugreifen, dort Hinweise zu platzieren, dass gerade im Shop etwas gekauft wurde und daher vielleicht ein alternativer Artikel mehr Sinn macht oder von einem Admin-Request aus in einen Warenkorb zu schauen. Und das alles so, dass die eigentliche Webseite, die der User sieht bzw. der Code, gar nichts erst davon mitbekommt.

Ist das besser? schlechter? Schwierig zu beantworten. Im Normalfall ist es einfach nur anders. Und es gibt sicher genug deutlich komplexere Anwendungen und Strukturen, wo es einfach mehr Sinn macht, sie einmal zentral vorliegen zu haben statt ständig neu zu berechnen.

Ein wichtiger Versuch von mir, eine normale PHP-Webseite zu tunen, ist ein ausgeklügeltes Caching-System. Jedes moderne Framework unterstützt das mittlerweile. Interessant ist aber vielmehr die Frage, was eine Aktualisierung des Caches auslöst. Ein einem OOP-Framework müssten das Objekte sein......

[pago]

Okay, macht Sinn. Für mich stellt sich dann aber immer noch die Frage: Warum nicht auf Resin als AppServer setzen? Ich hab mir die Doku jetzt nicht allzu genau angesehen, aber ich gehe doch recht stark davon aus, dass es darüber Möglichkeiten gibt, seine Objekte dort abzulegen. Dann hätte man doch prinzipiell das "beste" aus beiden Welten. Hast du dir das mal angesehen?

[Jojo]

Zitat von mepeisen

Wenn man nun wieder auf einen Application Container schaut, ist es dort problemlos möglich, beispielsweise durch Objekt Sharing entsprechend auch auf fremde Warenkörbe zuzugreifen, dort Hinweise zu platzieren, dass gerade im Shop etwas gekauft wurde und daher vielleicht ein alternativer Artikel mehr Sinn macht oder von einem Admin-Request aus in einen Warenkorb zu schauen. Und das alles so, dass die eigentliche Webseite, die der User sieht bzw. der Code, gar nichts erst davon mitbekommt.

Klingt für mich irgendwie nach einer Art Daemon, oder wie darf man sich das vorstellen?
Den Daemon könnte man auch mit PHP machen.... Wobei natürlich die Wartbarkeit darunter leiden würde...
Der AppServer wird wohl die persistenten Objekte auch nur alle paar Millisekunden refreshen, oder irre ich mich?

Sorry, ich bin neu auf dem Gebiet WebApps mit Java.