For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/public-cloud/ai-machine-learning/ai-deploy-load-test-app.md.

AI Deploy - Tutoriel - Tester la charge de votre application avec Locust

Voir en Markdown

Découvrez comment tester facilement vos API et trouver leurs limites

Info

AI Deploy est couvert par les Conditions particulières OVHcloud Public Cloud.

Objectif

L’objectif de ce tutoriel est de tester la charge de vos applications déployées, en interrogeant progressivement vos API avec un outil de test de charge. Généralement, votre défi consiste à anticiper vos besoins en calcul, par exemple combien de CPU ou de GPU seront nécessaires pour 1000 appels API par heure, avec une latence acceptable.

Il existe plusieurs applications permettant de simuler le nombre d’utilisateurs et de requêtes que vous pourriez avoir à gérer.

Dans ce tutoriel, nous en utiliserons une et interpréterons les résultats.

Prérequis

  • Un projet Public Cloud dans votre compte OVHcloud.
  • Une app avec une API en cours d’exécution sur AI Deploy, dans votre projet Public Cloud.
  • Un environnement Python, avec suffisamment de CPU et de RAM ainsi qu’un accès internet (une machine virtuelle est recommandée).

Accès à l'espace client OVHcloud

  • Lien direct :
  • Pour accéder à vos services : Public Cloud > Sélectionnez votre projet

Choisir le bon outil de test de charge pour vos besoins

Selon votre langage de programmation préféré et le temps que vous souhaitez consacrer à ce sujet, plusieurs options s’offrent à vous.

Vous pouvez d’abord opter pour un outil de test de charge SaaS, tel que Gatling.io ou K6.io. Rien à installer, facile à démarrer.

Une deuxième option consiste à utiliser des outils de test de charge open source. Certains sont uniquement en ligne de commande, comme hey ou Wrk2, d’autres proposent une interface web comme Locust.

Il est essentiel de choisir le bon outil pour le bon test. Pour la suite, nous choisirons et utiliserons Locust, qui nous permet d’afficher des graphiques visuels.

En pratique

Déployer une app avec une API REST

N’hésitez pas à déployer l’app et l’API de votre choix pour tester la charge, tant que vous pouvez l’interroger via des requêtes REST.

Pour ce tutoriel, nous allons tester la charge d’une API de classification de spam issue du portfolio d’apps AI Deploy. Cette API prend en entrée des phrases (e-mails) sous forme de texte, et renvoie un score de probabilité de spam.

Vous pouvez déployer cette API facilement depuis l’ ou la CLI OVHcloud. Une bonne stratégie consiste à déployer avec l’autoscaling, avec un nombre minimum et maximum de réplicas. Nous pourrons ainsi surveiller l’évolution du nombre de réplicas utilisés.

Voici la commande CLI utilisée pour la déployer, avec un autoscaling allant de 1 à 5 réplicas et un seuil CPU de 75 % :

ovhai app run --name spamclassifier --cpu 1 \
--auto-min-replicas 1 \
--auto-max-replicas 5 \
--auto-resource-type CPU \
--auto-resource-usage-threshold 75 \
priv-registry.gra.ai.cloud.ovh.net/ai-deploy-portfolio/fastapi-spam-classification

Vérifier que votre API fonctionne bien avec cURL

Info

Pour pouvoir vous connecter à votre app AI Deploy, vous devez créer un token bearer pour votre utilisateur AI OVHcloud.

Une fois déployée, testons d’abord notre API avec une simple commande cURL. Voici la commande à essayer dans un terminal :

curl -s -X POST \ 
"<api_url>/spam_detection_path \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"message":"This is a test from my machine"}' | jq

Voici le résultat renvoyé par notre appel :

{
  "label": "ham",
  "label_probability": 0.9875114695528484
}

Quelques explications sur les lignes ci-dessus :

  • Sur la première ligne, nous précisons que nous allons utiliser une méthode POST.
  • Nous précisons l’URL où la requête POST sera exécutée. L’api_url est l’URL de votre API. Elle devrait ressembler à : https://baac2c13-2e69-4d0f-ae6b-dg9eff9be513.app.gra.ai.cloud.ovh.net/.
  • Nous ajoutons le token permettant d’accéder à notre API, généré via l’espace client OVHcloud ou la CLI ovhai. Nous le précisons dans l’en-tête de la requête. Si vous souhaitez en savoir plus sur la génération et l’utilisation des tokens, vous pouvez suivre ce tutoriel.
  • Nous précisons que notre corps de requête est au format JSON.
  • Nous plaçons dans le corps de la requête le message que nous souhaitons envoyer au classificateur de spam. Dans votre cas, le corps pourra être différent, car cela dépend de l’API. Notre objectif est que le classificateur de spam nous renvoie la probabilité de chaque réponse. La dernière instruction | jq nous permet d’avoir un bel affichage du résultat dans le terminal.

