Framework J2EE le plus rapide à afficher les pages

Bonjour à tous ;)

La question délicate du jour est :
Quel est d'après vous le framework J2EE le plus rapide ? Quand je dis "rapide", cela signifie que la page se charge le plus vite possible pour l'utilisateur.

Par exemple, j'ai essayé Struts 2.0.9 récemment et je le trouve particulièrement lent (2-3 secondes) pour afficher une page banale.

Bien évidemment, on ne prend pas en compte le temps de la première compilation de la jsp par le serveur d'application.

J'ai aussi entendu que Ruby était très lent également.

Bref, une idée du plus rapide ? Struts ? JSF ? Autres ?

A vous ;)

En même temps, tester avec une seule requête ce n'est pas forcément très représentatif des performances du framework. Il faudrait mieux faire des tests avec JMeter avec le nombre moyen d'utilisateurs de ton site.

Par contre, je n'ai jamais vu de comparatif de performances des différents frameworks web. On cherche plutôt en priorité la productivité plutôt que les performances.

Ok merci pour ta réponse.

Pour information, mon appli Struts2, que je sois seul à l'utiliser ou plusieurs, les temps de réponse toutes les pages sont les mêmes. C'est à dire un petit délai entre le clic et l'affichage (alors qu'il n'y a pas de calcul à faire). Je suppose que c'est la lourdeur du framework qui implique ces conséquences. Pour info, je n'ai pas mis bcp d'interceptors sur mes pages (concept repris par Struts 2).

La question reste entière :
Quelqu'un a t-il pu comparer les performances de Struts/JSF/Struts2/Spring MVC/... ?

Bonjour,
Question délicate en effet.

Je n'ai pas vraiment fait de comparatif entre plusirus frameworks, mais juste pour dire que selon mon expérience, JSF est tout sauf une foudre de vitesse.
J'en parle ici un peu.

Merci pour ce lien intéressant.

Au sujet du message sur le temps CPU sur le blog :
Nous savons tous que le javascript est une grosse merde qui pompe un max de ressource. Donc ce n'est pas surprenant que ton temps CPU sera en majeure partie pris par ajax. Ta partie métier et ta partie d'accès aux données sont faites en Java, langage bien moins rapide que le C++ mais tellement plus que le javascript :mouarf:

Bon sinon

Citation:

---

Question délicate en effet

---

Tout à fait. Sur le web, on trouve beaucoup de commentaires sur les frameworks, mais rarement concernant les performances. Hors, chez nous, c'est extrêmement important. Quand je vois le temps que met Struts 2 à afficher un "hello world" i18n, je me dis "mais où va t-on" 8O

Citation:

---

Envoyé par tiboudchou

Nous savons tous que le javascript est une grosse merde qui pompe un max de ressource. Donc ce n'est pas surprenant que ton temps CPU sera en majeure partie pris par ajax. Ta partie métier et ta partie d'accès aux données sont faites en Java, langage bien moins rapide que le C++ mais tellement plus que le javascript :mouarf:

---

Je ne suis pas sûr de te suivre là: le JS s'exécute du côté client, or les mesures e performances que j'ai réalisé sont côté serveur, donc, jene vois pas bien le rapport :koi:

Ah oui très juste en effet. Je n'étais pas réveillé ce matin, désolé. :aie:

Autre possibilité : pour ta couche DAO ainsi que ta couche métier, tu codes davantage de chose toi même en Java (jdbc, logique métier, ...)
Alors que pour tes composants qui te prennent pas mal de ressources, tu utilises des "packages" tout fait. T'as pas trop le choix tu me diras :P Ca rejoint très bien ma question. On peut même en poser une autre : Les développeurs de framework J2EE/ajax se sont-ils déjà soucier des performances ? :roll:

à mon avis que non, moi j'utilise Jsf et je vois qu'il y a le même défit que strust,(en faisons un nouveau Load).
Mais,à mon avis, on ne peu pas contrôler la performance d'une framework et d'une autre car ça reste toujours liée au complexité des requêtes et aux nombres d'accé au base.

Tapestry 5 a un systeme de pool de page qu'il réutilise en fonction des demandes.
Je trouve notre site véloce, le client aussi, mais nous ne sommes pas encore en période de stress test. Et puis là partie métier est en Oracle PL/SQL.

Citation:

---

Envoyé par tiboudchou

Bonjour à tous ;)

La question délicate du jour est :
Quel est d'après vous le framework J2EE le plus rapide ? Quand je dis "rapide", cela signifie que la page se charge le plus vite possible pour l'utilisateur.

Par exemple, j'ai essayé Struts 2.0.9 récemment et je le trouve particulièrement lent (2-3 secondes) pour afficher une page banale.

Bien évidemment, on ne prend pas en compte le temps de la première compilation de la jsp par le serveur d'application.

J'ai aussi entendu que Ruby était très lent également.

Bref, une idée du plus rapide ? Struts ? JSF ? Autres ?

A vous ;)

---

Bonsoir,

C'est vrai que pratiquement personne ne compare les perfs des frameworks web alors que c'est une caractéristique importante des frameworks. En fonction du type d'appli que l'on envisage, ça peut même être un critère déterminant. Ainsi, certains frameworks seront plus adaptés à des applis complexes et dynamiques (je pense à Wicket par exemple) tandis que d'autres pourront tenir une charge élevée pour un site à forte audience, mais relativement peu interactifs. Personnellement, je pense qu'il n'existe pas de framework adapté à toutes les situations, et donc il faut choisir le framework en fonction du type d'application envisagé.

