Test de charge d'API gratuit

Faites un test de charge sur un point d'accès REST, GraphQL ou SOAP en ligne en moins de 60 secondes. Des milliers d'utilisateurs virtuels depuis plus de 25 régions cloud, avec latence p95 et p99, débit et taux d'erreur par requête.


Options:
Get started for free to access more locations, save test history, and set alerts.


Connaissez la vraie capacité de votre API

Combien de requêtes par seconde votre API sert-elle avant que la latence ne monte ?

Un simple curl ne dit rien sur la concurrence.

Un test de charge d'API envoie de nombreuses requêtes en parallèle et mesure chacune d'elles.

Vous obtenez la latence p95 et p99, le débit et les erreurs par point d'accès.

Requêtes de base de données lentes, limites de débit et pools de connexions apparaissent immédiatement.

Testez avant le lancement de l'application mobile, pas après le premier avis à une étoile.

Testez de vraies requêtes, pas seulement un ping

L'exécution gratuite sollicite tout point d'accès public avec des utilisateurs simultanés.

L'application complète ajoute méthodes, en-têtes, authentification et corps JSON.

Enchaînez les requêtes pour reproduire un vrai parcours connexion puis lecture.

Vous avez déjà un script JMeter ou k6 ? Importez-le et exécutez-le depuis le cloud.

Chaque exécution conserve un détail par requête et une chronologie.

Définissez des seuils de réussite ou d'échec et bloquez les déploiements depuis votre CI.
Testez de vraies requêtes, pas seulement un ping

Ce qu'un test de charge d'API doit mesurer

Trois chiffres racontent l'essentiel. Lisez-les ensemble, pas un par un.

Latence : p95 et p99, pas la moyenne

La moyenne cache la queue lente. Un p99 de deux secondes signifie qu'un appel sur cent attend deux secondes, ce que vos utilisateurs remarquent et ce qui déclenche vos timeouts.

Débit : requêtes par seconde

Le nombre de requêtes que l'API termine chaque seconde sous charge. Quand ajouter des utilisateurs ne l'augmente plus, vous avez trouvé la capacité du composant le plus lent derrière le point d'accès.

Taux d'erreur : 5xx, timeouts et connexions refusées

Les erreurs qui n'apparaissent que sous charge pointent vers des pools épuisés, des limiteurs de débit et des dépendances en amont. Regroupez-les par code de statut et par point d'accès pour voir lequel casse en premier.

Comment faire un test de charge d'API gratuitement

Quatre étapes, rien à installer, des résultats en quelques minutes.

  1. Saisissez l'URL du point d'accès
    Collez l'URL publique du point d'accès. Les points d'accès GET fonctionnent directement dans l'exécution gratuite ; les autres méthodes et les corps se configurent dans l'application complète.
  2. Choisissez utilisateurs et durée
    Décidez combien d'utilisateurs virtuels simultanés simuler et pendant combien de temps. Le plan gratuit couvre une exécution à 25 utilisateurs ; les plans payants vont jusqu'à des milliers depuis plusieurs régions.
  3. Lancez depuis le cloud
    Démarrez le test et laissez les générateurs de charge travailler. Votre propre réseau n'est jamais le goulot d'étranglement.
  4. Lisez latence, débit et erreurs
    Les résultats montrent la latence p95 et p99, les requêtes par seconde et les erreurs par code de statut, pour distinguer un point d'accès lent d'un point d'accès en échec.

Test de charge d'API : questions fréquentes

Qu'est-ce qu'un test de charge d'API ?

Un test de charge d'API envoie de nombreuses requêtes simultanées à un point d'accès et mesure comment la latence, le débit et le taux d'erreur évoluent à mesure que la charge augmente. Il montre la capacité de l'API et le point où elle commence à se dégrader.

Le test de charge d'API est-il gratuit ?

Oui. L'exécution gratuite fonctionne sans compte ni carte et est limitée à 25 utilisateurs virtuels depuis un emplacement. Les tests plus grands, davantage de régions et la configuration des requêtes demandent un compte gratuit ou un plan payant.

Puis-je envoyer des requêtes POST avec un corps JSON ?

L'exécution gratuite de cette page envoie des requêtes GET vers une URL publique. Connectez-vous pour définir la méthode, les en-têtes, l'authentification et le corps, ou importez un script JMeter ou k6 qui le fait déjà.

Comment tester une API qui demande une authentification ?

Ajoutez le jeton ou la clé d'API comme en-tête dans l'application complète, ou utilisez un script JMeter ou k6 qui se connecte d'abord et réutilise la session. Ne mettez pas de secrets dans l'URL d'une exécution gratuite.

Quelle est une bonne latence p95 pour une API ?

Cela dépend de l'appelant. En règle générale, moins de 200 ms pour les points d'accès derrière une interface utilisateur et moins d'une seconde pour les tâches en arrière-plan. Ce qui compte davantage, c'est que le p95 reste stable quand vous ajoutez des utilisateurs.

Puis-je tester un point d'accès GraphQL ou SOAP ?

Oui. Les deux reposent sur HTTP. Les requêtes GraphQL et les enveloppes SOAP sont envoyées dans le corps de la requête, que vous configurez dans l'application complète ou dans un script.

Puis-je lancer le même test depuis plusieurs régions ?

Les utilisateurs connectés peuvent lancer un test depuis plus de 25 régions cloud à la fois et comparer la latence par région. L'exécution gratuite utilise une seule région.

Puis-je faire échouer mon pipeline CI si l'API est trop lente ?

Oui. Définissez des seuils de réussite ou d'échec sur un test (p95, p99, taux d'erreur, débit minimal) et lisez le verdict via l'API ou la GitHub Action pour bloquer un déploiement.

×