Schnellstes Webframework

[ARadauer]

Mit welchem Webframework bring ich eurer Meinung nach die beste Performance zusammen?
Also kleine Anwendung, wenig und einfache Funktionalität, sehr viele Benutzer. Hauptsächlich Datenbank Operationen. Keine Anbindung irgendwelcher ejb, ws, jms usw...

Plain JSP? Servlets?

 

[nillehammer]

Puuuh, also da stößt Du bestimmt eine Grundsatzdiskussion an :applaus:. Ich würde sagen, nimm das, mit dem Du selbst am schnellsten zum Ziel kommst und einigermaßen sauberen Code produzierst. Da wären plain JSPs sicher nicht die richtige Wahl, eher schon JSF. Mein absoluter Favorit ist Tapestry, obwohl die Lernkurve da recht hoch ist. Wicket soll auch gut sein. Groovy ist auch ganz toll, weil es viele Infrastrukturklassen out of the box für Dein Datenmodell mit liefert (z.B. hast Du automatisch Daos mit Grundfunktionen).

 

[JohannisderKaeufer]

Werden JSP-Seiten nicht in zu einem Servlet kompiliert.

Also beim Deployment bzw. Ersten Aufruf, werden so viel ich weiß aus den JSP's Servlets erstellt.

Danach sollten sich Servlets und JSPs nichts mehr groß schenken.

Dann gibt es noch die Möglichkeit sich den eigenen Server zu bauen und dann auf Socketebene mit den Browsern zu kommunizieren. Die Performancefrage hängt dann aber im wesentlichen von den Programmierkünsten des Implementierers ab.

Wenn man nun etwas über den Tellerrand schauen möchte kann man auf node.js treffen.
Das ist jetzt serverseitiges Javascript.
Ein großer Unterschied zwischen Servlets und node.js liegt darin, das Servlets in Threads pro Request abgearbeitet werden und node.js ein Event und Callback basiertes vorgehen hat.

Java Non-blocking Servers, and What I Expect node.js to do if it is to Become Mature


Dieser Artikel beschäftigt sich mit diesen zwei vorangehensweisen.

 

[Gelöschtes Mitglied 6946]

Meistens ist doch die Datenbank der Flaschenhals. Wenn du nun noch konkret ansprichst, dass die Anwendung eher klein ist und viel auf der Datenbank gemacht wird, dann fällt der Unterschied der Webframeworks vermutlich nicht ins Gewicht. Aber konkret zu deiner Frage: Ich habe keine Ahnung, welches Framework in dem Fall "schneller" wäre. Sorry.

 

[SlaterB]

nur Sockets und HTTP-Strings selber parsen + zusammenstellen?

 

[homer65]

Meistens ist doch die Datenbank der Flaschenhals. Wenn du nun noch konkret ansprichst, dass die Anwendung eher klein ist und viel auf der Datenbank gemacht wird, dann fällt der Unterschied der Webframeworks vermutlich nicht ins Gewicht. Aber konkret zu deiner Frage: Ich habe keine Ahnung, welches Framework in dem Fall "schneller" wäre. Sorry.

Sehe ich auch so.
Der Flaschenhals bei Anwendungen ist meist die Datenbank.

 

[nillehammer]

Wie ich schon geschrieben habe, nimm das, mit dem Du selbst am produktivsten bist. Aber, wenn Dich die Leistungsfähigkeit der Webframeworks unbedingt interessiert, hier ist ein sehr ausführlicher Benchmark: Rails, Wicket, Grails, Play, Tapestry, Lift, JSP, Context JT Dev

 

[ARadauer]

Ok erstmals danke für die Antworten.

nimm das, mit dem Du selbst am schnellsten zum Ziel kommst

mhn ich weiß nicht.... ich will nicht schnell zum ziel kommen. Ich will eine app schreiben die theretisch mit tausenden von Besuchern zurecht kommt.

Meistens ist doch die Datenbank der Flaschenhals.