L'absence de comparaison peut s'expliquer par le fait que peu de gens maitrisent plus d'un ou deux frameworks. Idéalement, il faudrait que tous les frameworks viennent avec une implémentation d'un même site web, le pet shop de Sun par ex. Cela permettrait de faire une comparaison des frameworks sur un exemple complet.

J'avais fait une petite recherche sur les perfs il y a quelques semaines et je suis tombé sur un blog:
http://javajmc.blogspot.com/2006/10/...rformance.html

Technology - Hits per second with 1 user / 10 users:

Struts 1 - 109 / 191
Stripes - 88 / 140
WW2/SAF2 with default FreeMarker templates - 12 / 7
WW2/SAF2 with Velocity templates - 22 / 15
JSF - 27 / 40

Comme tu le vois, les résultats du blogger et des commentaires du blog confirment la relative lenteur observée de Struts 2/WebWorks2 et de JSF par rapport à Struts. Le seul framework testé qui tienne la comparaison par rapport à Struts est Stripes (encore un bon point pour ce framework réputé simple et excellent).

Mais ensuite, la lenteur du framework de présentation n'est qu'une partie de l'équation, car il faut lui ajouter la lenteur des requêtes en BD qui est souvent déterminante (dans le cas de JSF, ce serait quand même JSF qui est déterminant).
Ceci étant, dans les cas finalement assez rares où la vitesse est vraiment déterminante (des centaines ou milliers de connexions simultanées), il vaut p-ê mieux faire du PHP, car même si le langage est lui-même plus lent que Java, PHP est généralement bcp moins lourd qu'une pile JEE.

Très intéressant :ccool:
Comme c'est montré dans le lien donné par el muchacho, un classique dans le genre bouffeur de CPU est OGNL qqui est justement le dénominateur commun entre WebWork et Struts 2.

Et justement, l'équipe de Wicket s'en est débarassé comme évaluateur d'expressions pour leur propre implémentation à cause de ça dans la version 1.2.

En passant...

Pour avoir utilisé struts 1.3 un grand nombre de fois, je peux te dire que les performances sont excellentes.
Maintenant, avant de conclure quoi que se soit sur tel ou tel framework, il faudrait déjà savoir ce que tu as codé, le problème de lenteur est (à mon avis) plus spécialement là... ;)

Pour JSF, c'est surtout les taglibs d'IHM qui peuvent être gourmandes (RichFaces est relativement gourmand), mais bon, on veut du beau et du facile à mettre en oeuvre... il faut bien en payer le prix :aie:

A+

Non non, on ne parle pas de ce que j'ai codé, ou même des accès BD.
Je parle juste du fait d'afficher une bête page.

D'une part, j'ai codé un framework J2EE à la main
D'autre part, j'ai utilisé Struts2

J'ai fait la même application (donc même code, même accès BD), et bien sous Struts2, on sent une certaine latence quand on clique sur les pages... A tel point que l'on se demande si on a vraiment cliqué. Je trouve cela assez hallucinant. Alors la, vous allez me dire qu'il y a la notion "d'interceptor" dans Struts2 et que j'en ai mis trop sur la page, que nenni. Une seconde, c'est trop long pour afficher un "Hello world" !

En tout cas, merci à tous pour vos réponses.

Je vais tester Struts 1 (je l'ai déjà utilisé il y a fort longtemps mais n'avait pas prête attention à d'éventuels temps de latence).

Citation:

---

Envoyé par tiboudchou

Je vais tester Struts 1 (je l'ai déjà utilisé il y a fort longtemps mais n'avait pas prête attention à d'éventuels temps de latence).

---

Bon choix, même si c'est un peu vieux et qu'à priori il n'y aura plus (beaucoup) d'évolution sur ce framework.
Au moins, tu trouveras plein d'aide (au cas où)...

Pour moi, dans cette techno, le trio gagnant serait :
- struts 1.3
- struts-layout pour l'IHM
- tiles

(Après, pour la DB, c'est Hibernate...)

A+

Citation:

---

Pour moi, dans cette techno, le trio gagnant serait :
- struts 1.3
- struts-layout pour l'IHM
- tiles

---

Ce n'est pas mon trio gagnant. La première raison est l'utilisation de Spring. Struts 1.3 ne s'intègre pas très bien avec la version 1.3. Ensuite, je trouve la version 1.3 trop verbeuse.
D'où ma préférence pour Spring MVC et le COC (Convention Over Configuration), on peut réduire le fichier de configuration à peau de chagrin. De plus étant donné que cela fait partit de Spring, il n'y a pas de problème d'intégration.
Après, si je veux construire une interface graphique plus riche, peut être que je tournerais vers un autre framework. Peut être wicket ou autre chose.

Je ne suis pas non plus un fan de tiles qui est là aussi trop verbeux. Je préfère sitemesh basé sur le modèle de conception décorateur. Je trouve ça plus pratique à utiliser.

Citation:

---

Envoyé par darkxan

Je ne suis pas non plus un fan de tiles qui est là aussi trop verbeux. Je préfère sitemesh basé sur le modèle de conception décorateur. Je trouve ça plus pratique à utiliser.

---

Verbeux tiles ? Je trouve ça hyper concis 8O

Je suis allé voir ce qu'était SiteMesh (je ne connais pas), trop tôt pour en dire quoi que ce soit... Si tu peux me dire ce que ça fait (que tiles ne fait pas)
ça m'arrangerait bien ;)

Si tu veux savoir, il suffit de lire le tutorial sur sitemesh disponible sur ce site. :mouarf: