it-swarm.dev

Ist JSF wirklich bereit, leistungsstarke Webanwendungen bereitzustellen?

Ich habe viel Gutes über JSF gehört, aber meines Wissens hatten die Leute in der Vergangenheit auch viele ernsthafte Beschwerden über diese Technologie, ohne zu wissen, wie sehr sich die Situation verbessert hat. Wir betrachten JSF als wahrscheinliche Technologie für ein soziales Netzwerkprojekt. Wir sind uns jedoch weder der Leistungsbewertung von JSF bewusst, noch konnten wir wirklich auf eine vorhandene Hochleistungswebsite stoßen, die JSF verwendet hat. Die Leute beschweren sich über Probleme mit der Skalierbarkeit der Leistung.

Wir sind uns immer noch nicht sicher, ob wir mit jsf das Richtige tun, und möchten daher von Ihnen alles darüber hören und Ihre Eingaben berücksichtigen.

Ist es möglich, JSF so zu konfigurieren, dass es die hohen Leistungsanforderungen von Diensten für soziale Netzwerke erfüllt? Auch inwieweit ist es möglich, mit den aktuellen Problemen in JSF zu überleben. Was genau sind ihre Probleme?


Ich bin nicht besorgt über die Entwicklungskomplexität mit JSF, über die sich andere normalerweise beschweren, weil ich nach meiner persönlichen Erfahrung glaube, dass dies überhaupt nicht stimmt, aber ich bin mehr besorgt darüber, welche Leistungs- und Skalierbarkeitsprobleme auftreten. Und bitte missbrauchen Sie es nicht nur bei seinen alten Problemen, die mit früheren Versionen verknüpft sind. Ich kümmere mich nur um den gegenwärtigen Zustand, was auch immer seine Vergangenheit gewesen war.

16
aklin81

JSF ist definitiv in der Lage, leistungsstarke Webanwendungen bereitzustellen. Die App, an der ich gerade arbeite, ist vollständig in JSF und aus den Protokollstatistiken geht hervor, dass viele nicht DB-intensive Seiten minimale Ausführungszeiten von 0 ms und durchschnittliche Zeiten von weniger als 10 ms haben.

Einige der Wicket-Leute haben Dinge über die Leistung von JSF gesagt, aber laut diesem aufwändigen Benchmark schneidet JSF tatsächlich besser ab als Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx -edition /

Beachten Sie, dass JSF auch eine bessere Leistung als GWT erbringt, solange der Server nicht gesättigt ist. Der GWT/JSF-Benchmark-Vergleich ist jedoch schwierig, da es wirklich wichtig ist, dass der Server für GWT auch die Konvertierung und Validierung von Daten im Postback von JSF durchführt. Dies können Sie in der Praxis einfach nicht auslassen (vertrauen Sie niemals dem Kunden). Bei den GWT- und JSF/Wicket-Diagrammen sollte berücksichtigt werden, dass der Rendering-Schritt des Browsers für JSF/Wicket trivial ist (da sie meistens bereit zum Rendern von HTML bereitstellen), der GWT-Client jedoch noch einige Arbeiten zu erledigen hat tun, nachdem Sie die Serverantwort erhalten haben.

Eines der Hauptprobleme bei der Leistung/Skalierbarkeit, die alte JSF-Versionen (vor 2.0) hatten, war der Missbrauch des Speicherns von Status, indem viel zu viele Daten darin abgelegt wurden. Dinge, die absolut nicht dort gewesen sein sollten, wurden hineingelegt (wie Konstanten wie 'foo' wie in <my:tag attribute="foo"/>).

JSF 2.0 führte das partial state saving Mechanismus, dh nur der Delta-Status wird gespeichert. In der Praxis kann dies sehr gering sein, und Reduzierungen um zwei Größenordnungen im Vergleich zu JSF 1.x sind keine Seltenheit.

Nach Jahren der Verwendung von JSF kann ich sagen, dass ich, abgesehen davon, dass in JSF 1.x zu viel Status gespeichert wurde, nie auf Leistungsprobleme gestoßen bin, die ich JSF zuschreiben könnte. Alle Leistungsprobleme, die wir jemals hatten, wurzelten immer in der Datenbank und/oder wie wir Back-End-Services einrichteten, unsere Abfragen schrieben usw.

24
Arjan Tijms

Alle Theoretiker der Welt können sagen, dass JSF wunderbar ist, aber schauen Sie sich nur an, wie Ihre Seiten aussehen. Es produziert riesige Mengen an Javascript und anderem Mist, die Ihre Fähigkeit, Module wie jQuery oder die saubere Verwendung von CSS hinzuzufügen, erheblich beeinträchtigen werden. Nicht zu sagen, dass es nicht geht, aber zu welchem ​​Preis.

Persönliche Erfahrung mit einem relativ kleinen Projekt und mittlerer Komplexität. Ein Disaster. Es war ein Durcheinander mit all den Rückrufen und man kann andere Technologien nicht einfach einmischen. Wir hatten einen großen Fehler, der bei der Verwendung von JSTL in JSF verursacht wurde. Wir konnten nie alle jQuery-Inhalte verwenden, da JEDER Link ein Javascript-Rückruf ist.

