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 der Performance-Scores von JSF nicht bewusst und konnten auch keine existierende Hochleistungs-Website finden, die JSF verwendet hatte. Die Leute beschweren sich über Probleme mit der Leistungsskalierbarkeit.

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

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

Ich mache mir keine Sorgen über die Komplexität der Entwicklung bei JSF, über die sich andere normalerweise beschweren, weil ich meiner persönlichen Erfahrung nach der Meinung bin, dass dies überhaupt nicht zutrifft, aber ich mache mir mehr Sorgen darüber, welche Leistungs- und Skalierbarkeitsprobleme auftreten. Und bitte missbrauchen Sie es nicht nur wegen seiner alten Probleme, 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.

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 kann ich ersehen, 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 sich über die Leistung von JSF geäußert, aber nach 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 ausgelastet ist. Der GWT / JSF-Benchmarkvergleich ist jedoch schwierig, da es sehr wichtig ist, dass der Server für GWT auch die Konvertierung und Validierung von Daten im Postback durchführt, das 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 renderbereites HTML bereitstellen), der GWT-Client jedoch noch einige Aufgaben hat Tun Sie dies, nachdem Sie die Serverantwort erhalten haben.

Eines der Hauptprobleme in Bezug auf Leistung und Skalierbarkeit bei alten JSF-Versionen (vor 2.0) war die missbräuchliche Speicherung des Status, indem zu viele Daten darin abgelegt wurden. Dinge, die auf keinen Fall hätte da sein dürfen (wie Konstanten wie 'foo' wie in <my:tag attribute="foo"/>).

JSF 2.0 führte den partial state savingMechanismus ein, was bedeutet, dass nur der Delta-Status gespeichert wird. In der Praxis kann dies sehr gering sein, und Verringerungen um zwei Größenordnungen im Vergleich zu JSF 1.x sind keine Seltenheit.

Nachdem ich JSF jahrelang verwendet habe, kann ich sagen, dass ich mit Ausnahme des Speicherns von zu viel Status in JSF 1.x nie auf ein Leistungsproblem gestoßen bin, das ich JSF zuschreiben könnte. Jegliche Performance-Probleme, die wir jemals hatten, waren immer auf die Datenbank und / oder die Art und Weise zurückzuführen, wie wir Back-End-Services eingerichtet, unsere Abfragen geschrieben usw.

Alle Theoretiker der Welt können sagen, dass JSF wunderbar ist, aber sehen Sie sich nur an, wie Ihre Seiten aussehen. Es produziert riesige Mengen von Javascript und anderem Mist, die Ihre Fähigkeit, Module wie jQuery oder die saubere Verwendung von CSS hinzuzufügen, erheblich beeinträchtigen werden. Ich sage nicht, 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 umzugehen, und man kann andere Technologien nicht einfach einmischen. Wir hatten einen großen Fehler, der bei der Verwendung von JSTL und JSF verursacht wurde. Wir konnten das gesamte jQuery-Material nie verwenden, da es sich bei JEDEM Link um einen JavaScript-Rückruf handelt.

Lauf weg und lauf schnell weg.

Auch wenn Sie Skala sagen, welche Art von Skala sprechen Sie. Anzahl der Seiten, Anzahl der Benutzer, Anzahl der Anfragen pro Sekunde, Anzahl der Funktionen. Die Antworten auf diese Fragen können Ihnen helfen. Auch wenn Ihnen jemand sagt, dass es skaliert werden muss, fragen Sie ihn, zu welchem ​​Grad und wie schnell. Die Antwort wird Ihnen enorm helfen. Wenn Sie in einer Woche über Google Scale sprechen oder wenn Sie über 1000 Benutzer und 10000 Seitenaufrufe pro Tag in einem Jahr sprechen.

Nahezu jedes Framework, in dem Sie Antworten nicht in Echtzeit im Hintergrund eingeben, wird so skaliert, dass es 99,999% der Anwendungsfälle erfüllt.

