Tests de montée en charge avec Gatling

 

695 682. C'est le nombre de bacheliers pour cette année. Autant de personnes pouvant consulter simultanément leurs résultats sur une application. Chez Studyrama, dans le cadre du développement de l'application permettant aux bacheliers de consulter les résultats, nous avons effectué des tests de montée en charge.

Tests de montée en charge, késako ?

Il s'agit de bombarder le site web de requêtes de façon à voir sa performance sur un très grand nombre d'utilisateurs simultanés et d'identifier les points critiques.

Pour effectuer ces tests, nous avons utilisé l’outil Gatling. Développé en Scala, il permet d'enregistrer via le navigateur des "scénarios" de consultation d'un site web par un utilisateur. Ces scénarios peuvent ensuite être édités puis lancés simultanément par des milliers d'utilisateurs fictifs en ligne de commande. Un rapport nous indique les résultats de ces tests et les points à améliorer après analyse.

En fonction de la puissance de la machine, Gatling peut générer des milliers d'utilisateurs simultanés sur une même machine. Il est aussi possible de lancer un même scénario sur plusieurs machines et fusionner les résultats !

Exemple d'un scénario sur Gatling

Location des serveurs

En plus de nécessiter de bonnes machines, il faut aussi une bonne connexion pour envoyer toutes les requêtes sous peine d'être limité par la bande passante.

Nous avons loué différents serveurs sur Amazon AWS avec le compte gratuit. 5 machines du "free tier", chacune lançant jusqu'à 500 utilisateurs simultanés (soit environ 2500 utilisateurs pouvant lancer une ou plusieurs requêtes par seconde !)

Lancement des tests et analyse

Le lancement des tests s’effectue en ligne de commande. Les résultats sont enregistrés dans un fichier de log à partir duquel Gatling peut générer des graphes lisibles dans un navigateur.

Pour tester la charge, nous avons effectué des tests sur courte et longue durées. Nos premiers tests (dont le nombre d’utilisateurs s’est basé sur les statistiques de l’année dernière) n’ont montré aucun point critique. Comme le site répondait parfaitement, nous avons voulu aller jusqu’au crash. Ce dernier s’est produit au bout de 2 minutes, sur un pic de plus de 2000 requêtes par seconde. Nous avons pu identifier le point critique (le nombre de connexions maximum sur la base de données) que nous avons optimisé (augmentation du nombre de connexions). Le dernier test aura généré plus de 4 millions de requêtes (une moyenne de 900 requêtes à la seconde) dont seules quelques milliers auront échoué (2335 erreurs 500).

Résultat graphique des tests de montée en charge

 

Le jour J

Les résultats du bac général sont tombés le mardi 5 Juillet, à 10h pour les plus grandes académies, dont Paris. À ce moment, il y avait plus de 9050 utilisateurs simultanés (sur 5 minutes, soit une moyenne de 30 utilisateurs par seconde), bien moins que nos simulations. Comme estimé, le site n'a pas bronché…

Conclusion

250 000 sessions, plus d'un million de pages vues sur une journée et une application qui a tenu la charge. Ce fut une réussite du point de vue technique chez nous.

Bien sûr, effectuer des tests de montée en charge ne permet pas d'assurer à 100% que l'application fonctionnera parfaitement le jour J, mais rassure sur sa possibilité de supporter une charge donnée.

Liens

Site officiel de Gatling : http://gatling.io/

Documentation : http://gatling.io/docs/2.2.2/

 

Rattana Y et Mathieu M

Commentaires

rattana
Je tiens à préciser que Mathieu M a aussi activement participé à ce projet et à cet article.

Ajouter un commentaire