Puis-je servir plusieurs clients en utilisant uniquement Flask app.run () en mode autonome?
Je sais que je peux relier Flask avec Apache ou d’autres serveurs Web. Mais je pensais utiliser Flask en tant que serveur autonome servant plusieurs clients simultanément.
Est-ce possible? Dois-je gérer la création de plusieurs threads et les gérer?
flask.Flask.run accepte les arguments de mot clé supplémentaires (_**options_) auxquels il est transféré werkzeug.serving.run_simple - deux de ces arguments sont threaded (que vous pouvez définissez sur True pour activer le threading) et processes (que vous pouvez définir sur un nombre supérieur à un pour que werkzeug génère plusieurs processus de traitement des demandes). Donc si vous le faites:
_if __== '__main__':
app.run(threaded=True)
# Alternately
# app.run(processes=3)
_Flask dira à Werkzeug d’utiliser le threading et de générer trois processus pour traiter les demandes entrantes.
Cela dit, le _serving.run_simple_ de Werkzeug enveloppe le package wsgiref 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 envisagez d'utiliser Flask en production (en supposant que la "production" n'est pas une application interne à faible trafic ne comptant pas plus de 10 utilisateurs simultanés), veillez à le placer derrière un serveur Web réel (voir la section de la documentation de Flask intitulée Options de déploiement pour certaines méthodes suggérées).
L'utilisation de app.run() simple à partir de Flask crée un seul serveur synchrone sur un seul thread capable de servir un seul client à la fois. Il est conçu pour être utilisé dans des environnements contrôlés à faible demande (développement, débogage) 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 le 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 ouvriers (processus séparés, donc pas de soucis avec GIL), et vient même avec ouvriers asynchrones qui accélérera votre application (et la rendra plus sécurisée) avec peu ou pas de travail de votre part (en particulier avec Flask).
Pourtant, même Gunicorn ne devrait probablement pas être directement exposé au public. En production, il devrait être utilisé derrière un serveur HTTP plus robuste; nginx a tendance à aller bien avec Gunicorn et Flask.