Réponses:
flask.Flask.run
accepte des arguments de mot clé supplémentaires ( **options
) qu'il transmet à werkzeug.serving.run_simple
- deux de ces arguments sont threaded
(un booléen) et processes
(que vous pouvez définir sur un nombre supérieur à un pour que werkzeug génère plusieurs processus pour gérer les demandes).
threaded
par défaut à True
partir de Flask 1.0, donc pour les dernières versions de Flask, le serveur de développement par défaut pourra servir plusieurs clients simultanément par défaut. Pour les anciennes versions de Flask, vous pouvez explicitement passer threaded=True
pour activer ce comportement.
Par exemple, vous pouvez faire
if __name__ == '__main__':
app.run(threaded=True)
pour gérer plusieurs clients à l'aide de threads d'une manière compatible avec les anciennes versions de Flask, ou
if __name__ == '__main__':
app.run(threaded=False, processes=3)
pour dire à Werkzeug de générer trois processus pour gérer les demandes entrantes, ou tout simplement
if __name__ == '__main__':
app.run()
pour gérer plusieurs clients à l'aide de threads si vous savez que vous utiliserez Flask 1.0 ou une version ultérieure.
Cela étant dit, Werkzeug serving.run_simple
encapsule le wsgiref
package de la bibliothèque standard - et ce package contient une implémentation de référence de WSGI, pas un serveur Web prêt pour la production. Si vous prévoyez d'utiliser Flask en production (en supposant que "production" n'est pas une application interne à faible trafic avec pas plus de 10 utilisateurs simultanés), assurez-vous de la placer derrière un vrai serveur Web (voir la section des documents de Flask intitulée Options de déploiement pour certaines méthodes suggérées).
L'utilisation du simple à app.run()
partir de Flask crée un serveur synchrone unique sur un seul thread capable de servir un seul client à la fois. Il est destiné à être utilisé dans des environnements contrôlés avec une faible demande (développement, débogage, par exemple) pour cette raison.
Générer des threads et les gérer vous-même ne vous mènera probablement pas très loin non plus, à cause de Python GIL .
Cela dit, vous avez encore de bonnes options. Gunicorn est un serveur WSGI solide et facile à utiliser qui vous permettra de générer plusieurs travailleurs (processus séparés, donc pas de soucis GIL), et est même livré avec des travailleurs asynchrones qui accéléreront votre application (et la rendront plus sécurisée) avec peu à aucun travail de votre part (surtout avec Flask).
Pourtant, même Gunicorn ne devrait probablement pas être directement exposé publiquement. En production, il devrait être utilisé derrière un serveur HTTP plus robuste; nginx a tendance à bien aller avec Gunicorn et Flask.
gunicorn app:app 127.0.0.1:8080
lieu de python app.py
. Nginx agirait en tant que service public qui expose votre application privée exécutée par Gunicorn (un proxy inverse) , cachant toutes sortes de détails d'implémentation HTTP de niveau inférieur, servant peut-être directement des fichiers statiques, etc.
processes=100
et en être satisfait? Dans mon cas, je n'ai besoin que de fichiers statiques, pas de méthodes HTTP Post. Mon exigence est, je veux exécuter tous les threads Flask dans le cadre de mon application parent, afin qu'ils puissent tous partager des variables.