J'ai fait un test de charge sur l'application de jeu pour smartphone, je voudrais donc partager comment cela a été fait. Cette fois, nous avons effectué un test de charge en supposant 100 000 DAU.

Les outils utilisés

Client de test de charge
- locust
Suivi de la performance
Nouvelle relique (en plus de la surveillance normale, ajoutez le plugin MySQL)
Moniteur standard AWS

Test de charge avec une configuration simple

Tout d'abord, le test de charge est effectué avec une configuration simple, y compris la signification de la confirmation de communication. Cette fois, j'ai créé une API qui fait juste écho au json passé et effectué un test de charge à l'aide de locust. Si vous le faites soudainement avec plusieurs unités, vous ne saurez pas où régler lorsque les performances ne sont pas atteintes. Tout d'abord, voyons comment le framework Django peut fonctionner sur le serveur d'applications lui-même. (À l'origine, il vaut mieux le faire avec Django ordinaire, mais cette fois, c'est sous la forme d'ajout d'API à Django du serveur d'application que nous développons)

En conséquence, le serveur d'applications de Django a géré environ 600 RPS avec environ 70% d'utilisation du processeur. Je pense que c'est une bonne idée de le comparer avec le benchmark de Django lui-même et de vérifier s'il est extrêmement lent.

Un autre avantage de ce test est que vous pouvez voir si le locust client de chargement lui-même peut fonctionner correctement.

Si la configuration simple fonctionne, créez un scénario de test.

Définition de l'utilisateur à tester et création d'un scénario de test

Lors de l'exécution d'un test de charge, déterminez les définitions utilisateur attendues et les objectifs à atteindre.

Je pense que cela dépend des caractéristiques de l'application, mais cette fois, nous définirons les utilisateurs comme ** utilisateurs lourds **, ** utilisateurs généraux **, ** nouveaux utilisateurs ** comme suit.

Utilisateurs lourds: utilisateurs absorbés par le jeu
Utilisateurs généraux: utilisateurs existants qui ont joué à des jeux mais qui jouent légèrement
Nouvel utilisateur: un utilisateur qui installe et joue à un nouveau jeu ce jour-là

Même si nous supposons 100 000 DAU, le nombre et les types d'API pouvant être touchés différeront selon qu'il y a beaucoup de nouveaux utilisateurs ou de gros utilisateurs, et la charge sera complètement différente. S'il y a beaucoup d'utilisateurs lourds, la partie principale du jeu, comme les quêtes et le PvP, sera beaucoup jouée. D'un autre côté, s'il y a beaucoup de nouveaux utilisateurs, l'API pour le traitement de l'inscription après l'inscription sera beaucoup touchée.

Comme nous avons divisé les utilisateurs en segments distincts, nous avons défini les API suivantes comme suit.

Définissez l'API que chaque segment atteint
Définissez à quel point chaque segment atteint son API
Calculez le nombre d'API qu'un utilisateur de chaque segment accède par jour (340 pour les gros utilisateurs dans la figure)
Multipliez 3 par la DAU de chaque segment, additionnez-les et obtenez le nombre de demandes quotidiennes qui arrivent au système (13 510 000 dans la figure). Le RPS moyen peut être calculé par 5,4
Il est nécessaire que le système émette 469 RPS (Request per Seconds), qui est estimé à environ 3 fois la valeur de crête basée sur les valeurs d'expérience jusqu'à présent.

J'ai en fait créé un scénario avec des criquets et fait un test de charge sur ce qui a été défini ci-dessus.

Test de charge sur un serveur à l'aide d'un scénario

Soudainement, vous pouvez le faire avec un seul sans test de charge en utilisant plusieurs serveurs d'applications. L'objectif est de confirmer la communication des scénarios de test et de réduire les coûts. La configuration soudaine de plusieurs serveurs d'applications n'est pas bonne car cela coûte de l'argent même lors de divers essais et erreurs dues à des erreurs. Testez le scénario de test incluant MySQL et Redis avec la configuration suivante.

Test de charge pour résister à la charge attendue

Enfin, configurez le serveur comme indiqué ci-dessous et effectuez des tests de charge jusqu'à ce que le RPS cible soit atteint. Si la charge sur le serveur d'applications est élevée (le processeur est de 70% ou plus, etc.), augmentez le serveur d'applications ou améliorez les spécifications. La même chose s'applique à MySQL et Redis.

Résumé

J'ai écrit sur la façon dont j'ai fait le test de charge dans mon projet, mais les points suivants étaient les points.

Augmentation de la configuration minimale
Créer un scénario de test à partir d'un utilisateur supposé