Lauf weg und renn schnell weg.

Auch wenn Sie Skalierung sagen, von welcher Art von Skalierung sprechen Sie? Anzahl der Seiten, Anzahl der Benutzer, Anzahl der Anforderungen pro Sekunde, Anzahl der Funktionen. Die Antworten auf diese Fragen können Ihnen helfen. Auch wenn Ihnen jemand sagt, dass er skalieren muss, fragen Sie ihn, in welchem ​​Ausmaß und wie schnell. Die Antwort wird Ihnen enorm helfen. Wenn Sie in einer Woche über Google Scale sprechen oder über 1000 Benutzer und 10000 Seitenaufrufe pro Tag in einem Jahr.

Nahezu jedes Framework, bei dem Sie die Antworten nicht in Echtzeit im Hintergrund eingeben, lässt sich auf 99,999% der Anwendungsfälle skalieren.

8
Bill Leeper

Haftungsausschluss: Ich mag JSF. Wie auch immer, selbst mit dem neuesten RI (Mojarra 2.2.x) oder MyFaces, selbst mit der lang erwarteten zustandslosen Implementierung Leistung ist sehr schlecht. Dies liegt am JSF-Lebenszyklus und an der Tatsache, dass jede Ansicht (teuer) für jede Anforderung erstellt wird.

Um einen Hinweis zu erhalten, ist dies ein einfacher Benchmark gegen ein einfaches Servlet Java Servlet gegen eine JSF-Seite), die beide nur "Hallo Welt" drucken.

Servlet

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/NewServlet

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/NewServlet
Document Length:        128 bytes

Concurrency Level:      100
Time taken for tests:   0.970 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4300000 bytes
HTML transferred:       1280000 bytes
Requests per second:    10307.02 [#/sec] (mean)
Time per request:       9.702 [ms] (mean)
Time per request:       0.097 [ms] (mean, across all concurrent requests)
Transfer rate:          4328.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.0      1       5
Processing:     1    9   4.6      8      51
Waiting:        1    8   4.4      7      40
Total:          4   10   4.1      8      51

Percentage of the requests served within a certain time (ms)
  50%      8
  66%     10
  75%     11
  80%     11
  90%     12
  95%     14
  98%     29
  99%     33
 100%     51 (longest request)

[~ # ~] jsf [~ # ~]

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/xhtml/test/jsf.xhtml

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/xhtml/test/jsfxhtml
Document Length:        100 bytes

Concurrency Level:      100
Time taken for tests:   4.676 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4250000 bytes
HTML transferred:       1000000 bytes
Requests per second:    2138.60 [#/sec] (mean)
Time per request:       46.759 [ms] (mean)
Time per request:       0.468 [ms] (mean, across all concurrent requests)
Transfer rate:          887.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       6
Processing:     5   46   6.0     46      73
Waiting:        2   45   5.5     45      72
Total:          8   47   5.8     46      73

Percentage of the requests served within a certain time (ms)
  50%     46
  66%     48
  75%     50
  80%     51
  90%     54
  95%     56
  98%     60
  99%     62
 100%     73 (longest request)
4
gpilotino

Wenn Sie die Leistung von JSF (sowohl Mojarra 2.1.7 als auch MyFaces 2.1.7) besser verstehen und mit einem ähnlichen Framework wie Apache Wicket (1.4.20 und 1.5.5) vergleichen möchten, sehen Sie sich diese Informationen an tiefer Vergleich (MAI 2012):

Grundlegendes zu JSF 2 und Wicket: Leistungsvergleich

Der gute Teil ist, dass alles verfügbar ist (Code, experimentelle Daten, Anweisungen zur Reproduktion des Tests, ein ausführlicher ausführlicher Bericht). Es löst alle Ihre Fragen zur JSF-Leistung und Sie werden sehen, was Apache MyFaces kann.

3
lu4242

Ein Artikel, der ein wenig helfen könnte (obwohl nicht wirklich schlüssig), ist Server Centric Java Frameworks: Leistungsvergleich bei DZone Javalobby:

... In diesem Artikel wird überprüft, wie effektiv die meisten SPI Java Web) sind Frameworks beziehen sich auf teilweise vom Server bereitgestellte Änderungen. Wir sind nicht an Ereignissen ohne Serverkommunikation interessiert, dh an Ereignissen ohne (mögliche) Serversteuerung.

Wie werden sie gemessen?

Wir werden die Menge an Code messen, die an den Client gesendet wird, und zwar in Bezug auf die visuelle Änderung, die im Client durchgeführt wird .

Zum Beispiel erwarten wir für eine geringfügige visuelle Änderung (einige neue Daten) in einer Komponente nicht viel Code vom Server, dh das neue Markup, das als einfaches HTML benötigt wird oder in JavaScript eingebettet ist, oder einige allgemeine Anweisungen, die die neuen Daten enthalten visualisiert. Andernfalls scheint etwas nicht zu stimmen, beispielsweise wird die gesamte Komponente oder Seitenzone neu erstellt, wodurch Bandbreite und Client-Leistung (und möglicherweise Server-Leistung) verschwendet werden.

Da wir öffentliche Demos verwenden, erhalten wir keinen endgültigen und feinkörnigen Benchmark . Sie werden jedoch sehr starke Unterschiede zwischen den Frameworks feststellen.

Die Testtechnik ist sehr einfach und jeder kann sie ohne spezielle Infrastruktur durchführen. Wir brauchen nur FireFox und FireBug. In diesem Test werden FireFox 3.6.8 und FireBug 1.5.4 verwendet.

Die FireBug-Konsole protokolliert, wenn "XMLHttpRequests anzeigen" aktiviert ist, jede AJAX - Anforderung, die die Serverantwort anzeigt ...

Frameworks getestet

RichFaces , IceFaces , MyFaces/Trinidad , OpenFaces , PrimeFaces , Vaadin , ZK , ItsNat

... anscheinend ist PrimeFaces die einzige JSF-Implementierung, die frei von schwerwiegenden Leistungseinbußen ist ...

Ich konnte keinen richtigen Vergleich (für die Leistung) finden, wenn jemand einen findet, würde ich ihn gerne sehen!

3
Martijn Verburg

Es gibt ein Problem mit Facelets im Allgemeinen, das meiner Meinung nach ziemlich unpraktisch ist. Es ist viermal wortreicher als nötig und erfordert zu viel manuelle Arbeit, wenn Sie einen Schritt von etwas Primitivem entfernt sind. HybridJava wäre ein guter Ersatz für Facelets als Präsentations-Engine in JSF - es erledigt den gleichen Job (und insbesondere noch viel mehr - es macht alle "Bindungen" und IDs für Sie) mit viel weniger Tastenanschläge.

2
Dima

Also wollte ich einen ähnlichen Benchmark einfügen. Ich nahm eine Twitter bootstrap Beispielseite und konvertierte sie in xhtml strict. Danach habe ich genau eine ApplicationScoped CDI-Bean eingerichtet Das hat Hello, World zurückgegeben. Ich habe den EL-Ausdruck auf die Seite gesetzt. Für die JSF-Version habe ich den JSF-Ressourcenhandler verwendet, für die JSPX-Version habe ich HTML-Stil CSS und JS-Includes verwendet.

Ich habe die Apache-Bank verwendet, um die Ladezeit der Hauptseite zu testen. Der Test wurde auf einem nicht optimierten TomEE + v1.5.2-Server durchgeführt. Ich habe jeden Benchmark 5x durchgeführt und dann einen vollständigen GC durchgeführt, bevor ich eine Messung durchgeführt habe. Bost-Tests wurden in derselben JVM-Instanz durchgeführt, ohne die JVM neu zu starten. Ich habe den APR auf dem libpath verfügbar, bin mir aber nicht sicher, ob sich dies auf diesen Test auswirkt.

JSF ist langsamer, aber nicht viel, da es sich um sehr kleine Mengen handelt. Was nicht gezeigt wird, ist, dass JSF/JSPX mit zunehmender Komplexität der Seiten linear oder exponentiell skaliert.

Eine Sache, die mir aufgefallen ist, ist, dass JSPX im Vergleich zu JSF sehr wenig Müll produziert. Durch Ausführen des Benchmarks auf der JSPX-Seite sprang der verwendete Heap von 184 MB auf 237 MB. Wenn Sie den Benchmark in derselben JVM auf der JSF-Seite ausführen, springt der verwendete Heap von 108 MB auf mindestens 404 MB, aber eine automatische Speicherbereinigung wird aktiviert dieser Punkt. Es scheint, dass das Optimieren Ihres Garbage Collectors für JSF eine absolute Notwendigkeit ist .

JSF

[email protected]:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/index.jsf
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.Apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/index.jsf
Document Length:        2904 bytes

Concurrency Level:      100
Time taken for tests:   2.138 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      32160000 bytes
HTML transferred:       29040000 bytes
Requests per second:    4677.27 [#/sec] (mean)
Time per request:       21.380 [ms] (mean)
Time per request:       0.214 [ms] (mean, across all concurrent requests)
Transfer rate:          14689.55 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.3      1      21
Processing:     1   20   9.0     18      63
Waiting:        1   19   8.8     17      62
Total:          2   21   8.8     20      64

Percentage of the requests served within a certain time (ms)
  50%     20
  66%     23
  75%     25
  80%     27
  90%     32
  95%     39
  98%     46
  99%     50
 100%     64 (longest request)

JSPX

[email protected]:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/page2.jspx
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.Apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/page2.jspx
Document Length:        2440 bytes

Concurrency Level:      100
Time taken for tests:   1.273 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      26290000 bytes
HTML transferred:       24400000 bytes
Requests per second:    7856.63 [#/sec] (mean)
Time per request:       12.728 [ms] (mean)
Time per request:       0.127 [ms] (mean, across all concurrent requests)
Transfer rate:          20170.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    5   2.3      6      20
Processing:     1    8   4.6      6      40
Waiting:        1    8   4.3      6      40
Total:          2   13   3.8     12      41

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     13
  80%     13
  90%     17
  95%     20
  98%     24
  99%     28
 100%     41 (longest request)
1