JSF est-il vraiment prêt à fournir des applications Web hautes performances? [fermé]


16

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é.


7
ptrthomas.wordpress.com/2009/05/15/jsf-sucks Je sais qu'il y a eu une réponse de l'architecte en chef JSF qui justifie chaque décision, mais pour moi, quelqu'un qui connaît certaines technologies web et qui a souffert, même avec JSF 2.0, Facelets et SEAM, c'est de la moquerie. Même James Gosling dit: "Je déteste JSF avec passion." J'utiliserais Wicket ou Tapestry et j'éviterais JSF et ses problèmes.
Falcon

12
@ ThorbjørnRavnAndersen Je suis en désaccord avec vous doucement. Je pense qu'il vaut mieux fournir plus d'explications que de simplement dire: "Je déteste JSF"
Chiron

6
@ ThorbjørnRavnAndersen Je comprends votre point mais j'encourage vraiment les gens à fournir plus d'informations. Par exemple, un vote négatif sans commentaire me dérange toujours.
Chiron

3
@Chiron, la question n'est pas de savoir si JSF est utilisable ou non, mais si JSF peut être fait pour fonctionner. Les personnes qui commencent par mettre le cadre en place ne peuvent probablement pas répondre à la question réelle. Je maintiens moi-même une application JSF.

3
> Même James Gosling dit: "Je déteste JSF avec passion." - C'est bien connu, c'était une erreur, comme il voulait dire JSP. Écoutez attentivement le fragment en question. Il s'agit de ce qui a été créé en réponse à l'ASP classique, et c'était JSP, pas JSF.
Arjan Tijms

Réponses:


24

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.


1
0 ms ... Je pense que vos moyens de mesure doivent être examinés.
gbjbaanb

2
@gbjbaanb Je ne pense pas, cela provenait de statistiques qui ont été établies de manière très professionnelle. Notez que je parle du temps minimum et des pages non intensives en DB . Les pages qui s'exécutaient à ce moment-là n'avaient évidemment pas 1000 composants répartis sur 100 inclusions. Nous parlons ici de pages relativement simples, peut-être 10 composants, 1 modèle principal, peut-être 1 inclus, sur un serveur qui fonctionne depuis un certain temps, donc tout est chaud et en mémoire. Le temps moyen est plus élevé (10 ms comme je l'ai mentionné) et 90% plus élevé aussi. Max peut être n'importe quoi.
Arjan Tijms

La situation est que ce monde ne critique que les choses qui sont capables de résoudre tous les problèmes. Mais que résoudre tous les problèmes a toujours un prix et nécessite un grand zèle et un enthousiasme. Ce que j'ai vu dans les équipes, c'est qu'elles commencent à se développer sans même comprendre le cycle de vie. Cela implique une courbe d'apprentissage abrupte, mais c'est aussi beau que remarquable.
Shirgill Farhan

Le goulot d'étranglement est plus susceptible d'être dans la base de données / IO et la bande passante (mobile ...) que le serveur lui-même. Java est vraiment rapide lorsqu'il est bien utilisé.
Christophe Roussy

8

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.


3
-1 pour toutes les échelles du cadre. C'est comme dire «ne vous souciez pas de la performance».
Raynos

3
En soi, tout cadre Web publié évoluera, y compris JSF. Ils disent tous que oui, ce serait un cadre assez merdique si ce n'était pas le cas. Cela dit, beaucoup de gens font des choses stupides avec cela et c'est généralement là que les problèmes de mise à l'échelle se posent.
Bill Leeper

1
vrai, mais certains frameworks vous encouragent à faire des choses avec entrave à l'échelle, soit parce que le framework l'encourage, soit que la communauté l'encourage. Je dirais que ces cadres ne sont pas à l'échelle.
Raynos

Le bit "comment mesurez-vous la mise à l'échelle" devrait peut-être être un commentaire à la question?

4

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)

1
Je ne pense pas qu'une simple page helloworld puisse être représentative ou significative. Une comparaison sérieuse doit fournir les informations nécessaires comme les numéros de version, la configuration utilisée, etc. Veuillez lire la comparaison entre JSF et Wicket dans une réponse précédente.
lu4242

Permettez-moi d'être en désaccord. Je trouve vraiment significatif que dans le contexte sans état le plus simple, jsf soit 5 fois plus lent que jsp. Il est trivial de vérifier que dans des scénarios plus complexes, les performances de jsf deviennent pires. Ou je peux fournir plus de repères pour les plus paresseux :-) La mise en œuvre de jsf est mojarra 2.2 comme indiqué ci-dessus, avec glassfish 3
gpilotino le

"... jsf est 5 fois plus lent que jsp ..." Je pense que l'erreur ici est de ne pas prendre en compte le débit et le comportement sous-jacent de jsp vs jsf. C'est trop complexe à expliquer, mais dans ce cas, le temps de réponse est évidemment plus lent car jsf a un effet de concurrence que jsp n'a pas. Mais à la fin, il est plus précis de comparer les cycles par seconde. En outre, Mojarra n'est pas identique à MyFaces, donc les deux implémentations ont des nombres différents du point de vue des performances. Notez que l'effet de concurrence dans ce cas est exagéré.
lu4242

En fait, il est complètement absurde de comparer un servlet simple contre JSF. La seule comparaison qui a du sens est une "application" faite en utilisant JSP / servlets vs une autre "application" qui fait exactement la même chose en utilisant JSF. Pourquoi? parce que JSF fournit des solutions intégrées pour le rendu / ajax / navigation / validation, des choses qui doivent être faites à partir de zéro ou à la main dans JSP. Même si la comparaison est intéressante du point de vue des performances (aucun cadre ne sera plus rapide que servlet / jsp), JSP ne correspond pas à JSF, car il ne fait même pas une petite partie de ce que JSF fait pour vous.
lu4242 du

"il est complètement absurde de comparer un servlet simple contre JSF". non ce n'est pas. les deux technologies sont censées fournir du contenu. c'est pourquoi je prends en compte les contextes sans état, où la validation et d'autres choses ne comptent tout simplement pas. "le temps de réponse est évidemment plus lent car jsf a un effet de concurrence que jsp n'a pas" n'est-ce pas un problème d'évolutivité en soi? à propos de myfaces, afaik mojarra, c'est la mise en œuvre la plus rapide (je vais enquêter)
gpilotino

3

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.


3

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!


2

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.


1

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)

-3

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.


1
Il ne répond pas à la question, qui concerne les performances JSF et non la recommandation du cadre. Quoi qu'il en soit, GWT est généralement apprécié par les personnes qui ne connaissent pas JavaScript ^^
Danubian Sailor
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.