J'ai entendu beaucoup de bien au sujet de JSF, mais pour autant que je sache, les gens se sont également plaints de cette technologie dans le passé, ne sachant pas à quel point la situation s'est améliorée. Nous considérons JSF comme une technologie probable pour un projet de réseau social. Mais nous ne sommes pas au courant des scores de performance de JSF et nous ne pouvons pas vraiment trouver de site Web haute performance existant qui utilisait JSF. Les gens se plaignent de ses problèmes d'évolutivité des performances.

Nous ne savons toujours pas si nous faisons la bonne chose en choisissant jsf, et nous aimerions donc tout savoir de vous à ce sujet et prendre en compte vos contributions.

Est-il possible de configurer JSF pour répondre aux besoins de haute performance des services de réseaux sociaux? Aussi jusqu'à quel point est-il possible de survivre aux problèmes actuels de JSF. Quels sont exactement ses problèmes?

Je ne m'inquiète pas des complexités de développement avec JSF de ce que les autres se plaignent habituellement parce que selon mon expérience personnelle, je pense que ce n'est pas vrai du tout, mais je suis plus préoccupé par les problèmes de performances et d'évolutivité. Et s'il vous plaît, ne vous contentez pas d'en abuser sur ses anciens problèmes liés aux versions précédentes. Je me soucie juste de l'état actuel quel que soit son passé.

JSF est certainement capable de fournir des applications Web hautes performances. L'application sur laquelle je travaille actuellement est entièrement en JSF et d'après les statistiques du journal, je peux voir que de nombreuses pages non intensives en DB ont des temps d'exécution minimum de 0 ms et des temps moyens inférieurs à 10 ms.

Certains des gars de Wicket ont dit des choses sur les performances de JSF, mais selon ce benchmark élaboré, JSF fonctionne en fait mieux que Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Notez que tant que le serveur n'est pas saturé, JSF fonctionne également mieux que GWT. La comparaison de référence GWT / JSF est cependant difficile, car il est vraiment important que le serveur pour GWT effectue également la conversion et la validation des données dans la publication que JSF fait. C'est quelque chose que vous ne pouvez tout simplement pas laisser de côté dans la pratique (ne faites jamais confiance au client). En outre, pour les graphiques GWT vs JSF / Wicket, il convient de prendre en compte que l'étape de rendu du navigateur est triviale pour JSF / Wicket (car ils servent principalement du HTML prêt à être rendu), mais le client GWT a encore du travail à faire. faire après avoir reçu la réponse du serveur.

L'un des principaux problèmes de performances / d'évolutivité anciennes versions de JSF (antérieures à 2.0) était l'utilisation abusive de l'état en y insérant beaucoup trop de données. Des choses qui n'auraient absolument pas dû être là où elles ont été mises (comme des constantes telles que 'foo' comme dans <my:tag attribute="foo"/>).

JSF 2.0 a introduit le partial state savingmécanisme, ce qui signifie que seul l'état delta est enregistré. En pratique, cela peut être très faible et des réductions de deux ordres de grandeur par rapport à JSF 1.x ne sont pas rares.

Après des années d'utilisation de JSF, je peux dire qu'à l'exception d'enregistrer trop d'état dans JSF 1.x, je n'ai jamais rencontré de problème de performance que je pouvais attribuer à JSF. Tout problème de performance que nous ayons jamais eu était toujours enraciné dans la base de données et / ou la façon dont nous configurions les services principaux, écrivions nos requêtes, etc.

Tous les théoriciens du monde peuvent dire que JSF est merveilleux, mais regardez simplement à quoi ressemblent vos pages. Il produit des tas massifs de javascript et d'autres conneries qui vont gravement handicaper votre capacité à ajouter des modules comme jQuery ou une utilisation propre de CSS. Je ne dis pas que cela ne peut pas être fait, mais à quel prix.

Expérience personnelle avec un projet relativement petit et une complexité moyenne. Une catastrophe. C'était un gâchis avec tous les rappels et vous ne pouvez pas mélanger facilement d'autres technologies. Nous avons eu un énorme bogue qui s'est avéré être causé lors de l'utilisation de JSTL mélangé avec JSF. Nous n'avons jamais pu utiliser tous les trucs jQuery car CHAQUE lien est un rappel javascript.

Fuyez et fuyez vite.

De plus, quand vous dites échelle, de quel type d’échelle parlez-vous. Nombre de pages, nombre d'utilisateurs, nombre de requêtes par seconde, nombre de fonctionnalités. Les réponses à ces questions peuvent vous aider. Aussi, lorsque quelqu'un vous dit qu'il doit évoluer, demandez-lui dans quelle mesure et à quelle vitesse. La réponse vous aidera énormément. Si vous parlez de l'échelle Google dans une semaine ou si vous parlez de 1 000 utilisateurs et de 10 000 pages vues par jour en un an.

Presque tous les frameworks, à moins que vous saisissiez les réponses en temps réel en arrière-plan, évolueront pour répondre à 99,999% des cas d'utilisation.

Avertissement: j'aime JSF. Quoi qu'il en soit, même avec la dernière RI (Mojarra 2.2.x) ou MyFaces, même avec la performance d' implémentation sans état tant attendue est très médiocre. Cela est dû au cycle de vie JSF et au fait que chaque vue est (de manière coûteuse) construite pour chaque demande.

