[PYTHON] Efforts d'amélioration des performances

La dernière fois, j'ai écrit sur les tests que mon équipe effectue. Cette fois, je voudrais écrire sur les points auxquels je fais attention lors de sa mise en œuvre, ainsi que sur la nouvelle relique et le criquet utilisés pour améliorer les performances.

Points à prendre en compte lors de la mise en œuvre

La chose la plus importante à surveiller est "Si vous sélectionnez ou créez dans une boucle, mettez-la hors de la boucle". Récupérer avec select in, bulk create, cela seul améliorera considérablement la réponse. L'algorithme parvient à le faire après l'avoir supprimé.

Présentation des outils

Peu importe à quel point vous êtes prudent, vous êtes un être humain. Il y a des cas où il est laissé tel quel. Si vous vérifiez le temps de traitement avec New Relic, vous pouvez voir la situation où la même instruction de sélection est émise plusieurs fois. Si elle est trouvée, nous la considérerons et la corrigerons afin qu'elle ne puisse être effectuée qu'une seule fois.

New Relic ##

Y a-t-il un traitement lent?

• Il faut environ 600 ms pour exécuter cette API !! *

pourquoi ~?

• Select est exécuté 71 fois !! *

Tout d'abord, cherchez un endroit qui peut être corrigé de cette manière et essayez de l'améliorer.

Locust ## http://locust.io Locust est un outil de test de charge. Après avoir apporté des améliorations à New Relic, utilisez locust pour charger et vérifier la réponse de l'API. Si vous le faites, la réponse sera lente en attendant que le verrou soit libéré, ou le résultat sera "* Un verrou mort s'est produit! *" En premier lieu, donc "Réduisons la plage de verrouillage" ou "L'ordre de verrouillage était incorrect!" On a découvert que cela nous a aidés à apporter d'autres améliorations. Ce n'était pas souvent que c'était encore lent, mais dans ce cas, il serait préférable de revoir la logique.

Why Locust? ### **Je ne sais pas! ** ** Je n'étais pas en charge! Lorsque j'écris cet article, j'ai l'impression d'essayer de passer cet article à la hâte.

Cependant, c'était plus facile à comprendre par rapport à JMeter, avec lequel je jouais lorsque j'étais sur le point de faire un test de charge auparavant. La raison en est que le test de charge est écrit en code python. Je pensais pouvoir l'écrire moi-même. Je n'ai aucune expérience dans la mise en œuvre du code de test de charge, je vais donc l'étudier et le publier plus tard, mais je vais définir le nombre d'accès pour les utilisateurs lourds et les utilisateurs légers, définir le taux de frappe sur l'API et appliquer la charge Je comprends (enfin, je pense que JMeter peut le faire aussi).

Donc, je voudrais parler de Locust la prochaine fois.