Test de montée en charge d’un site web ou d’une API avec Blitz.io
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
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
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
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
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
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
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 :
- APC pour booster les performances d’Apache,
- Memcached pour la mise en cache d’objets,
- Varnish en reverse-proxy / solution de cache.
Et voici le résultat du même test, le résultat est bluffant.
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
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 ! 
Commentaire by Johan — 7 septembre 2011 @ 14:01
J’avais fait un test du service cet été également et je l’avais également adoré… Le tien est plus poussé au niveau technique et ça montre l’intéret de Varnish…
Sinon tu cites comme mauvais point : « peut-être un peu cher pour pouvoir tester plus d’une minute ou avec plus que 250 utilisateurs simultanés ».
A cela je répond, il faut bien vivre… Et j’ajoute, il y a un système d’affiliation qui permet d’augmenter le nombre de users pour un compte gratuit et à priori tu l’as vu…
Personnellement, j’ai fait un article, j’ai eu droit à 250 users « offerts » en plus et avec l’affiliation j’ai droit à 175 users en plus. Au final je peux tester jusqu’à 675 users gratuitement pendant une minute.
Voila !
Commentaire by Romain — 7 septembre 2011 @ 14:25
@Johan > Je comprends bien qu’il faut vivre, mais je m’attendais pas à « autant ».
J’ai dit que c’était « un peu » cher, donc pour moi ça reste quand même du domaine du raisonnable…
Commentaire by Nicolargo — 7 septembre 2011 @ 16:04
Merci pour cet article très complet !
Concernant Varnish, il est clair que le gain est assez impressionnant pour les sites à fort trafic.
Effet collatéral, j’ai pu valider la supervision (via Shinken) des attaques DDOS sur mon site fonctionnait bien
Commentaire by Romain — 7 septembre 2011 @ 16:18
@Nicolargo > Ah oui ?
Tu feras un article ? ^^
Commentaire by michou — 7 septembre 2011 @ 18:00
Avec cloudflare.com j’ai pu encaisser près de 3500 mecs simultanés bande de petits joueurs ^^
Commentaire by Cybervince — 7 septembre 2011 @ 18:13
Sympa comme service.
Ca m’a clairement permis de voir les limites de mon hébergement mutualisé. Mais jusqu’à présent, même lors de forts pics d’activité, mon site a toujours tenu le coup (car bon, même quand il y a 200 personnes qui visitent un site en même temps, ils ne balancent pas leurs requêtes pile à la même seconde).
Commentaire by kowsik — 7 septembre 2011 @ 21:52
Awesome blog and thanks for writing about http://blitz.io. In return, we’ve given you a one-time +250 blogging credit so you can rush up to 500 concurrent users. You can earn more with referrals too!
Thanks,
@pcapr
Ping by Test de montée en charge d’un site web ou d’une API avec Blitz.io by Romain DECKER | Le Blog des Gens Tranquilles — 13 septembre 2011 @ 13:48
[...] Test de montée en charge d’un site web ou d’une API avec Blitz.io « wOueb by Romain DECKER / A…. [...]
Commentaire by olivier clémence — 15 septembre 2011 @ 7:31
Merci pour cet article, blitz semble être assez génial je vais le tester et j’ai également découvert APC, va falloir que j’étudie ça !
Commentaire by Mike Orpheus — 6 décembre 2011 @ 16:27
Hi everybody,
Je vous invite tous à decouvrir un nouvel outil « CloudNetCare » http://www.cloudnetcare.com
Franchement c’est un superbe outil, peut-être le meilleur actuellement sur le marché !!!
Il a tout! Simple d’utilisation de multiples services annexes, des prix pour les PME exemple 1er Pack à 39,90€ pour 1000 tests et pour les grands comptes !
Il y du free donc testez le ………..
Best regards
Mike
Commentaire by Soul — 11 mars 2012 @ 18:27
Bien sympa, je connaissais pas l’outil, merci.
Ping by 4h18 - Optimiser son serveur pour wordpress — 26 mai 2012 @ 21:25
[...] de Nginx comme proxy, l’article date de 2009 mais tient toujoursRomain Decker, une solution gratuite pour tester la montée en charge de votre serveurQuentinZone, un tuto pour déplacer ses images vers un sous domaine Retour en haut ↑ « [...]