Test de charge API
Préambule
Avoir un site web ou une application rapide et réactive c’est bien, savoir combien de visiteurs vous pouvez accueillir en simultanés sur votre site, ou combien d’utilisateurs sur votre application c’est mieux, mais pourquoi ?
Dans cet article nous parlerons uniquement de la partie API (Backoffice).
Vous êtes-vous déjà demandé combien de wagons pouvait tracter une locomotive ? À partir de combien de wagons le train commence à ralentir et à partir de quand le train n’avance plus du tout ?
On va faire l’analogie suivante :
- Locomotive = Site internet / Application
- Wagon = Visiteur sur le site
La seule manière de savoir est de tester en ajoutant des wagons à notre locomotive et suivre son comportement.
Les utilisateurs sur internet sont très volatils et vont voir ailleurs dès qu’un site ou une application est lente.
Faire un test de charge permet de connaitre les limitations des applications et des sites pour anticiper les pics d’activités.
Il ne faut pas sous-estimer les tests de charge ni les ressources nécessaires pour les réaliser.
L’objectif
Stresser l’API de notre application afin d’identifier les points de contention.
Récupérer des valeurs clés à surveiller pour notre supervision :
la limite maximum de requêtes en simultanées à partir de laquelle les performances se dégradent.
la limite maximum de requêtes en simultanées à partir de laquelle l’application ne répond plus.
Locust en quelques mots
Locust est un outil qui permet d’effectuer des tests de charge d’api.
Il utilise des scénarios qui sont rédigés en python et une interface web qui permet de lancer et consulter les résultats des scénarios.
Locust est capable de simuler autant d’utilisateurs qu’on désire dans la limite des ressources qu’on lui met à disposition.
Il fonctionne avec des workers à qui il délègue des tâches à exécuter.
Site officiel de locust : https://locust.io/
Notre environnement
2 clusters kubernetes distincts.
1 cluster dédié pour l’application
API en nodejs avec expressjs (docker)
Base de données postgresql haute disponibilité (docker) + pgpool (docker)
En chiffre :
20 instances de serveur (2CPU / 7 Go de ram)
60 instances d’API
20 connexions au pgpool de base de données par instance d’API (soit 1200 connexions)
4 pgpool
440 connexions par pgpool par base de données (soit 1760 connexions)
2 nœuds de base de données PostgreSQL
2000 connexions disponibles par nœud PostgreSQL
1 cluster dédié pour locust
10 instances de serveur (2CPU / 7 Go de ram)
1 master
50 workers
Le scénario
Le but du scénario est de simuler un utilisateur.
Voici notre scénario :
Authentification
Chargement des données de l’utilisateur
Récupération d’une liste de données de type1 (jusqu’à 5000 entrées)
Récupération d’une liste de données de type2 (jusqu’à 5000 entrées)
Récupération d’une liste de données de type3 (jusqu’à 5000 entrées)
Récupération d’une liste de données de type4 (jusqu’à 5000 entrées)
Récupération d’une liste de données de type5 (jusqu’à 5000 entrées)
En réalité un utilisateur ne fera pas toutes ses requêtes aussi rapidement mais cela reste une simulation.
Le but n’est pas d’identifier le nombre d’utilisateurs simultanés mais le nombre de requêtes simultanées.
Il est important d’avoir des utilisateurs différents pour ne pas fausser les performances avec des données mises en cache.
Exécution des tests
Pour lancer un test on ouvre l’interface web de locust
On saisit :
Le nombre d’utilisateurs à simuler : 100.
L’évolution de la croissance du nombre d’utilisateurs dans le temps ( +1 utilisateur par seconde ).
- On peut suivre en temps réel l’avancement du test.
Rapport de test
Une fois terminé locust fournit un rapport détaillé avec les informations suivantes :
- Tableaux
- Nombre de requêtes (ok, ko, min, max, moyenne, ko par seconde et ratio d’exécution)
- Temps de réponse (en percentiles 50, 60, 70, 80, 90, 95, 99 et 100)
- Nombre de Requêtes en erreur (Avec le nombre d’apparitions)
- Graphiques
- Nombre de requêtes par seconde
- Temps de réponse
- Nombre d’utilisateurs
Analyse du rapport
On peut observer les 3 phases :
- Comportement normal
- Dégradation des performances (Le temps de réponse commence à croitre)
- Surcharge
Conclusion
En l’état notre application supporte aisément 200 utilisateurs (de tests) en simultanés.
Pour être honnête, au vu des ressources allouées je m’attendais à bien mieux et c’est là où c’est intéressant et très important (après analyse nous avons identifié 2 améliorations significatives, une première sur la configuration sur pgpool et une seconde sur la configuration des pools de connexions dans le Core de l’application).
Que faire ensuite ?
Identifier les points de contention.
Est-ce l’api (consommation CPU / mémoire), pgpool (pool d’accès à la base de données) ou la base de données qui atteint sa limite ?
Mettre en place une supervision pour prévenir à l’approche des seuils.
Mettre en place un scalling automatique (montée à l’échelle automatique) des briques de l’application, mais ça c’est un autre sujet.
Deckad est une société experte dans le développement de solution numérique pour les entreprises. Retrouvez nous sur les réseaux sociaux
Nos produits
Nous contacter
Adresse
Pépinière CCI de la Drôme
3 rue Georges Charpak
26300 Alixan
Numéro
+33 (0) 7 69 31 52 04