J’ai déjà abordé à 3 reprises les tests de montée en charge pour des sites ou des applications web :

  • via ApacheBench, à travers des commandes en ligne depuis un serveur,
  • avec LoadImpact, qui vous permet de tester des montées en charge sur des sites ou applications jusqu’à 50 utilisateurs simultanés gratuitement.

La semaine dernière, j’ai découvert presque caché dans le panier du libre de Nicolargo un nouveau concurrent : Blitz.io, et là….tadaaaa ! :)

Complètement développé en node.js, Blitz.io vous propose des tests de performances, ainsi que des tests de montée en charge pour votre site, application web, ou API RESTful. Blitz.io apporte beaucoup de fraîcheur dans l’écosystème des tests de performances.

Un test de performance simple sur Blitz.io

Un test de performance simple sur Blitz.io

Premier bon point : pas d’identifiants supplémentaires à créer, on peut se connecter avec un compte Google ou un compte Facebook. C’est rapide et efficace ! Ensuite, pour le reste, tout se déroule dans la « blitz bar«  : les tests sont lancés via une ligne de commande.

Un test est nommé « blitz », et 3 types sont disponibles  :

  • SPRINT: on fait un test de performance simple (en gros un test de vitesse). Combien de temps faudra-t-il pour charger une page ou avoir la réponse d’une API ? Le résultat ressemble à une sortie d’un test Firebug.
  • RUSH : permet de faire un test de montée en charge avec plusieurs dizaines ou plusieurs centaines d’accès concurrents (jusqu’à 1 000 000 utilisateurs simultanés moyennant finance),
  • CONDITIOn : permet de faire des tests réguliers via un gem Ruby (et une clé d’API) depuis un de vos postes/serveurs.
Affichage de la réponse du serveur lors d'un test simple avec Blitz.io

Affichage de la réponse du serveur lors d'un test simple

En entrant –variables dans le champ de Blitz, on affiche les options et les variables possibles pour lancer un test (voir capture ci-dessous).

Paramètres à appliquer au test Blitz.io

Paramètres à appliquer au test Blitz.io

Après ce test un peu simple, on peut passer aux choses sérieuses et simuler une montée en charge jusqu’à 250 utilisateurs simultanés (maximum pour la version gratuite de Blitz.io).

On peut utiliser par exemple la commande suivante : –region ireland –pattern 1-250:60 www.woueb.net

On peut la décomposer de la façon suivante :

  • –region ireland : pour spécifier la zone géographique à partir de laquelle le test sera lancé le test (sont déjà disponibles california , virginia , ireland , japan et singapore),
  • –pattern 1-250:60 : la montée en charge sera de 1 à 250 utilisateurs, pendant une durée de 60 secondes,
  • www.woueb.net : le site ou l’application à tester.

Note : pour pouvoir réaliser un test « RUSH », il faut pouvoir démontrer à l’application qu’on est bien le propriétaire du site en ajoutant un fichier contenant 42 à la racine du serveur.

Pour les besoins de la démonstration, j’ai désactivé Varnish, APC, et Memcached que j’ai mis sur mon nouveau serveur pour un test sur 250 utilisateurs simultanés. Je sais par avance qu’Apache va tenter de répondre à toutes ces requêtes sans y arriver : voici le résultat.

Temps de réponse d'Apache par rapport à un nombre croissant d'utilisateurs simultanés

Temps de réponse d'Apache par rapport à un nombre croissant d'utilisateurs simultanés

A la fin d’un test, deux courbes sont proposées : une courbe des temps de réponses fonction du nombre d’utilisateurs, ainsi qu’une courbe des hits et timeouts fonction du nombre d’utilisateurs.

On peut diviser la première courbe (ci-dessus) en 3 parties :

  • une phase initiale (20 premières secondes) : le serveur répond normalement, les temps de réponses sont constants,
  • une phase secondaire où les temps de réponses se dégradent en augmentant,
  • la fin du test où plus aucune requêtes n’est répondue par le serveur (tracé plat).
Nombre de hits d'Apache par rapport au nombre croissant d'utilisateurs simultanés

Nombre de hits d'Apache par rapport au nombre croissant d'utilisateurs simultanés

Pour valider ce résultat, on peut visualiser les informations du serveur Apache avec le server-status.

Statut du serveur Apache pour un maximum d'utilisateurs simultanés

Statut du serveur Apache pour un maximum d'utilisateurs simultanés

On voit clairement (entouré en rouge) que tous les workers d’Apache sont utilisés : la limite en nombre de connexions simultanées est atteinte. Cela se traduit d’abord par une augmentation des temps de réponses, puis par des timeouts (les requêtes attendant que les workers se libèrent).

Maintenant, pour un second test, je réactive tout ce qu’il faut :

Et voici le résultat du même test, le résultat est bluffant. :)

Temps de réponse du blog avec Varnish / APC / Memcached par rapport à un nombre croissant d'utilisateurs simultanés

Temps de réponse du blog avec Varnish / APC / Memcached actifs

Les temps de réponses sont constants (même pour 250 utilisateurs simultanés), et presque aucun timeouts ne sont à déplorés. Blitz.io propose également un résumé du test et des conseils dans l’onglet « Highlights » (voir capture ci-dessous). Ce résumé peut vous mettre sur la piste de problèmes éventuels et vérifier quelques hypothèses.

Un résumé du résultat du test de montée en charge et des conseils sur Blitz.io

Un résumé du résultat du test de montée en charge et des conseils

Quelques commandes :

  • –tutorial : pour afficher un tutoriel (plutôt bien fait) en 7 étapes,
  • –variables : pour afficher les variables qu’il est possible d’utiliser lors d’un « blitz ».

Même si Bliz.io est disponible gratuitement, vous pouvez également payer pour étendre les fonctionnalités de test ainsi que le nombre maximum d’utilisateurs simultanés : d’après la page de paiement, on peut voir par exemple que ça vous en coutera 149$ pour une journée avec 10 000 utilisateurs simultanés (pour des tests allant jusqu’à 10 minutes).

Bon points :

  • existence d’API clientes en Java, Maven, node.js, Ruby, Python, Perl,
  • possibilité de tester des API RESTful, des sites ou des applications web,
  • jusqu’à 250 utilisateurs concurrents en version gratuite,

Mauvais points :

  • peut-être un peu cher pour pouvoir tester plus d’une minute ou avec plus que 250 utilisateurs simultanés,
  • il n’est pas possible de créer des scénarios (login sur une page, etc.).

Pour une prise en main optimale de Bliz.io, le tutoriel est vraiment bien conçu ! Bon amusement ! ;)