mhn ja meistens, aber wenn ich nach 30ms mit der DB fertig bin, will ich nicht dass das webframework noch 300 ms verbrät...

Ich denke ich werds jetzt mal mit Tapestry umsetzen. Die Lernkurve stellt kein Problem da, schon ein paar mal benutzt.
Ich sehs dann eh wenns nicht reicht vielleicht mal eine alternative mit jsp.

nur Sockets und HTTP-Strings selber parsen + zusammenstellen?

mhn interessant daran hab ich noch gar nicht gedacht, aber ich denke man solls nicht übertreiben ;-)

Danke

 

[JimPanse]

Hi,

ich finde dieser Artikel:

Web Framework review - evaluation - test

in dem JSF, Stripes und Tapestry gegenübergestellt werden gibt einen guten Überblick.

Greetz

 

[turtle]

Ich will eine app schreiben die theretisch mit tausenden von Besuchern zurecht kommt.

Was hat das denn mit Webframework oder dessen API zu tun?

Du kannst keine Webapplikation schreiben, die auf n Rechnern hundert Besucher bedient und erwarten, dass auf gleicher Hardware nun plötzlich tausend User arbeiten können. Vielfach greifen derartige Applikationen ja auch noch auf eine DB zu. Da kannst Du ja auch nicht erwarten, dass EINE DB-(Instanz) tausende User performant bedienen kann.

Dafür sind Cluster da. Ich würde also an Deiner Stelle hinterfragen, wie die Clusterfähigkeiten eines Webframeworks bestellt ist.

 

[Deros]

naja so wie es sich anhört will er doch eher viel serverperformance, die eigentlich antwortzeit ist dann ja eher nebensächlich. Darum würde ich eher von allem abraten was serverseitig rendert. Spontan würde ich vielleicht sogar zu was richtung gwt/smartgwt greifen. Ist halt eher rechenintensiv auf dem client und der server kann sich so halt nur mit den wirklichen Anfragen beschäftigen.

 

[turtle]

so wie es sich anhört will er doch eher viel serverperformance

Mir ist kein Framework bekannt, dass es Probleme bei moderaten Zugriffen pro User verursacht.

Probleme kommen meiner Erfahrung dadurch zustande, weil VIELE Benutzer arbeiten und/oder weil die DB nicht gut skaliert. Wenn natürlich der Usecase ist, rendere mit 1,000,000 Datensätze dann ist jedes Framework überfordert, weil die Anforderung Unsinn ist.

Meine Aussage zur Clusterfähigkeit ist daher immer noch gültig.

 

[FArt]

Die Frage an sich ist Käse und eine sinnvolle Antwort zu finden ist müßig.

Mit welchem Auto fahrt ihr am schnellsten in den Supermarkt hat da die gleiche Qualität.

"Performance" gibt es an vielen Stellen. Ohne sinnvolle Definition, was hier Performance genau bedeuten soll und Kenntnis der Infrastruktur kann man da keine allgemeinen Aussage treffen.

Ich würde mir darum erst mal keinen Kopf machen. Heutige APIs "perfomen" alle ordentlich. So lange die DB hinterher kommt kann ich viele User bei Bedarf über einfachste Skalierungstechniken realisieren.

 

[ARadauer]

Dafür sind Cluster da. Ich würde also an Deiner Stelle hinterfragen, wie die Clusterfähigkeiten eines Webframeworks bestellt ist.

Das ist ein guter Punkt.
Clusterfähigkeit ist wirklich ein Thema mit dem ich mich eigentlich noch nie näher beschäftigt habe...
Ist das nicht eher eine Frage des darunter liegenden Servers?
Warauf muss ich acht geben, wenn ich meine Web App später in einem Cluster betreiben will? Zb bei amazon ws? Thema sticky sessions... ist doch keine Angelegenheit meiner app oder?

 

[FArt]

Ein richtiger Cluster ist oft überdimensioniert.

Eine gerne genommene Konstellation ist eine Apache Webserver, der auf beliebig viele hinter ihm gelagerte Tomcats verteilt. (= einfache Skalierung)