Pourquoi votre application FastAPI (ou Flask) fonctionne mal avec des charges élevées

Tout d’abord, désolé pour l’appât du titre ?, mais j’ai résolu ce problème hier soir et je suis toujours sous les effets de la poussée de dopamine. Je dois juste partager ça.

Ce texte est destiné aux développeurs débutants ou aux Data scientists (et non aux ingénieurs logiciels Python seniors) et je l'écrirai sous forme de récit, ou en d'autres termes, de séquence chronologique des événements tels qu'ils se sont produits, au lieu d'un "document technique". (structuré en problème, solution, discussion). J'aime cette approche car elle montre comment les choses se passent dans la vraie vie.

Considérations initiales

Ces tests ont été effectués sur GCP Cloud Run en utilisant un seul processeur et une machine de 512 M de RAM, et nous avons utilisé Locust, un outil incroyable (pour Python, LoL).

De plus, si vous rencontrez déjà des problèmes de performances sur des requêtes uniques sur Postman, je vous suggère fortement de jeter un œil à ce dépôt dédié à augmenter les performances de FastAPI de kisspeter et celui-ci de LoadForge.

Premier cycle d'essai

En utilisant une seule requête dans Postman, après le démarrage de Cloud Run, j'obtenais un temps de réponse d'environ 400 ms. Pas le meilleur, mais tout à fait dans une fourchette acceptable.

Notre test de charge est assez simple : lit, écrit et supprime dans une seule table (ou GET, POST et DELETE vers les points de terminaison de l'API). 75 % de lecture, 20 % d'écriture, 5 % de suppression. Nous l'exécutons avec 100 utilisateurs simultanés pendant 10 min.

À la fin, nous avons obtenu un temps de réponse moyen de 2 secondes, mais le plus inquiétant est que le temps moyen augmentait encore à la fin du test, il est donc très probable que le nombre augmente encore avant (et si) il se stabilise. .

J'ai essayé de l'exécuter localement sur ma machine, mais à ma grande surprise, le temps de réponse dans Postman n'était que de 14 ms. Cependant, lors de l'exécution du test de charge pour 500 utilisateurs simultanés, le problème est réapparu ? ...

À la fin du test, le temps de réponse était d'environ 1,6 s et continuait d'augmenter, mais un problème s'est produit et le ciel du 95e centile est monté en flèche (et a ruiné le graphique =( ). Voici les statistiques :

Maintenant, pourquoi un serveur qui répond en 14 ms passe-t-il soudainement à 1,6 seconde avec seulement 500 utilisateurs simultanés ?

Ma machine est un core i7, 6 cœurs, 2,6 GHz, 16 Go de RAM, SSD. Cela ne devrait pas arriver.

Ce qui m'a donné un bon indice, ce sont les journaux de mon processeur et de ma mémoire... Ils étaient extrêmement faibles !

Cela signifie probablement que mon serveur n'utilise pas toutes les ressources de ma machine. Et devinez quoi ? Ce n’était pas le cas. Permettez-moi de vous présenter un concept que la grande majorité des développeurs oublient lors du déploiement d'applications FastAPI ou Flask en production : le processus worker.

Selon getorchestra.io :

Comprendre les travailleurs du serveur

Les serveurs de travail sont essentiellement des processus qui exécutent le code de votre application. Chaque travailleur peut traiter une demande à la fois. Si vous avez plusieurs collaborateurs, vous pouvez traiter plusieurs demandes simultanément, améliorant ainsi le débit de votre candidature.

Pourquoi les serveurs sont importants

• Concurrence : ils permettent un traitement simultané des requêtes, conduisant à une meilleure utilisation des ressources du serveur et à des temps de réponse plus rapides.
• Isolement : Chaque travailleur est un processus indépendant. Si un travailleur échoue, cela n'affecte pas les autres, assurant une meilleure stabilité.
• Évolutivité : l'ajustement du nombre de travailleurs peut facilement faire évoluer votre application pour gérer différentes charges.

En pratique, tout ce que vous avez à faire est d'ajouter le paramètre facultatif --workers à la ligne d'initialisation de votre serveur. Le calcul du nombre de Workers dont vous avez besoin dépend beaucoup du serveur sur lequel vous exécutez votre application et du comportement de votre application : notamment en ce qui concerne la consommation de mémoire.

Après l'avoir fait, j'ai obtenu de bien meilleurs résultats localement pour 16 travailleurs, convergeant vers 90 ms (pour 500 utilisateurs simultanés) après 10 min :

Phase d'essai finale

Après avoir configuré les microservices avec le nombre approprié de nœuds de calcul (j'en ai utilisé 4 pour mon instance Cloud Run à processeur unique), mes résultats étaient incroyablement meilleurs dans GCP :

La valeur finale converge vers 300 ms à la fin du test dans le serveur GCP, ce qui est pour le moins acceptable. ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!