JSF è sicuramente in grado di fornire applicazioni web ad alte prestazioni. L'app su cui sto lavorando è completamente in JSF e dalle statistiche del registro posso vedere che molte pagine non DB hanno tempi di esecuzione minimi di 0 ms e tempi medi inferiori a 10 ms.

Alcuni dei Wicket hanno detto cose sulla performance di JSF, ma secondo questo elaborato benchmark JSF si comporta in realtà meglio di Wicket: link

Si noti che fino a quando il server non è saturo, JSF offre prestazioni migliori di GWT. Il confronto tra benchmark GWT / JSF è tuttavia difficile, dal momento che è molto importante che il server per GWT esegua anche la conversione e la convalida dei dati nel postback di JSF. Questo è qualcosa che semplicemente non puoi lasciare in pratica (non fidarti mai del cliente). Inoltre, per i grafici GWT e JSF / Wicket, si dovrebbe tenere conto del fatto che il passaggio di rendering del browser è banale per JSF / Wicket (poiché servono principalmente HTML pronti per il rendering), ma il client GWT ha ancora del lavoro da svolgere fare dopo aver ricevuto la risposta del server.

Uno dei principali problemi di prestazioni / scalabilità che avevano le versioni vecchie JSF (precedenti alla 2.0), stava abusando del risparmio di stato inserendo troppi dati in esso. Cose che assolutamente non avrebbero dovuto essere lì dove sono state inserite (come costanti come 'pippo' come in <my:tag attribute="foo"/> ).

JSF 2.0 ha introdotto il meccanismo partial state saving , che significa che viene salvato solo lo stato delta. In pratica questo può essere molto piccolo e le riduzioni di due ordini di grandezza rispetto a JSF 1.x non sono rare.

Dopo anni di utilizzo di JSF, posso dire che, salvo il salvataggio di troppo stato in JSF 1.x, non ho mai riscontrato problemi di prestazioni che potrei attribuire a JSF. Tutti i problemi di prestazioni che abbiamo mai avuto sono stati sempre radicati nel DB e / o come abbiamo configurato i servizi di back-end, scritto le nostre query, ecc.

Tutti i teorici del mondo possono dire che JSF è meraviglioso, ma basta dare un'occhiata a come appaiono le tue pagine. Produce enormi pile di javascript e altre schifezze che ostacoleranno gravemente la tua capacità di aggiungere moduli come jQuery o l'uso pulito dei CSS. Non dire che non può essere fatto, ma a quale costo.

Esperienza personale con un progetto relativamente piccolo e media complessità. Un disastro. È stato un disastro affrontare tutte le callback e non è possibile mescolare facilmente altre tecnologie. Abbiamo riscontrato un bug enorme che si è verificato durante l'utilizzo di JSTL con JSF. Non siamo mai stati in grado di utilizzare tutta la roba di jQuery a causa del fatto che OGNI collegamento è un callback javascript.

Corri via e scappa via veloce.

Anche quando dici scala, che tipo di scala stai parlando. Numero di pagine, numero di utenti, numero di richieste al secondo, numero di funzioni. Le risposte a questi potrebbero aiutarti. Inoltre, quando qualcuno ti dice che ha bisogno di scalare chiedere loro di che grado e quanto velocemente. La risposta ti aiuterà moltissimo. Se stai parlando di google scale in una settimana o stai parlando di 1000 utenti e 10000 pagine viste al giorno in un anno.

Quasi tutti i framework, a meno di digitare in tempo reale le risposte in background, scaleranno per soddisfare il 99,999% dei casi d'uso.

Se vuoi capire più chiaramente come funziona JSF (sia Mojarra 2.1.7 che MyFaces 2.1.7) e confrontarlo con un framework simile come Apache Wicket (entrambi 1.4.20 e 1.5.5), dai un'occhiata a questo confronto approfondito (MAGGIO 2012):

Informazioni su JSF 2 e Wicket: confronto delle prestazioni

La buona parte è che tutto è disponibile (codice, dati sperimentali, istruzioni su come riprodurre il test, un rapporto dettagliato completo). Risolverà tutte le tue domande sulle prestazioni JSF e vedrai cosa è in grado di fare Apache MyFaces.

