Estou criando um aplicativo com o Flask, mas não sei muito sobre o WSGI e sua base HTTP, Werkzeug. Quando começo a atender a um aplicativo Flask com gunicorn e 4 processos de trabalho, isso significa que posso lidar com 4 solicitações simultâneas?
Quero dizer solicitações simultâneas, e não solicitações por segundo ou qualquer outra coisa.
Respostas:
Ao executar o servidor de desenvolvimento - que é o que você obtém executando app.run(), você obtém um único processo síncrono, o que significa que no máximo 1 solicitação está sendo processada por vez.
Ao colocar o Gunicorn na frente dele em sua configuração padrão e simplesmente aumentar o número de --workers, o que você obtém é essencialmente um número de processos (gerenciados pelo Gunicorn) que cada um se comporta como o app.run()servidor de desenvolvimento. 4 trabalhadores == 4 solicitações simultâneas. Isso ocorre porque o Gunicorn usa seu synctipo de trabalhador incluído por padrão.
É importante observar que o Gunicorn também inclui trabalhadores assíncronos, a saber eventlete gevent(e também tornado, mas isso é melhor usado com a estrutura do Tornado, ao que parece). Ao especificar um desses trabalhadores assíncronos com a --worker-classbandeira, o Gunicorn gerencia vários processos assíncronos, cada um gerenciando sua própria simultaneidade. Esses processos não usam threads, mas coroutines. Basicamente, dentro de cada processo, ainda apenas uma coisa pode estar acontecendo por vez (1 thread), mas os objetos podem ser 'pausados' enquanto aguardam a conclusão de processos externos (pense em consultas ao banco de dados ou em E / S de rede).
Isso significa que, se você estiver usando um dos trabalhadores assíncronos do Gunicorn, cada trabalhador poderá lidar com muito mais do que uma única solicitação de cada vez. O número de funcionários que é melhor depende da natureza do seu aplicativo, de seu ambiente, do hardware em que ele é executado etc. Mais detalhes podem ser encontrados na página de design do Gunicorn e notas sobre como o gevent funciona em sua página de introdução.
Atualmente, existe uma solução muito mais simples do que as já fornecidas. Ao executar o aplicativo você só tem que passar ao longo do threaded=Trueparâmetro para a app.run()chamada, como:
app.run(host="your.host", port=4321, threaded=True)Outra opção, de acordo com o que podemos ver nos documentos do werkzeug , é usar o processesparâmetro, que recebe um número> 1, indicando o número máximo de processos simultâneos a serem manipulados:
- threaded - o processo deve lidar com cada solicitação em um thread separado?
- processos - se maior que 1, lide com cada solicitação em um novo processo até esse número máximo de processos simultâneos.
Algo como:
app.run(host="your.host", port=4321, processes=3) #up to 3 processesMais informações sobre o run()método aqui e a postagem do blog que me levou a encontrar a solução e as referências da API.
Nota: nos documentos do Flask sobre os run()métodos, é indicado que o uso em um ambiente de produção é desencorajado porque ( aspas ): "Embora leve e fácil de usar, o servidor interno do Flask não é adequado para produção, pois não é bem dimensionado. . "
No entanto, eles apontam para a página Opções de implantação , para obter as maneiras recomendadas de fazer isso ao ir para produção.
Não, você definitivamente pode lidar com mais do que isso.
É importante lembrar que, no fundo, supondo que você esteja executando uma máquina com um único núcleo, a CPU realmente executa apenas uma instrução * por vez.
Nomeadamente, a CPU pode executar apenas um conjunto muito limitado de instruções e não pode executar mais de uma instrução por tick de clock (muitas instruções levam até mais de 1 tick).
Portanto, a maior parte da concorrência de que falamos em ciência da computação é a concorrência de software. Em outras palavras, existem camadas de implementação de software que abstraem a CPU de nível inferior e nos fazem pensar que estamos executando o código simultaneamente.
Essas "coisas" podem ser processos, que são unidades de código que são executadas simultaneamente, no sentido de que cada processo pensa que está sendo executado em seu próprio mundo com sua própria memória não compartilhada.
Outro exemplo são os threads, que são unidades de código dentro de processos que também permitem simultaneidade.
A razão pela qual seus 4 processos de trabalho serão capazes de lidar com mais de 4 solicitações é que eles disparam threads para lidar com mais e mais solicitações.
O limite de solicitação real depende do servidor HTTP escolhido, E / S, SO, hardware, conexão de rede etc.
Boa sorte!
* instruções são os comandos básicos que a CPU pode executar. exemplos - adicione dois números, pule de uma instrução para outra