Nous avons maintenant la confirmation que notre API fonctionne, essayons de tester sa charge.

Nous allons simplement simuler plusieurs commandes curl. Avec l’outil Locust, nous pouvons simuler plusieurs utilisateurs et définir un nombre d’appels par minute vers l’API. Cela peut se faire facilement avec l’interface de Locust. Mais avant d’utiliser cette interface, nous devons lancer Locust et configurer l’outil. Cela peut se faire facilement avec Python.

Installer locust.io

Locust est un package Python open source que vous pouvez installer en une ligne de code. Suivez leur documentation officielle :

pip3 install locust

Vous pouvez l’installer sur votre ordinateur personnel, mais gardez à l’esprit que les outils de test de charge nécessitent quatre éléments pour ne pas devenir le goulot d’étranglement de votre test de charge :

  • Suffisamment de calcul (CPU).
  • Suffisamment de mémoire (RAM).
  • Une connectivité à faible latence vers votre API.
  • Aucun « voisin bruyant », c’est-à-dire aucun logiciel installé pouvant compromettre vos résultats. Imaginez que la puissance de votre CPU soit utilisée par du rendu vidéo, cela biaisera vos résultats.

Pour toutes ces raisons, une instance Public Cloud est recommandée, comme une machine virtuelle de taille moyenne. Pour ce tutoriel, nous utiliserons une instance OVHcloud B2-30.

Configurer Locust

Pour configurer le logiciel, vous devez créer un fichier nommé locustfile.py. Dans ce fichier, vous pouvez indiquer le chemin où vous souhaitez effectuer votre requête, les en-têtes de votre requête, le type de requête (POST, GET, etc.) et le corps si vous souhaitez en ajouter un à la requête.

Un fichier générique ressemblera à ceci :

from locust import HttpUser, task

class HelloWorldUser(HttpUser):
    @task
    def hello_world(self):
        self.client.get("/hello")
        self.client.get("/world")

Pour notre API et nos besoins, le fichier locust sera légèrement modifié :

# Import the Locust dependencies
from locust import HttpUser, task

# Import general library from python
import os
import random

# Import lorem ipsum library to generate some random texts
from lorem_text import lorem

# Import dotenv to load the environments variables
from dotenv import load_dotenv
load_dotenv()

# Create a table with some lorem ipsum texts
messages = []

# Add 1000 random texts of 10 paragraphs each (simulate 1000 emails)
for i in range(1000):
    messages.append(lorem.paragraphs(10))

# Define the headers of the request. Token is stored as an environment variable here
headers = {
    "Authorization": "Bearer {os.getenv('TOKEN')}", "Content-Type": "application/json"}

class HelloWorldUser(HttpUser):
    # Definition of the first path where we do our post request
    @task
    def hello_world(self):
        # Define the body with the email choose randomly from the tab of all the emails
        body = {"message": random.choice(messages)}
        # Do the post request on the spam detection path
        self.client.post("/spam_detection_path",
                         headers=headers, json=body)

Pour vos propres besoins, vous devrez modifier le chemin, les en-têtes et le corps, car ces paramètres changent d’une API à l’autre.

