HTTP Rider est un outil capable d’enregistrer une liste de requêtes HTTP pour les rejouer ensuite. Il n’est pas possible de créer un parcours complexe avec des conditions ou des boucles. Cependant, il conviendra tout à fait aux cas où l’on souhaite obtenir un résultat rapide concernant les temps de réponse de certaines pages web. Voyons ce que l’on peut en tirer avec un exemple concret.
Un exemple concret
Comme d’habitude, je me base sur OpenCart (http://www.opencart.com/), une application open source tournant sur une pile WAMP. Cette application en PHP est intéressante, parce qu’elle présente les cas d’usage les plus répandus (CRUD, recherche, liste, détail) et elle est livrée avec un jeu de données minimaliste.
Jeu de données
Il est possible d’importer dans le scénario un fichier CSV, une table ou un onglet Excel afin de l’utiliser dans l’étape d’édition du scénario. Ici, j’ai choisi de créer une liste d’identifiants d’articles différents afin d’introduire de la variation dans les données utilisées. Ce qui permet de ne pas obtenir de trop bons résultats à cause des différents caches applicatifs.
Enregistreur
HTTP Rider utilise Fiddler afin d’enregistrer tous les échanges http (seulement les requêtes GET et POST) ayant lieu sur la machine où il est utilisé. On peut définir des règles d’inclusion ou d’exclusion d’URL afin de filtrer ce qui sera enregistré (et donc rejoué plus tard lorsque l’on lancera le tir).
Éditeur de script
L’étape suivant celle de l’enregistrement permet de supprimer des requêtes que l’on aurait oublié de filtrer. On peut aussi utiliser des paramètres issus des données que l’on aurait importées précédemment. Ici je lie le paramètre « product_id » à la première colonne de mon jeu d’essai.
On notera qu’il est possible d’enregistrer le scénario (mono-script en fait).
Exécution
La dernière étape permet de lancer le tir proprement dit. On peut fixer :
- Le nombre d’utilisateurs simulés en parallèle.
- La durée du tir (Elapse time).
- La pause à effectuer entre chaque requête http (think time).
- La limite à ne pas dépasser lorsque l’on attend la réponse HTTP (puisque le timeout est une notion définie sur le navigateur des visiteurs).
On obtient alors les temps de réponse des requêtes HTTP enregistrées. L’outil ne fournit pas d’autres rapports ou de possibilités d’export que ce que vous voyez sur cet écran.
Comment est fait HTTP Rider ?
- Il est en .Net et il ne tournera que sous Windows avec le framework 4.0.
- Il se base sur le composant Fiddler (le couteau suisse indispensable du consultant en performance) pour la capture des trames HTTP. http://fiddler2.com/
- Il utilise HTML Agility pack pour manipuler les en-têtes et corps de requête http://htmlagilitypack.codeplex.com/
- Et d’autres composants open source.
Les points forts d’HTTP Rider
- Assistant graphique permettant de créer un test de charge sans prétention, mais rapidement.
- Possibilité de capturer les requêtes http depuis n’importe quel exécutable émettant des trames HTTP (merci Fiddler).
- La possibilité d’utiliser un jeu de données afin d’introduire de la variation.
- Possibilités d’inclusion et d’exclusion d’URL.
Les points faibles d’HTTP Rider
- Ne supporte que le protocole HTTP (au niveau requête ou URL-based si on le comparait à LoadRunner).
- Le code source n’est pas disponible.
- C’est un projet expérimental (l’auteur n’a visiblement pas d’intention de le continuer ou de l’ouvrir aux contributeurs).
- La dernière version date du 24/02/2012.
- Limité aux verbes GET et POST.
- Ne supporte pas les sessions TLS (HTTPS).
- Pas de reporting (cependant, je pense que ce n’est pas son positionnement).
Conclusion
HTTP Rider est un outil intéressant qui est comparable à Apache Benchmark, mais que l’on pourrait situer un cran au-dessus parce qu’il est doté d’une interface graphique permettant de faire la capture des échanges et d’avoir un résultat rapide. J’ai bien aimé la possibilité de lier un jeu de données depuis Excel en toute simplicité (encore un point fort par rapport à AB).
Attention au fait que cet outil ne permet de monter un scénario composé que d’un seul script. On peut cependant lancer plusieurs instances de l’outil sur une seule ou plusieurs machines.
Malheureusement l’outil ne va pas plus loin en termes de résultats (pas de graph de type « over time ») ou de définition du scénario (rampe, etc.). J’ai de gros doutes sur sa pérennité et il est vraiment dommage que le code source ne soit pas disponible.
En bref, si vous souhaitez faire un test de charge vite fait afin d’avoir une idée des temps de réponse sans la complexité d’un JMeter ou d’un LoadRunner, foncez avant que l’outil ne disparaisse du net.
Pour aller plus loin
- Le scénario et le jeu d’essai utilisés pour cet article sont disponibles ici.
- Lien vers la page du projet.