JSF est-il vraiment prêt à fournir des applications Web hautes performances?
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 utilise 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 suis pas préoccupé par les complexités de développement avec JSF, ce que les autres se plaignent généralement, car 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 simplement 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é que rencontraient les anciennes versions JSF (antérieures à 2.0), était d'abuser de l'enregistrement de l'état en y mettant 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 saving mé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. Cela ne veut pas dire 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 parlez-vous de 1000 utilisateurs et de 10000 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 le dernier RI (Mojarra 2.2.x) ou MyFaces, même avec le très attendu implémentation sans état les performances sont très médiocres. 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'un simple benchmark par rapport à un simple Java servlet vs une page JSF, tous deux affichant simplement "hello world"
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 (mais pas vraiment concluant) est Server Centric Java Frameworks: Comparaison des performances chez DZone Javalobby:
... Cet article examine l'efficacité de la plupart des SPI Java sont sur des changements partiels fourni 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'obtiendrons pas de 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 implémentation JSF exempte de graves pénalités de performance est PrimeFaces ...
Je n'ai pas pu trouver une comparaison correcte (pour la performance), 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 même beaucoup plus, en particulier - il fait toutes les "liaisons" et identifiants pour vous) avec beaucoup moins frappes.
Je voulais donc lancer un benchmark similaire. J'ai pris un Twitter bootstrap page d'exemple et l'ai converti 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é le banc Apache 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é 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 provoque le saut du tas utilisé de 108 Mo à au moins 404 Mo, mais une collecte automatique des ordures a démarré à ce point. Il semblerait que le réglage de 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)