Une fois votre locustfile.py prêt, ouvrez l’interface web de Locust sur [http://your_IP:8089](http://your_IP:8089).

L’interface web devrait ressembler à ceci :

Interface web de Locust avec le formulaire Start new load test comprenant les champs Number of users Spawn rate et Host et le bouton Start swarming avec le statut READY

Lancer vos tests de charge

Vous disposez maintenant de votre app en cours d’exécution sur OVHcloud, et Locust est configuré. Simulons quelques appels utilisateurs.

Depuis l’interface web, renseignez le nombre d’utilisateurs simultanés (appels API) et le pas d’incrémentation (taux d’apparition).

Pour ce tutoriel, nous ajouterons 480 utilisateurs au total, avec un taux d’apparition de 2 utilisateurs ajoutés par seconde. Nous simulerons cela sur une durée de 4 minutes. Nous supposons que ce cas correspond à un afflux soudain sur l’API. La plupart du temps, on peut supposer qu’il n’y a pas autant d’utilisateurs sur la plateforme.

Lancez le test.

Interpréter les résultats via Locust

À la fin du test de charge, vous verrez ce résumé rapide :

Onglet Statistics de Locust affichant la ligne POST /spam_detection_path avec 128060 requêtes 53 échecs une médiane de 260 ms une moyenne de 442 ms un maximum de 7477 ms et 805.7 requêtes par seconde avec 0% d'échecs

Si nous souhaitons obtenir plus de détails sur notre test, nous pouvons consulter les graphiques fournis par Locust dans l’onglet charts. Voici ce que l’on peut observer :

Onglet Charts de Locust affichant Total Requests per Second qui augmente par paliers jusqu'à environ 800 sans échec et Response Times qui monte à environ 2500 ms au 95e centile alors que la médiane reste basse

Nous avons déployé cette API de 1 à 5 réplicas, avec 1 CPU pour chacun, complété par l’autoscaling. On peut voir que notre API a été légèrement surchargée. En effet, sur les graphiques comme dans le résumé rapide, on observe quelques échecs. Ces échecs sont dus à des erreurs serveur. On peut supposer que nous avons atteint certaines limites matérielles à un moment donné, par exemple avant de monter en charge vers un plus grand nombre de réplicas.

On peut également observer une latence d’appel qui augmente avec le temps. Au final, on peut s’attendre à plus de 3 secondes par appel.

L’interprétation des résultats peut dépendre de vos besoins et de vos critères de performance. Nous pouvons bien sûr effectuer un nouveau test avec davantage d’utilisateurs pour observer les limites de nos API, et ajouter plusieurs tâches dans le locustfile.py.

Une chose n’est pas visible ici : le scaling du backend OVHcloud. Nous avons déployé notre app avec l’autoscaling, d’un minimum de 1 réplica à un maximum de 5. Les avons-nous utilisés ? Ont-ils été utiles et à pleine capacité ?

Voyons ces mêmes résultats en détail avec l’outil de monitoring d’AI Deploy.

Interpréter les résultats avec le monitoring AI Deploy

Rendez-vous dans l’espace client OVHcloud et accédez au détail de votre application déployée. Cliquez sur le bouton Accéder au tableau de bord.

Ce dashboard est fourni gratuitement dans AI Deploy, pour chaque application déployée. Toutes les apps déployées sont regroupées dans un dashboard Grafana unique.

Vous pouvez sélectionner l’app déployée en haut de ce dashboard Grafana, comme illustré ci-dessous :

Tableau de bord Grafana App Monitoring avec le sélecteur d'application en haut et les panneaux Resource usage pour GPU Usage GPU Memory Usage CPU Usage Memory Usage Network Usage Ephemeral storage usage Volumes Total Size Volumes Total File Count et une section HTTP

Avec ce dashboard, vous pouvez voir le pourcentage de CPU utilisé en temps réel, la latence HTTP de votre API, l’autoscaling de l’app, la bande passante réseau et bien plus encore. Les barres verticales bleues indiquent les événements de scaling.

Voici le résultat pour la charge CPU, globalement (tous réplicas confondus) :

Panneaux Grafana Resource usage pendant le test de charge avec CPU Usage culminant près de 60% puis redescendant et les panneaux Memory Usage Network Usage et Ephemeral storage usage à côté avec des barres bleues verticales marquant les événements de scaling

On constate que notre app a scalé à plusieurs reprises et n’a pas atteint sa capacité maximale, grâce à l’autoscaling. Regardons maintenant la latence de notre application :

Panneaux Grafana Volumes et HTTP avec HTTP Call Latency au 95e centile se stabilisant autour de 750 ms puis culminant au-delà de 1.5 s et HTTP Call Count montant à environ 280 appels avant de retomber à zéro

On voit ici que la latence a augmenté progressivement, puisque nous avons un taux d’apparition de deux nouveaux utilisateurs par seconde. La latence de l’API était stable autour de 750 ms, puis a atteint un pic à 1,5 s.

Là encore, l’interprétation dépendra de vos besoins. Devons-nous fournir plus de CPU parce que la latence est trop élevée ? Cette question variera selon les besoins de vos clients. Pour un anti-spam, ajouter 1 seconde est considérable pour une entreprise recevant des milliers d’e-mails par jour, mais peu gênant s’il s’agit d’une douzaine par jour. Regardons maintenant le scaling de notre application :

Panneaux Grafana Auto-scaling montrant Running replicas passant de 1 à 4 pour un maximum de 5 un Usage target de 75% et les courbes CPU Usage et Memory Usage par réplique pour les répliques 9nwqj d2dwf dtz8c et zd2ln

On constate que le seuil a été plafonné à 75 % pour l’autoscaling, et que celui-ci a été respecté. Sur les 5 réplicas fournis à l’application, 4 ont été utilisés.

En conclusion, Locust et le monitoring AI Deploy sont tous deux utiles pour interpréter les résultats, mais, plus que les outils, l’essentiel est de définir des charges de travail et des critères de performance réalistes.

Dernier point : alors que Locust mesure une latence de bout en bout (depuis la machine virtuelle Locust ici, jusqu’au modèle API déployé), le monitoring AI Deploy ne mesure que la latence du backbone (de la requête à la réponse). C’est pourquoi les valeurs de latence sont plus élevées du côté de Locust, atteignant 2,5 secondes.

Aller plus loin

Documentation officielle de Locust : Locust.io

Comparaison des outils de test de charge : Comparison of load testing tools

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Votre avis nous intéresse !

N’hésitez pas à nous faire part de vos questions, retours et suggestions pour améliorer le service :

Cette page vous a-t-elle aidé ?