Dichiarazione di non responsabilità: mi piace JSF. Comunque, anche con l'ultimo RI (Mojarra 2.2.x) o MyFaces, anche con l'attesissima implementazione senza stato le prestazioni sono molto povere. Ciò è dovuto al ciclo di vita di JSF e al fatto che ogni vista è (ampiamente) costruita per ogni richiesta.

Per avere un indizio, questo è un semplice punto di riferimento contro un semplice servlet Java vs una pagina JSF, entrambi stampano solo "Ciao mondo"

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)

C'è un problema con Facelets in generale che IMHO è una cosa piuttosto scomoda da usare. È quattro volte più prolisso di quanto sia effettivamente necessario e richiede troppa fatica manuale una volta che si fa un passo indietro verso qualcosa di primitivo. HybridJava sarebbe un buon sostituto di Facelets come motore di presentazione all'interno di JSF - fa lo stesso lavoro (e anche molto di più, in particolare - rende tutti i "binding" e gli ID per te) con un numero molto inferiore di tasti.

Un articolo che potrebbe aiutare un po '(anche se non è davvero conclusivo) è Framework centronici server centrici: confronto delle prestazioni su DZone Javalobby:

...This article reviews how much effective most of the SPI Java web frameworks are on partial changes provided by the server. We are not interested in events with no server communication, that is, events with no (possible) server control.

How they are going to be measured

We are going to measure the amount of code that is sent to client regarding to the visual change performed in client.

For instance for a minor visual change (some new data) in a component we expect not much code from server, that is, the new markup needed as plain HTML, or embedded in JavaScript, or some high level instructions containing the new data to be visualized. Otherwise something seems wrong for instance the complete component or page zone is rebuilt, wasting bandwidth and client power (and maybe server power).

Because we will use public demos, we are not going to get a definitive and fine grain benchmark. But you will see very strong differences between frameworks.

The testing technique is very easy and everybody can do it with no special infrastructure, we just need FireFox and FireBug. In this test FireFox 3.6.8 and FireBug 1.5.4 are used.

The FireBug Console when "Show XMLHttpRequests" is enabled logs any AJAX request showing the server response...

Frameworks tested

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

...apparently the only JSF implementation free of serious performance penalties is PrimeFaces...

Non sono stato in grado di trovare un confronto corretto (per prestazioni), se qualcuno ne trova uno mi piacerebbe vederlo!

Quindi volevo lanciare un benchmark simile. Ho preso una pagina di esempio di bootstrap di Twitter e convertito in xhtml strict. Successivamente, ho impostato esattamente un bean CDI ApplicationScoped che restituiva Hello, World. Inserisco l'espressione EL nella pagina. Per la versione JSF, ho usato il gestore di risorse JSF, per la versione JSPX, ho usato lo stile HTML css e js include.

Ho usato il banco Apache per testare il tempo di caricamento della pagina principale. Il test è stato eseguito su un server TomEE + v1.5.2 non ottimizzato. Ho eseguito ogni benchmark 5x, quindi ho eseguito un GC completo prima di effettuare una misurazione. I test Bost sono stati eseguiti nella stessa istanza JVM senza riavviare JVM. Ho l'APR disponibile su libpath, ma non sono sicuro che ciò influenzi questo test.

JSF è più lento, ma non di molto, dato che abbiamo a che fare con quantità molto piccole. Ciò che è non dimostrato è come le pagine diventano più complesse, JSF / JSPX scala in modo lineare o esponenziale.

Una cosa che ho notato è che JSPX produce pochissima immondizia rispetto a JSF. L'esecuzione del benchmark sulla pagina JSPX ha causato il salto dell'heap utilizzato da 184mb a 237mb. Eseguendo il benchmark nella stessa JVM sulla pagina JSF, l'heap utilizzato passa da 108mb a least 404mb, ma a questo punto viene avviata una garbage collection automatica. Sembrerebbe che la regolazione del garbage collector per JSF sia una necessità assoluta .

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 converte il tuo codice java in uno script java. quindi funziona come uno script java sul lato client. Inoltre, puoi integrare css nelle tue applicazioni gwt. In generale, gwt è leggero e può funzionare su tutti i browser senza alcun problema. Non so molto su JSF. Ma penso dt, JSF non è flessibile come GWT.