Tests de charge : Un peu d’histoire

Ou plutôt pourquoi je me suis remis à faire des tests…..

Il y a deux objectifs dans ma démarche :

1. améliorer les sites de nos clients. Les tests de charge permettent d’apprécier le comportement d’un site lors de fortes audiences et de détecter les éventuelles contentions.
2. développer la maîtrise du Web chez les développeurs. A travers la mise au point des scénarios, on apprend comment un navigateur dialogue avec un site Web. C’est une brique essentielle dans la fabrication des sites Web.

Un sujet récurrent depuis le début du Web

On connaît tous l’importance des temps de réponse et les problématiques d’audience des sites Web.

En 1996, lorsque j’ai travaillé sur le premier site Web bancaire français, j’ai mis au point mon premier outil de test car il n’y avait aucun produit pour accomplir cette tâche. J’ai utilisé l’inoxydable Telnet pour simuler des connexions, des scénarios et des tests de charge !

A cette époque, Telnet sur HP-UX permettait d’injecter des requêtes HTTP avec un pipe.

Ca donnait des commandes de ce type :

Grâce à la simplicité du protocole HTTP, ça devenait (plus ou moins) facile d’injecter des requêtes POST, de stocker des cookies et de jouer un scénario avec des Shell scripts. C’est ainsi que j’ai commencé les tests de charge sur le site que j’étais en train de construire.  J’avais baptisé ce petit programme de tests “Gator”. On s’en servait également pour les tests systèmes, fonctionnels de bout en bout. On avait déjà un ancêtre de Sélénium pour les recettes.

Malheureusement, la grande majorité des “Telnet” ne supportaient pas le pipe. J’ai donc réécrit Gator en Perl, ce qui a donné naissance à gator.pl

Cette fois le script Perl était bien plus évolué et prenait en entrée des scénarios de test sous forme de fichiers.

Au début des années 2000, on n’envoyait pas beaucoup d’informations dans les headers et le JavaScript ne posait pas trop de problèmes. On était capable de créer nos tests sans sniffer le trafic Web, uniquement avec la connaissance des pages à tester.

Néanmoins, la mise au point de ce type de tests n’était  possible que par les développeurs. Et les années passant, je me suis dit que les scripts Perl étaient trop compliqués à maintenir et je me suis tourné vers un produit. Comme à l’époque je programmais en Java et j’utilisais Tomcat comme serveur applicatif, je me suis naturellement tourné vers Jakarta JMeter, qui faisait partie de la même suite logicielle que Tomcat, pour faire les tests de charge.

Les RFC

L’intérêt de travailler sur la mise au point des scénarios de tests de charge est de comprendre le dialogue entre un client (navigateur) et un serveur Web. Ce dialogue a été formalisé pour la première fois dans un « Request For Comment », la RFC 1945 écrite en partie par Tim Berners Lee qui détaille le protocole HTTP. Par la suite d’autres RFC , comme la RFC 2068 ont complété cette documentation au fur et à mesure que le protocole s’est enrichi. Depuis, il y a eu bien d’autres RFC qui illustrent la complexité du dialogue entre le client Web et le serveur.

Depuis quelques années, cette communication est au cœur de l’optimisation de l’expérience client. Tout le monde s’y intéresse et des logiciels comme Google PageSpeed qui font aujourd’hui le bonheur des agences digitales, décortiquent en détail cette communication. On parle ici des performances d’un site.

Les tests de charge supposent idéalement que le site est déjà performant. On constate en pratique qu’un site performant supporte mieux la charge qu’un site peu performant. Ça veut dire que les équipes qui ont travaillé sur le projet étaient déjà sensibles à la performance.

Pour autant les tests de charges vont permettre de trouver des optimisations liées aux pics d’audience. C’est leur objectif premier, mais on peut trouver bien d’autres contentions ou imperfections avec ce type de tests !