Méthode de test de charge lors de l'utilisation de l'API de service externe
La dernière fois, j'ai écrit sur les grandes lignes du test de charge, mais cette fois, j'écrirai sur le test de charge de l'API externe qui a été fait à ce moment-là. Cet article est tiré de l'article précédent [Connaissance du test de charge minimale obtenue dans le premier test de charge du serveur API], «Il s'agit d'un test de charge difficile. Il mérite l'item "Je frappe l'API d'un service externe".
Configuration du serveur testée en charge
Le serveur d'API créé cette fois frappe l'API du service externe à l'intérieur de l'API.
Cette fois, le sundbox de service externe n'existait pas, il n'a donc pas été possible d'effectuer directement un test de charge incluant le service externe. De plus, ce mécanisme a été configuré pour que le serveur externe s'authentifie à la première fois et que les autres API ne puissent être touchées qu'après la réussite de l'authentification, donc si un problème survient ici, un nouvel utilisateur peut le gérer. Il a joué un rôle si important qu'il a disparu.
Objectif du test de charge pour les services externes
- Examiner dans quelle mesure les performances de l'API du service externe affectent
- Si des services externes sont impliqués, les performances de votre propre serveur seront grandement affectées par l'état des performances des services externes. Pour faire face aux problèmes, il est nécessaire de savoir à l'avance quelle influence ils ont.
Comment tester
Comme je l'ai dit au début, cette fois, l'environnement sundbox n'existait pas dans l'API du service externe, il n'était donc pas possible de se connecter directement au service externe lors du test de charge.
Par conséquent, nous avons préparé un serveur factice, et cette fois nous avons décidé d'effectuer un test de charge en nous connectant au serveur factice. Ensuite, comment tester avec un serveur factice, mais cette fois j'ai ajouté une seule fonction pratique au serveur factice, et en utilisant cette fonction, j'ai pu mesurer le degré d'influence du serveur externe.
Conditions du serveur factice
-
Accepte la même requête qu'une API externe normale et renvoie le même type de réponse. ―― Tout d'abord, c'est naturel, mais la condition minimale est de se comporter de la même manière que l'API externe que vous utilisez réellement.
-
Vous pouvez spécifier le temps de réponse. ――C'est la fonction pratique utilisée cette fois. En ajustant le temps de réponse, il est possible de supposer certains modèles de performances du serveur externe et d'effectuer un test de charge.
Pour écrire un exemple, le temps de réponse peut être ajusté en fonction de la valeur de X-Sleep </ b> dans l'en-tête comme indiqué ci-dessous.
curl -d '{"user":"hoge"}' https://dummy-server.jp/test/api -H "Content-type: application/json" -H "X-Sleep: 2000"
Méthode d'essai de charge
- La valeur normale est un taux d'utilisation du processeur de 50% ou moins.
- Créez un scénario avec uniquement des API liées à des API externes avec locasut et appliquez une charge.
- Mesurez le temps de réponse de l'API du serveur factice avec un nombre fixe de modèles entre 100 ms et 3000 ms, et mesurez comment le temps de réponse de l'API du serveur factice l'affecte. --Il est préférable de modifier le temps de réponse à mesurer en fonction du temps défini du timeout.
- Définissez la valeur limite à l'endroit où la médiane devient instable ou où l'erreur 502 commence, et mesurez le RPS et l'utilisation du processeur jusqu'à ce point. --Lorsque la médiane (médiane) augmente en même temps, il est possible que les performances se soient détériorées en raison de la charge.
Résultats de test
Voici un exemple des résultats du test de charge.
| Temps de réponse | RPS | l'utilisation du processeur |
|---|---|---|
| 100ms | 230 | 90% |
| 200ms | 220 | 80% |
| 300ms | 200 | 75% |
| 400ms | 200 | 72% |
| 500ms | 190 | 65% |
| 600ms | 185 | 60% |
| 700ms | 175 | 60% |
| 800ms | 170 | 55% |
| 900ms | 155 | 50% |
| 1000ms | 140 | 45% |
| 1500ms | 110 | 30% |
| 2000ms | 85 | 20% |
| 3000ms | 60 | 15% |
D'après ce résultat, on peut voir que lorsque le temps de réponse dépasse 1000 ms, l'utilisation du processeur dépasse 50% et les performances se détériorent.
Le contenu dérivé de ce résultat est que si le temps de réponse moyen du serveur externe est d'environ 1000 ms ou plus, cela peut affecter le serveur API de l'entreprise. </ b>
Mesures possibles en fonction des résultats du test de charge
――Lorsque vous entrez dans le service, vous pouvez mesurer le temps de réponse de l'API du serveur externe, et si le temps de réponse moyen est de 1000 ms ou plus, vous pouvez prendre des mesures telles que l'augmentation du nombre de serveurs et décider rapidement de maintenir les performances.
- De plus, vous pouvez sélectionner le paramètre de temps TimeOut lors de la connexion à l'API de service externe et décider de réessayer, etc. en fonction des résultats ci-dessus.
à la fin
Cette fois, j'ai testé avec cette approche, mais je pense que je dois découvrir s'il existe une autre meilleure façon. Cependant, si vous avez des informations sous forme de numéro plutôt que de ne rien faire, vous vous sentirez plus en sécurité.
Recommended Posts