Respostas:
flask.Flask.runaceita argumentos de palavras-chave adicionais ( **options) que encaminha para werkzeug.serving.run_simple- dois desses argumentos são threaded(um booleano) e processes(que você pode definir para um número maior que um para que o werkzeug gere mais de um processo para lidar com solicitações).
threadedo padrão Trueé o do Flask 1.0; portanto, para as versões mais recentes do Flask, o servidor de desenvolvimento padrão poderá atender a vários clientes simultaneamente por padrão. Para versões mais antigas do Flask, você pode passar explicitamente threaded=Truepara ativar esse comportamento.
Por exemplo, você pode fazer
if __name__ == '__main__':
app.run(threaded=True)para lidar com vários clientes usando threads de maneira compatível com as versões antigas do Flask, ou
if __name__ == '__main__':
app.run(threaded=False, processes=3)dizer ao Werkzeug para gerar três processos para lidar com solicitações recebidas, ou apenas
if __name__ == '__main__':
app.run()para lidar com vários clientes usando threads, se você souber que usará o Flask 1.0 ou posterior.
Dito isto, o Werkzeug serving.run_simpleenvolve o wsgirefpacote da biblioteca padrão - e esse pacote contém uma implementação de referência do WSGI, não um servidor Web pronto para produção. Se você usar o Flask em produção (supondo que "produção" não seja um aplicativo interno de baixo tráfego e com mais de 10 usuários simultâneos), mantenha-o atrás de um servidor Web real (consulte a seção de documentos do Flask, intitulada Opções de implantação para alguns métodos sugeridos).
Usar o simple app.run()de dentro do Flask cria um único servidor síncrono em um único thread capaz de atender apenas um cliente por vez. Ele se destina ao uso em ambientes controlados com baixa demanda (ou seja, desenvolvimento, depuração) exatamente por esse motivo.
Gerar threads e gerenciá-los você provavelmente também não o levará muito longe, por causa do Python GIL .
Dito isto, você ainda tem algumas boas opções. O Gunicorn é um servidor WSGI sólido e fácil de usar, que permite gerar vários trabalhadores (processos separados, portanto, não se preocupa com o GIL) e até vem com trabalhadores assíncronos que aceleram seu aplicativo (e o tornam mais seguro) com pouco sem trabalho da sua parte (especialmente com o Flask).
Mesmo assim, Gunicorn provavelmente não deve ser exposto publicamente diretamente. Na produção, ele deve ser usado atrás de um servidor HTTP mais robusto; O nginx costuma ir bem com o Gunicorn e o Flask.
gunicorn app:app 127.0.0.1:8080vez de python app.py. Nginx agiria como o serviço público que expõe seu aplicativo Gunicorn-run privado (a reverse-proxy) , escondendo todos os tipos de baixo nível detalhes de implementação HTTP, talvez servir arquivos estáticos diretamente, etc.
processes=100e ser feliz com isso? No meu caso, eu só preciso de arquivos estáticos, sem métodos HTTP Post. Minha exigência é que eu queira executar todos os threads do Flask como parte do meu aplicativo pai, para que todos possam compartilhar variáveis.