Comment calculer le nombre maximum de requêtes par seconde d'une application Django ?

Question

Je suis sur le point de déployer une application Django, et c'est alors que je me suis rendu compte que je ne pouvais pas trouver un moyen d'anticiper le nombre de requêtes par seconde que mon application peut gérer.

Existe-t-il un moyen de calculer le nombre de requêtes par seconde qu'une application Django peut traiter, sans avoir recours à des choses telles qu'un déploiement de test et l'utilisation d'un outil externe tel que criquet ?

Je sais que plusieurs facteurs entrent en jeu (comme le nombre de requêtes de base de données, etc.), mais il existe peut-être un moyen pratique de calculer, voire d'estimer, le nombre de visiteurs qu'une seule instance d'application Django peut gérer.

EDIT : J'ai supprimé la mention de Gunicorn, car elle ne fait qu'ajouter de la confusion à ce que je voulais vraiment savoir.

Answer 1

Existe-t-il un moyen de calculer le nombre de requêtes par seconde qu'un système de une application Django, sans avoir recours à des choses comme faire un test de déploiement et d'utiliser un outil externe tel que locust ?

Non et Oui. Comme l'a souligné mackarone, je ne pense pas qu'il soit possible d'éviter de le mesurer. Considérez le cas où vous avez fait un benchmark local sur votre serveur de développement local communiquant avec une instance de base de données locale, afin de générer une base de référence pour l'estimation. Le problème est que le matériel et le réseau (distance entre les services) font une énorme différence. Par conséquent, les chiffres générés localement n'auraient aucune valeur pour la planification de la capacité.

D'après mon expérience, les tests locaux sont très utiles pour relatif changements. Prenons l'exemple d'un cas où l'on souhaite évaluer l'impact de la planification des requêtes SQL sur les performances. Établir une base de référence locale, effectuer le changement, puis observer l'effet localement. es utile pour évaluer la vitesse relative.

Comment générer ces chiffres ?

Je vous recommande de déployer l'application sur le matériel et le réseau sur lesquels vous prévoyez de faire des tests. Ce déploiement devrait utiliser votre configuration de production et la topologie des composants (par exemple, si vous allez utiliser gunicorn, assurez-vous que gunicorn fonctionne à la place de NGINX, ou si vous allez avoir un proxy en face de gunicorn, assurez-vous qu'il est configuré). Je lancerais une seule instance de votre application en utilisant votre configuration de production.

Une fois ce processus lancé, j'effectuerais un test de charge sur l'instance unique à l'aide de l'un des outils de test de charge les plus répandus :

• Benchmark Apache
• Siège
• Végéta
• K6
• etc.

Vous pouvez lancer ces tests de charge à partir d'une seule machine et augmenter le trafic jusqu'à ce que les temps de réponse ne soient plus acceptables afin d'avoir une idée du nombre de connexions simultanées et du débit que votre application peut supporter.

Vous avez maintenant une idée de ce qu'une instance unique de votre service est capable de gérer. Jusqu'à ce que votre base de données (ou d'autres ressources partagées) soit saturée, ces chiffres peuvent être utilisés pour prévoir combien d'instances de votre service sont nécessaires pour gérer un certain volume de trafic !

Answer 2

Según la Gunicorn la documentation

Combien de travailleurs ?

NE PAS adapter le nombre de travailleurs au nombre de clients que vous prévoyez d'avoir. . Gunicorn ne devrait avoir besoin que de 4-12 processus de travail pour traiter des centaines ou des milliers de demandes par seconde .

Gunicorn s'appuie sur le système d'exploitation pour assurer l'équilibrage de la charge lors du traitement des demandes. En général, nous recommandons (2 x $num_cores) + 1 comme nombre de travailleurs pour commencer. Bien qu'elle ne soit pas très scientifique, cette formule repose sur l'hypothèse que, pour un noyau donné, un travailleur lira ou écrira à partir du socket pendant que l'autre travailleur traitera une requête.

Il est évident que le nombre optimal de travailleurs dépend de votre matériel et de votre application. Notre recommandation est la suivante commencer par la supposition ci-dessus et régler en utilisant les signaux TTIN et TTOU pendant que l'application est en charge .

N'oubliez jamais, il y a trop de travailleurs . Au bout d'un certain temps, vos processus de travail commenceront à solliciter les ressources du système, ce qui diminuera le débit de l'ensemble du système.

La meilleure chose à faire est de le régler à l'aide d'un outil de test de charge tel que Locust, comme vous l'avez mentionné.

C'est moi qui souligne

Answer 3

Vous devez d'abord installer (loadtest), c'est un paquet npm, J'étais en train d'apprendre redis et à cette époque j'ai trouvé ceci, vous pouvez l'utiliser, cela a fonctionné pour moi, Pour en savoir plus, consultez ce tutoriel : https://realpython.com/caching-in-django-with-redis/#start-by-measuring-performance

npm install -g loadtest

loadtest -n 100 -k  http://localhost:8000/myUrl/