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 :
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.
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 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/
2 clusters kubernetes distincts.
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
10 instances de serveur (2CPU / 7 Go de ram)
1 master
50 workers
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.
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 ).
Une fois terminé locust fournit un rapport détaillé avec les informations suivantes :
On peut observer les 3 phases :
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).
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
Pépinière CCI de la Drôme
3 rue Georges Charpak
26300 Alixan
+33 (0) 7 69 31 52 04