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.