Haftungsausschluss: Ich mag JSF. Trotzdem ist die Leistung der Implementierung ohne Status trotz des neuesten RI (Mojarra 2.2.x) oder MyFaces 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 Vergleich zwischen einem einfachen Java-Servlet und einer JSF-Seite. Beide geben nur "Hallo Welt" aus.

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)

Wenn Sie die Leistung von JSF (Mojarra 2.1.7 und 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 dieses Handbuch 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 zum Reproduzieren des Tests, ein ausführlicher ausführlicher Bericht). Es werden alle Ihre Fragen zur JSF-Leistung beantwortet und Sie werden sehen, was Apache MyFaces kann.

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

... Dieser Artikel beschreibt, wie effektiv die meisten SPI Java-Webframeworks bei Teiländerungen sind, die vom Server bereitgestellt werden. Wir sind nicht an Ereignissen ohne Serverkommunikation interessiert, dh an Ereignissen ohne (mögliche) Serversteuerung.

Wie werden sie gemessen?

Wir werden die Menge des an den Client gesendeten Codes in Bezug auf die im Client vorgenommene visuelle Änderung messen .

Beispielsweise 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 oder eingebettet in JavaScript benötigt wird, oder einige Anweisungen auf hoher Ebene, die die neuen Daten enthalten visualisiert. Andernfalls scheint etwas nicht zu stimmen, z. B. wird die gesamte Komponenten- oder Seitenzone neu erstellt, wodurch Bandbreite und Clientleistung (und möglicherweise Serverleistung) verschwendet werden.

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

Die Testtechnik ist sehr einfach und jeder kann es ohne spezielle Infrastruktur machen, wir brauchen nur FireFox und FireBug. In diesem Test werden FireFox 3.6.8 und FireBug 1.5.4 verwendet.

Die FireBug-Konsole protokolliert bei aktivierter Option "Show XMLHttpRequests" alle AJAX-Anforderungen mit der Serverantwort ...

Frameworks getestet

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

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

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

Es gibt ein Problem mit Facelets im Allgemeinen, dessen Verwendung IMHO ziemlich unpraktisch ist. Es ist viermal wortreicher als nötig und erfordert zu viel manuelle Arbeit, wenn Sie einen Schritt von etwas Primitivem ablassen. HybridJava ist ein guter Ersatz für Facelets als Präsentations-Engine in JSF - es erledigt die gleiche Aufgabe (und noch viel mehr - es erledigt alle "Bindungen" und IDs für Sie) mit viel weniger Tastenanschlägen.

Also wollte ich einen ähnlichen Benchmark einbauen . Ich habe eine Twitter-Bootstrap-Beispielseite genommen und sie in xhtml strict konvertiert. Danach habe ich genau eine ApplicationScoped CDI-Bean eingerichtet, die Hello, World zurückgegeben hat. 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 CSS und JS Includes im HTML-Stil verwendet.

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

JSF ist langsamer, aber nicht viel, da es sich um sehr kleine Mengen handelt. Was nicht gezeigt wird, ist, dass die Seiten komplexer werden und JSF / JSPX linear oder exponentiell skaliert.

Eine Sache, die mir aufgefallen ist, ist, dass JSPX im Vergleich zu JSF sehr wenig Müll produziert. Wenn der Benchmark auf der JSPX-Seite ausgeführt wurde, 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. Zu diesem Zeitpunkt wurde jedoch eine automatische Garbage Collection gestartet. Es scheint eine absolute Notwendigkeit zu sein, Ihren Garbage Collector auf JSF abzustimmen .

JSF

jonfisher@peanut:~$ /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

jonfisher@peanut:~$ /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)

GWT konvertiert Ihren Java-Code in ein Java-Skript. so läuft es als Java-Skript auf Ihrer Client-Seite. Außerdem können Sie CSS in Ihre GWT-Anwendungen integrieren. Im Allgemeinen ist gwt leicht und kann problemlos in allen Browsern ausgeführt werden. Ich weiß nicht viel über JSF. Aber ich denke, JSF ist nicht so flexibel wie GWT.