Publié par
Il y a 6 années · 4 minutes · Java / JEE, Performance

Devoxx – Performance comparison of Java Web frameworks

Après une intervention controversée de Matt Raible à Devoxx 2010 concernant la comparaison de frameworks Web, cette année trois personnes ont choisi de remettre le couvert :  Stijn Van den Enden, Guy Veraghert et Ward Vijfeijken.

Stijn débute la présentation en nous rassurant : leur recherche concerne une poignée de frameworks Web et est basée sur la scalabilité. Pour lui cette dernière est une notion importante :

  • Elle influe sur l’infrastructure
  • Elle assure une qualité de service
  • Elle a un coût non négligeable

Stijn nous explique qu’ils ont pris le parti de baser leur expérience sur les frameworks Web suivants :

  • GWT
  • JSF
  • Wicket
  • Spring MVC

Il poursuit avec le type d’application qui les intéresse :

  • Ecrans détaillés
  • Navigation de pages
  • Autocompletion
  • Ajax validation
  • Mise à jour du DOM

Ensuite pour tester la scalabilité de ces frameworks, l’expérience a porté sur :

  • Les temps de réponse
  • Think time (temps d’attente par un utilisateur avant de pouvoir effectuer une autre action)
  • Throughput (nombre de requêtes en succès par secondes)

Concernant la plateforme, les tests ont été effectués sur Amazon Web Server avec un Tomcat et une base de donnée MySQL.

Avant de nous dévoiler les résultats, Stijn nous explique que pour les analyser son équipe s’est basée sur le modèle théorique de la loi de Little afin d’avoir une référence pour faire parler les données. En résumé, le principe est de trouver un optimum concernant les temps de réponse et le nombre de threads supportés.

Ayant collecté énormément de données (plus de 300 millions de mesures), l’équipe a mis en place une application Web permettant de tracer des graphiques basés sur un bon nombre de paramètres activables / désactivables (CPU data, Memory data, nombre d’utilisateurs, etc..)

Après toutes ces explications sur l’environnement de tests, les résultats tombent enfin :

GWT est le grand gagnant suivi de très près par Spring MVC. Un peu plus loin nous avons Vaadin et dans les plus mauvais élèves nous retrouvons dans l’ordre JSF/Wicket et MyFaces. L’équipe a choisi d’intégrer Vaadin et MyFaces car ils n’avaient pas beaucoup de modifications à apporter.

A ce stade de la présentation, l’équipe nous dévoile qu’elle a été plus loin : la réalisation de tests sur le rendu des navigateurs.

Leur principal problème était que JMeter ne permet pas ce genre de tests. Ward nous présente alors leur solution: des plugins sur les navigateurs (firebug + network, Chrome developpment tool, HTTPWatcher) permettent d’extraire les données. Il nous parle ensuite de l’outil HAR Viewer qui permet d’interpréter et analyser ces données exportées, et nous explique l’automatisation de ces processus avec Selenium Web Server.

Encore une fois les résultats tombent : Wicket est le gagnant suivi de JSF, GWT et Spring MVC.

Néanmoins, Ward nous explique que les résultats sont légèrement biaisés : HAR déclenche son analyse trop tôt pour GWT. En effet, ce dernier a besoin de télécharger les javascripts avant de pouvoir effectuer un rendu. Des solutions en cours de développement peuvent y remédier (W3C Navigation timing API et W3C Resource timing API), mais ne sont pas encore disponibles.

Ward finit par nous présenter rapidement l’outil SpeedTracer, capable d’analyser les points de contentions sur les navigateurs (disponible seulement sous Chrome).

A travers tous ces tests, nous voyons que l’équipe a réalisé un travail réfléchi : mise en place d’un bon environnement de test, modèle théorique d’analyse des données, etc…, rendant les résultats justifiés et pertinents. Nous pouvons cependant regretter qu’ils n’aient pas intégré d’autres frameworks Web.

L’équipe conclue par le palmarès des frameworks en terme de coût de scaling pour 10000 utilisateurs avec des temps de réponse moyen à 200 ms

Le résultat final est GWT en premier, Spring MVC et JSF/Wicket.

Pour finir, Stijn ouvre le débat et pose la question suivant : c’est bien d’être rapide, mais le framework Web est-il vraiment le point de contention ? A méditer.

Nicolas Jozwiak
Nicolas est un ingénieur d'études confirmé disposant de 10 ans d'expérience de conception et développement sur technologies Java/JEE. Son parcours chez un éditeur avant son entrée chez Xebia lui a notamment permis de développer de solides compétences dans le domaine de la qualité et de l’industrialisation (tests, intégration continue, gestion de configuration, contrôle qualité). Nicolas est Directeur de projet chez Xebia Studio et bénéficie d’une expérience très solide de mise en place des méthodes agiles et d’accompagnement d’équipe sur le terrain. Il est reconnu pour son approche pragmatique, proactive et pédagogique.

6 réflexions au sujet de « Devoxx – Performance comparison of Java Web frameworks »

  1. Publié par kris, Il y a 6 années

    « Encore une fois les résultats tombent : Wicket est le gagnant suivi de JSF, GWT et Spring MVC. »

    –> o_O

    On n’était pas à la même talk alors :-)

    Jamais Wicket ou JSF n’est ressorti dans les premiers quelque soit le test …

  2. Publié par Nicolas, Il y a 6 années

    Bonjour,

    Sauf erreur de ma part, le graphe indiquait bien cet ordre concernant les tests de rendu dans les navigateurs… Auquel cas si vous pouviez m’indiquer l’ordre concernant ce test, je vous en serai reconnaissant.

    Nicolas (Xebia)

  3. Publié par Jeff, Il y a 6 années

    Ça ne rime pas à grand chose de comparer JSF et MyFaces, ce dernier étant une implémentation de JSF. Est-ce que le speaker voulait dire JSF = mojarra ?

  4. Publié par Nicolas BULTEAU, Il y a 6 années

    Je suis assez d’accord avec Chris : pour moi c’est springMVC, GWT, JSF et Wicket.
    http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/ (Difficile de donner un numéro de slide avec Prezi)
    Pour Jeff : de ce que j’en ai compris pour eux ‘JSF’ c’était l’implémentation référence majorra.

  5. Publié par Nicolas, Il y a 6 années

    Bonjour,

    @Nicolas
    Je suis d’accord avec ce résultat pour l’ensemble des tests (la conclusion de l’article va dans ce sens). Cependant l’ordre que j’ai relevé (Wicket, JSF, GWT et Spring MVC) concerne le test du rendu dans le navigateur (on ne voit pas les résulats dans les slides car c’était lorsqu’ils nous ont montré leur outil en modifiant des paramètres).

    Nicolas (Xebia)

  6. Publié par Gautier, Il y a 6 années

    Effectivement l’ordre dans la slide est bien (Wicket, JSF, GWT et Spring MVC) mais il s’agit de la note selon le critère Performance!

    Wicket et JSF ont environ 14 tandis que GWT et SpringMVC ont 17.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *