Deckad logo blanc

Test de charge API

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 ).

Locust start new load test

  • On peut suivre en temps réel l’avancement du test.

locust execution

locust execution 2

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 :

  1. Comportement normal
  2. Dégradation des performances (Le temps de réponse commence à croitre)
  3. Surcharge

 

Locust steps

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 logo blanc

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