Pour obtenir un indice, il s'agit d'une simple référence par rapport à un servlet java simple par rapport à une page JSF, les deux imprimant simplement "bonjour le monde"

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)

Si vous voulez comprendre plus clairement les performances de JSF (Mojarra 2.1.7 et MyFaces 2.1.7) et le comparer à un framework similaire comme Apache Wicket (1.4.20 et 1.5.5), jetez un œil à cette comparaison approfondie (MAI 2012):

Comprendre JSF 2 et Wicket: comparaison des performances

La bonne partie est que tout est disponible (code, données expérimentales, instructions sur la façon de reproduire le test, un rapport exhaustif détaillé). Cela résoudra toutes vos questions sur les performances JSF et vous verrez ce que Apache MyFaces est capable de faire.

Un article qui pourrait aider un peu (bien que pas vraiment concluant) est Frameworks Java centré sur le serveur: comparaison des performances chez DZone Javalobby:

... Cet article examine l'efficacité de la plupart des frameworks Web Java SPI sur les modifications partielles fournies par le serveur.Nous ne sommes pas intéressés par les événements sans communication avec le serveur, c'est-à-dire les événements sans contrôle de serveur (possible).

Comment ils vont être mesurés

Nous allons mesurer la quantité de code envoyée au client concernant le changement visuel effectué dans le client .

Par exemple, pour un changement visuel mineur (de nouvelles données) dans un composant, nous n'attendons pas beaucoup de code du serveur, c'est-à-dire le nouveau balisage nécessaire en HTML simple, ou incorporé dans JavaScript, ou quelques instructions de haut niveau contenant les nouvelles données à visualisé. Sinon, quelque chose semble incorrect, par exemple le composant complet ou la zone de page est reconstruit, gaspillant la bande passante et la puissance du client (et peut-être la puissance du serveur).

Parce que nous utiliserons des démos publiques, nous n'allons pas obtenir une référence définitive et fine . Mais vous verrez de très fortes différences entre les cadres.

La technique de test est très facile et tout le monde peut le faire sans infrastructure spéciale, nous avons juste besoin de FireFox et FireBug. Dans ce test, FireFox 3.6.8 et FireBug 1.5.4 sont utilisés.

La console FireBug lorsque "Show XMLHttpRequests" est activé enregistre toute requête AJAX montrant la réponse du serveur ...

Cadres testés

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

... apparemment, la seule mise en œuvre de JSF sans pénalités de performances graves est PrimeFaces ...

Je n'ai pas été en mesure de trouver une comparaison correcte (pour les performances), si quelqu'un en trouve une, j'adorerais la voir!

Il y a un problème avec les Facelets en général, à mon humble avis, c'est une chose assez gênante à utiliser. Il est quatre fois plus verbeux que nécessaire et nécessite trop de travail manuel une fois que vous avez fait un pas hors de quelque chose de primitif. HybridJava serait un bon remplacement pour Facelets en tant que moteur de présentation au sein de JSF - il fait le même travail (et bien plus encore, en particulier - il fait toutes les "liaisons" et identifiants pour vous) avec beaucoup moins de frappes.

Je voulais donc jeter un point de repère similaire. J'ai pris une page d'exemple de bootstrap twitter convertie en xhtml strict. Après cela, j'ai configuré exactement un bean CDI ApplicationScoped qui a renvoyé Hello, World. J'ai mis l'expression EL sur la page. Pour la version JSF, j'ai utilisé le gestionnaire de ressources JSF, pour la version JSPX, j'ai utilisé le style HTML css et js includes.

J'ai utilisé apache bench pour tester le temps de chargement de la page principale. Le test a été effectué sur un serveur TomEE + v1.5.2 non optimisé. J'ai exécuté chaque référence 5 fois, puis exécuté un GC complet avant de prendre une mesure. Les tests Bost ont été effectués dans la même instance JVM sans redémarrer la JVM. J'ai l'APR disponible sur le libpath, mais je ne suis pas sûr que cela affecte ce test.

JSF est plus lent, mais pas beaucoup, car nous traitons de très petites quantités. Ce qui n'est pas démontré, c'est que les pages deviennent plus complexes, JSF / JSPX évolue-t-il de manière linéaire ou exponentielle.

Une chose que j'ai remarquée est que JSPX produit très peu de déchets par rapport à JSF. L'exécution de la référence sur la page JSPX a fait passer le segment de mémoire utilisé de 184 Mo à 237 Mo. L'exécution de la référence dans la même machine virtuelle Java sur la page JSF fait passer le segment de mémoire utilisé de 108 Mo à au moins 404 Mo, mais un garbage collection automatique a démarré à ce stade. Il semblerait que régler votre garbage collector pour JSF soit une nécessité absolue .

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 convertit votre code java en script java. il s'exécute donc en tant que script java côté client. Et aussi, vous pouvez intégrer css dans vos applications gwt. En général, gwt est léger et peut fonctionner sur tous les navigateurs sans aucun problème. Je ne connais pas grand-chose à JSF. Mais je pense que dt, JSF n'est pas aussi flexible que GWT.