Ho sentito molto bene su JSF, ma per quanto ne so la gente ha anche avuto molte lamentele serie con questa tecnologia in passato, non consapevole di quanto sia migliorata la situazione. Stiamo considerando JSF come una probabile tecnologia per un progetto di social network. Ma non siamo a conoscenza dei punteggi delle prestazioni di JSF né potremmo davvero imbatterci in alcun sito Web ad alte prestazioni esistente che utilizzava JSF. Le persone si lamentano dei suoi problemi di scalabilità delle prestazioni.

Non siamo ancora molto sicuri se stiamo facendo la cosa giusta scegliendo jsf, e quindi vorrei sentire tutto da te su questo e prendere in considerazione i tuoi input.

È possibile configurare JSF per soddisfare le esigenze di prestazioni elevate del servizio di social network? Anche fino a che punto è possibile sopravvivere con gli attuali problemi di JSF. Quali sono esattamente i suoi problemi?

Sto non preoccupato per la complessità di sviluppo con JSF ciò che gli altri di solito si lamentano perché come per la mia esperienza personale credo che non è affatto vero, ma io sono più preoccupato per quello che i problemi di prestazioni e scalabilità. E per favore non limitarti ad abusarne dei vecchi problemi collegati alle versioni precedenti. Mi interessa solo lo stato attuale qualunque sia stato il suo passato.

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

Alcuni ragazzi di Wicket hanno detto cose sulle prestazioni di JSF, ma secondo questo elaborato benchmark JSF ha effettivamente prestazioni migliori di Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

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

Uno dei maggiori problemi di prestazioni / scalabilità delle vecchie versioni JSF (precedenti alla 2.0) era abusare del salvataggio dello stato inserendo troppi dati al suo interno. 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 partial state savingmeccanismo, il 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, a parte il fatto di aver salvato troppo stato in JSF 1.x, non ho mai riscontrato problemi di prestazioni che potrei attribuire a JSF. Eventuali problemi di prestazioni che abbiamo mai avuto erano sempre radicati nel DB e / o nel modo in cui abbiamo impostato i servizi di back-end, scritto le nostre query, ecc

Tutti i teorici del mondo possono dire che JSF è meraviglioso, ma dai un'occhiata a come sono le tue pagine. Produce enormi pile di javascript e altre cazzate che compromettono gravemente la tua capacità di aggiungere moduli come jQuery o un uso pulito dei CSS. Non dire che non si può fare, ma a quale costo.

Esperienza personale con un progetto relativamente piccolo e una media complessità. Un disastro. Era un disastro con tutti i callback e non è possibile mescolare facilmente altre tecnologie. Abbiamo riscontrato un enorme bug che si è rivelato essere causato dall'uso di JSTL in combinazione con JSF. Non siamo mai stati in grado di utilizzare tutte le cose jQuery a causa del fatto che OGNI link è un callback javascript.

Scappa e scappa velocemente.

Anche quando dici scala, di che tipo di scala stai parlando. Numero di pagine, numero di utenti, numero di richieste al secondo, numero di funzioni. Le risposte a queste potrebbero aiutarti. Inoltre, quando qualcuno ti dice che è necessario ridimensionarlo, chiedigli in che misura 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 visualizzazioni di pagina al giorno in un anno.

Quasi tutti i framework, a meno che non si digiti in tempo reale le risposte in background, si ridimensioneranno per soddisfare il 99,999% dei casi d'uso.

Disclaimer: mi piace JSF. Ad ogni modo, anche con l'ultimo RI (Mojarra 2.2.x) o MyFaces, anche con le tanto attese prestazioni di implementazione senza stato è molto scadente. Ciò è dovuto al ciclo di vita di JSF e al fatto che ogni vista è (costosa) costruita per ogni richiesta.

Per avere un'idea, questo è un semplice punto di riferimento rispetto a un semplice servlet java rispetto a una pagina JSF, entrambi che stampano semplicemente "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)

Se vuoi capire più chiaramente le prestazioni di JSF (sia Mojarra 2.1.7 che MyFaces 2.1.7) e confrontarlo con un framework simile come Apache Wicket (sia 1.4.20 che 1.5.5), dai un'occhiata a questo in- confronto profondo (MAGGIO 2012):

Comprensione di JSF 2 e Wicket: confronto delle prestazioni

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

Un articolo che potrebbe aiutare un po '(anche se non in modo conclusivo) è Server Centric Java Frameworks: Confronto delle prestazioni su DZone Javalobby:

... Questo articolo esamina l'efficacia della maggior parte dei framework Web SPI Java sulle modifiche parziali fornite dal server. Non siamo interessati ad eventi senza comunicazione tra server, ovvero eventi senza controllo (possibile) del server.

Come verranno misurati

Misureremo la quantità di codice che viene inviato al client in relazione alla modifica visiva eseguita nel client .

Ad esempio per una piccola modifica visiva (alcuni nuovi dati) in un componente, ci aspettiamo che non ci sia molto codice dal server, ovvero il nuovo markup necessario come HTML normale o incorporato in JavaScript o alcune istruzioni di alto livello contenenti i nuovi dati da visualizzato. Altrimenti qualcosa sembra sbagliato, ad esempio il componente completo o l'area della pagina viene ricostruita, sprecando larghezza di banda e potenza del client (e forse potenza del server).

Poiché utilizzeremo demo pubbliche, non otterremo un benchmark definitivo e di qualità . Vedrai differenze molto forti tra i framework.

La tecnica di test è molto semplice e tutti possono farlo senza infrastrutture speciali, abbiamo solo bisogno di FireFox e FireBug. In questo test vengono utilizzati FireFox 3.6.8 e FireBug 1.5.4.

La Console FireBug quando "Show XMLHttpRequests" è abilitato registra qualsiasi richiesta AJAX che mostra la risposta del server ...

Strutture testate

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

... a quanto pare l'unica implementazione JSF priva di gravi penalità di prestazione è PrimeFaces ...

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

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 ha bisogno di troppo lavoro manuale una volta che fai un passo fuori da qualcosa di primitivo. HybridJava sarebbe un buon sostituto di Facelets come motore di presentazione all'interno di JSF - fa lo stesso lavoro (e ancora di più, in particolare - rende tutti i "vincoli" e gli ID per te) con un numero molto minore di tasti.

Quindi volevo lanciare un benchmark simile. Ho preso a pagina di esempio Twitter Bootstrap e l'ho convertita in xhtml rigoroso. Successivamente, ho impostato esattamente un bean CDI ApplicationScoped che ha restituito Hello, World. Ho messo l'espressione EL sulla pagina. Per la versione JSF, ho usato il gestore di risorse JSF, per la versione JSPX, ho usato lo stile HTML css e include js.

Ho usato la panchina di 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 5 volte, quindi ho eseguito un GC completo prima di eseguire 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 influenzi questo test.

JSF è più lento, ma non di molto, poiché abbiamo a che fare con quantità molto ridotte. Cosa è non dimostrato è che le pagine diventano più complesse, JSF / JSPX si ridimensiona in modo lineare o esponenziale.

Una cosa che ho notato è che JSPX produce pochissima spazzatura rispetto a JSF. L'esecuzione del benchmark sulla pagina JSPX ha causato il salto dell'heap usato da 184mb a 237mb. L'esecuzione del benchmark nella stessa JVM sulla pagina JSF fa sì che l'heap usato salti da 108mb ad almeno 404mb, ma a quel punto è iniziata una raccolta automatica dei rifiuti. Sembrerebbe sintonizzare il tuo garbage collector per JSF è 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 script java. quindi viene eseguito come 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 è così flessibile come GWT.