Vous voulez savoir ce qu'il advient de votre API lorsque 80 personnes cliquent sur "commander" en même temps. Vous ouvrez donc Locust, et la première chose qu'il vous demande de faire est d'écrire une classe Python. Définir un HttpUser. Décorer les méthodes avec @task. Construire un locustfile.py, mettre en place un environnement virtuel, épingler quelques dépendances, puis comprendre pourquoi votre jeton d'authentification n'est pas réutilisé entre les requêtes. Rien de tout cela n'est le test. C'est le coût d'entrée avant que le test ne commence.
Locust est un excellent outil, et cette conception "code-first" est son objectif. Mais si votre but est une réponse simple à la question "mon point de terminaison de connexion tient-il à 100 utilisateurs concurrents", écrire et maintenir un harnais Python est beaucoup d'effort pour un seul chiffre. Il existe un chemin plus rapide lorsque les requêtes API que vous voulez soumettre se trouvent déjà dans un client API. Avec Apidog, vous pointez un test de performance vers un scénario de test existant, définissez le nombre d'utilisateurs virtuels et une durée, et lisez le débit, le temps de réponse et le taux d'erreur sur un graphique en direct. Pas de locustfile, pas de pip install, pas de Python du tout.
Ce que Locust fait réellement bien
Locust est un outil de test de charge open-source écrit en Python, et il est bon pour ce pour quoi il a été conçu. Vous décrivez le comportement de l'utilisateur comme du code. Un utilisateur virtuel est une classe Python, et les actions que cet utilisateur effectue sont des méthodes que vous étiquetez comme des tâches. Voici la forme canonique d'un locustfile.py :
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
Vous l'exécutez avec locust -f locustfile.py, ouvrez l'interface web à localhost:8089, définissez un nombre d'utilisateurs et un taux d'apparition, et regardez les chiffres augmenter. Parce que le comportement est du code, vous obtenez une réelle puissance expressive. Logique conditionnelle, distributions de tâches pondérées, parcours utilisateur séquentiels, clients personnalisés pour des protocoles au-delà de HTTP, état partagé entre les requêtes. La pondération @task(3) par rapport à @task(1) ci-dessus signifie que la navigation se produit trois fois plus souvent que l'ajout au panier, ce qui est le genre de réalisme qu'une liste de requêtes plate ne peut pas capturer.
Locust s'adapte également horizontalement. Exécutez-le distribué sur plusieurs processus ou machines de travail et un seul maître les coordonne, afin de pouvoir dépasser ce qu'une seule machine peut générer. Il est basé sur les événements, de sorte que chaque travailleur gère des milliers d'utilisateurs concurrents sans qu'un thread par utilisateur ne consomme de mémoire. Pour une équipe qui vit déjà en Python, qui traite ses tests de charge comme du code versionné et qui a besoin de modéliser des comportements utilisateur complexes en plusieurs étapes, Locust est un excellent choix. Rien de tout cela n'est contesté.
Le coût est le code. Chaque test est un programme que vous écrivez, déboguez et maintenez. Si votre API change, le locustfile change. Si un nouvel ingénieur doit exécuter le test, il a besoin d'un environnement Python correspondant. Et si vous n'écrivez pas déjà en Python, le langage lui-même devient un prérequis pour répondre à une question qui n'a rien à voir avec Python.
Où le modèle "code-first" devient une friction
La friction apparaît à trois niveaux.
Premièrement, la configuration. Avant de mesurer quoi que ce soit, vous installez Python, créez un environnement virtuel, pip install locust, et écrivez le harnais. Pour une vérification rapide "ce point de terminaison peut-il gérer 50 utilisateurs", c'est plus de plomberie que de charge utile.
Deuxièmement, la duplication. Vous avez probablement déjà défini ces requêtes quelque part. Peut-être dans Postman, peut-être dans un fichier .http, peut-être dans un client API que votre équipe utilise tous les jours. Le locustfile redécrit des requêtes qui existent déjà, y compris le flux d'authentification, les en-têtes, les corps de requête. Maintenant, vous maintenez deux copies de la même connaissance API, et elles divergent.
Troisièmement, les personnes qui ont besoin de la réponse. Un ingénieur QA, un chef de produit qui s'inquiète d'un lancement, ou un développeur frontend qui veut juste savoir si l'API survit à l'e-mail marketing ont tous besoin du résultat du test de charge. Ils n'ont pas nécessairement besoin de lire ou d'écrire en Python pour le mériter. Lorsque le test est bloqué derrière un locustfile, la réponse est bloquée derrière un ensemble de compétences.
Si vos tests de charge nécessitent réellement une logique de branchement et des clients de protocole personnalisés, cette friction vaut la peine d'être payée et Locust est le bon outil. Pour le cas courant de "exécuter mes vraies requêtes API sous charge concurrente et me montrer les chiffres", il vaut la peine de se demander si la couche Python vous apporte quelque chose.
L'approche Apidog : tester la charge des requêtes que vous avez déjà
Apidog aborde les tests de charge dans l'autre sens. Vous n'écrivez pas un script qui décrit des requêtes. Vous prenez des requêtes que vous avez déjà construites et vous les exécutez sous charge. L'unité d'un test de charge est un scénario de test, qui est simplement un ensemble ordonné de requêtes API avec leurs environnements, variables et assertions déjà attachés. Si vous avez utilisé Apidog pour tester ou déboguer un point de terminaison, la requête est déjà là. Le test de performance la réutilise.
Voici le flux complet.
- Ouvrez le scénario de test que vous souhaitez tester en charge. Il s'agit du même scénario que vous exécuteriez comme un test fonctionnel normal, avec les mêmes requêtes et les mêmes variables d'environnement.
- Choisissez de l'exécuter comme un test de performance plutôt que comme un seul passage.
- Définissez le nombre d'utilisateurs virtuels. Apidog prend en charge jusqu'à 100 utilisateurs virtuels, chacun parcourant chaque requête du scénario en parallèle pendant toute la durée du test.
- Définissez la durée du test. C'est la durée pendant laquelle les utilisateurs virtuels continuent de boucler.
- Définissez une durée de montée en charge si vous souhaitez une augmentation progressive. Pendant les X premières minutes, Apidog met les utilisateurs en ligne de manière incrémentielle plutôt que tous en même temps ; réglez-le sur 0 et chaque utilisateur virtuel démarre immédiatement.
- Si votre scénario est basé sur des données, choisissez un mode de correspondance. "Correspondance aléatoire" fait en sorte que chaque utilisateur virtuel tire une ligne aléatoire de vos données de test à chaque boucle ; "Correspondance séquentielle" parcourt les lignes dans l'ordre.
- Démarrez le test et surveillez le panneau en direct.
Le graphique se met à jour en temps réel. Pour chaque API du scénario, vous obtenez le nombre total de requêtes, le débit moyen, le temps de réponse moyen, le temps de réponse maximal et minimal, et les erreurs. Survolez le graphique pour voir les chiffres pour une tranche de temps donnée. Un onglet "Erreur" décompose les requêtes échouées afin que vous puissiez voir quel point de terminaison a commencé à flancher et quand. Lorsque l'exécution est terminée, l'onglet "Rapports de test" conserve l'historique afin que vous puissiez comparer l'exécution d'aujourd'hui à celle de la semaine dernière après avoir livré un changement.
Tout l'intérêt est qu'il n'y a pas de locustfile à écrire et pas d'environnement Python à gérer. La même requête qui a passé votre test fonctionnel est la requête qui génère la charge. C'est la différence entre décrire un test de charge et en exécuter un. Apidog est une plateforme API tout-en-un, de sorte que la conception, le débogage, les tests fonctionnels et les tests de charge d'un point de terminaison se déroulent tous à partir d'une seule définition de ce point de terminaison.
Une comparaison concrète
Supposons que vous souhaitiez confirmer qu'un point de terminaison de connexion gère 100 utilisateurs concurrents pendant deux minutes, avec une montée en charge de 30 secondes.
Dans Locust, vous écrivez une classe utilisateur avec une tâche qui publie les identifiants, gère le jeton renvoyé par la réponse, le stocke pour les appels de suivi, enregistrez le fichier, démarrez locust -f login_test.py, ouvrez l'interface web, et entrez 100 utilisateurs, un taux de spawn et une durée d'exécution. Si la gestion du jeton est incorrecte, vous déboguez Python avant de déboguer votre API.
Dans Apidog, vous ouvrez le scénario de test de connexion que vous avez déjà construit, le basculez en test de performance, tapez 100 pour les utilisateurs virtuels, 2 minutes pour la durée, 30 secondes pour la montée en charge, et le démarrez. L'authentification qui fonctionnait déjà dans votre test fonctionnel fonctionne toujours, car c'est le même scénario. Vous lisez la courbe du temps de réponse et le taux d'erreur au fur et à mesure qu'ils se produisent.
Les deux aboutissent au même type de réponse. L'un vous demande d'abord d'écrire et de maintenir un programme. L'autre réutilise ce que vous avez déjà. Pour les parcours utilisateur complexes, modélisés par code, le programme en vaut la peine. Pour la question "mon point de terminaison est-il rapide et stable sous charge", la réutilisation l'emporte sur le temps.
Limites honnêtes des deux côtés
Soyez lucide sur les compromis, car choisir le mauvais outil vous fera perdre une journée de toute façon.
Les tests de performance d'Apidog se limitent à 100 utilisateurs virtuels pour une seule exécution, et la charge est générée depuis votre machine exécutant l'application. Si vous devez simuler des dizaines de milliers d'utilisateurs ou générer de la charge depuis plusieurs régions géographiques à la fois, cela dépasse les capacités du test de performance intégré à l'application, et une configuration distribuée comme les workers Locust ou un cluster dédié de génération de charge est le bon choix. Apidog enregistre également les requêtes échouées de manière statistique plutôt que de capturer le corps complet de la requête et de la réponse pour chaque échec, donc un débogage forensique approfondi d'un appel échoué spécifique en pleine charge n'est pas sa force.
Le compromis de Locust est celui dont parle tout cet article. La puissance vient du code, et le code est un coût permanent. Vous maintenez un locustfile par scénario, gardez un environnement Python, et acceptez que quiconque souhaite exécuter le test doive lire du Python pour le comprendre. Pour un très grand nombre d'utilisateurs virtuels et une logique de protocole sur mesure, ce coût vous rapporte quelque chose de réel. Pour la vérification quotidienne de la charge API, c'est une surcharge.
Une règle raisonnable : si vous pouvez décrire le test comme "exécuter ces requêtes à cette concurrence pendant cette durée", optez pour le test de performance intégré à l'application. Si vous avez besoin de logique de branchement conditionnel, de graphes de tâches pondérés, de clients personnalisés ou de plus de six chiffres d'utilisateurs, optez pour le code. Pour une étude plus large de l'adéquation de chaque option, consultez notre récapitulatif des meilleurs outils de test de charge et la comparaison des outils de test de charge spécifiques aux API.
Lire les chiffres que vous obtenez en retour
Un test de charge n'est utile que si vous savez ce que signifie le résultat. Quatre métriques portent l'essentiel du poids.
Le débit (RPS/TPS) est le nombre de requêtes ou de transactions par seconde, le taux réellement servi par votre API. C'est le plafond de ce que votre système peut gérer. Si le débit se stabilise alors que vous continuez d'ajouter des utilisateurs virtuels, vous avez trouvé un point de saturation.
Le temps de réponse (latence) est le temps que chaque requête a pris. Surveillez la moyenne, mais surveillez le maximum encore plus attentivement. Une moyenne saine avec un maximum affreux signifie que certains utilisateurs ont une mauvaise expérience même si la plupart vont bien. La latence de queue est là où les vrais utilisateurs ressentent la douleur.
Le taux d'erreur est la proportion de requêtes qui ont échoué. Un test propre à faible charge qui commence à générer des 500 ou des timeouts à mesure que les utilisateurs virtuels augmentent vous indique exactement où le système tombe en panne. Le point où les erreurs commencent est souvent plus intéressant que le chiffre brut du débit.
La concurrence est le nombre d'utilisateurs virtuels actifs. Dans Apidog, c'est le nombre d'utilisateurs virtuels que vous définissez, et la montée en charge contrôle la vitesse à laquelle vous y arrivez. La montée en charge est importante car un système qui gère 100 utilisateurs atteints progressivement peut quand même tomber en panne si les 100 arrivent en même temps.
Si vous souhaitez une version plus approfondie de ceci, notre guide sur les tests de performance API explore les métriques, les types de tests et comment lire les courbes, et l'article sur les fondamentaux des tests de performance couvre la discipline plus largement.
Comment cela s'intègre aux outils auxquels vous vous comparez déjà
Si vous avez utilisé JMeter, le modèle mental est similaire à celui d'Apidog, car les deux vous permettent de configurer un test de charge via une interface utilisateur plutôt que du code. JMeter l'échange contre un plan de test plus lourd basé sur XML et une courbe d'apprentissage plus raide ; notre tutoriel de test de charge JMeter le couvre en détail. Si vous avez exécuté une charge via le collection runner de Postman, vous avez vu une version plus légère de la même idée, couverte dans le test de charge avec Postman, et Apidog ajoute des rapports de performance dédiés en plus des requêtes que vous pouvez également utiliser pour les tests API sans Postman. Apidog se situe entre la simplicité sans code que les gens désirent et la réutilisation des requêtes qui vous évite de maintenir un harnais séparé.
Le fil conducteur de tous est que votre test de charge devrait réutiliser les connaissances API que vous avez déjà encodées, et non les dupliquer dans un nouveau langage. Locust les duplique en Python parce que Python est sa force. Apidog réutilise vos scénarios parce que la réutilisation est sa force.
Pour commencer
Si vos requêtes se trouvent déjà dans Apidog, vous pouvez lancer un test de performance dans les cinq minutes. Ouvrez un scénario de test, basculez-le en test de performance, définissez le nombre d'utilisateurs virtuels et la durée, puis démarrez-le. Si vous utilisez un locustfile et que vous êtes fatigué de maintenir la couche Python, reconstruisez le scénario une seule fois dans l'application et vous n'écrirez plus de code de test de charge pour ce point de terminaison.
Téléchargez Apidog et pointez un test de performance vers un point de terminaison que vous testez déjà. Vous aurez les courbes de débit, de latence et de taux d'erreur avant d'avoir terminé d'écrire le locustfile équivalent. Locust reste la bonne solution pour la charge distribuée et modélisée par code à grande échelle. Pour la question que la plupart des développeurs se posent réellement, exécutez les requêtes que vous avez déjà.
FAQ
Apidog est-il un remplacement direct de Locust ?
Pas pour toutes les tâches. Pour les tests de charge d'API jusqu'à 100 utilisateurs virtuels sans écrire de code, Apidog remplace l'ensemble du flux de travail de Locust car il exécute directement vos scénarios de test existants. Pour la charge distribuée avec un très grand nombre d'utilisateurs ou les protocoles non-HTTP personnalisés modélisés en code, Locust reste le meilleur choix.
Dois-je écrire du code pour effectuer des tests de charge dans Apidog ?
Non. Vous configurez les utilisateurs virtuels, la durée du test et le temps de montée en charge dans l'interface utilisateur, et le test exécute les requêtes à partir d'un scénario de test que vous avez déjà construit. Il n'y a pas de locustfile ni d'environnement Python à configurer.
Combien d'utilisateurs virtuels Apidog peut-il simuler ?
Jusqu'à 100 utilisateurs virtuels dans un seul test de performance. Chacun d'eux parcourt chaque API du scénario en parallèle pendant la durée que vous avez définie. Si vous avez besoin de beaucoup plus que cela ou d'une charge provenant de plusieurs régions, un outil distribué basé sur le code comme Locust est le bon choix.
Quelles métriques le test de performance Apidog rapporte-t-il ?
Pour chaque API du scénario, vous obtenez le nombre total de requêtes, le débit moyen, le temps de réponse moyen, les temps de réponse maximum et minimum, ainsi que les erreurs, mis à jour en direct sur un graphique. Un onglet Erreurs détaille les requêtes échouées, et l'onglet Rapports de test conserve l'historique des exécutions afin que vous puissiez comparer les changements.
Puis-je tester la charge avec des requêtes basées sur des données ?
Oui. Si votre scénario est basé sur des données de test, choisissez "Correspondance aléatoire" pour que chaque utilisateur virtuel tire une ligne aléatoire à chaque boucle, ou "Correspondance séquentielle" pour parcourir les lignes dans l'ordre.
Dois-je encore utiliser Locust pour quelque chose ?
Oui, lorsque ses forces correspondent à vos besoins : comportement utilisateur défini par code avec branchements et tâches pondérées, clients de protocole personnalisés, et génération de charge distribuée dépassant largement les 100 utilisateurs virtuels. Utilisez le bon outil pour la forme du test.