Usando o balanceador de carga integrado do uWSGI x nginx

3

Eu tenho um aplicativo python que é exposto através do wsgi e ia implantá-lo para o mundo. Não há ativos estáticos que são servidos a partir dele. O aplicativo será implantado em uma única máquina. Eu vou servir o aplicativo wsgi usando o uwsgi e posso pensar em duas opções:

  1. veicula através de uma única instância do uwsgi na máquina, (descubra e gire com um bom número de trabalhadores / processos para usar talvez comece 2 * # núcleos)

  2. Execute várias instâncias do uwsgi, cada uma com um único trabalhador, atrás do nginx na mesma máquina.

  3. Execute uma única instância do uwsgi, atrás de nginx

Uma coisa a ter em mente é que o servidor já está atrás de um balanceador de carga.

Eu consideraria experimentar com # 2 ou # 3 se eu tivesse recursos estáticos para veicular. Como não há arquivos estáticos, parece que é um exagero.

Nesse caso, haveria algum benefício em executar o uwsgi por trás do nginx? oposta a um único servidor uswgi com um número apropriado de trabalhadores?

    
por dm03514 24.11.2015 / 22:31

1 resposta

1

A resposta a essa pergunta depende muito do seu caso de uso.

Eu não sei muito sobre o uWSGI, mas não consigo imaginar nenhum caso de uso em que faria sentido ter vários exemplos semelhantes sendo executados exatamente na mesma máquina / vm, já que ele é obviamente projetado para encadeamento. Sua sobrecarga apenas adicional. Portanto, # 2 não é realmente uma opção (se o seu aplicativo precisar ser reiniciado com frequência, corrija seu código em vez de usar essa configuração).

# 3 soa meio inútil agora, mas não é. nginx não é muito sobrecarga, é desempenho e pegada de memória é provavelmente insignificante, neste caso, em comparação com o aplicativo python. Isso causa impacto na latência, mas, novamente, isso não deve importar em nada menos do que um servidor de jogo RTS (e o http não é feito para baixa latência). O problema real é a configuração adicional e outro ponto de falha. No entanto, é muito mais provável que seu aplicativo falhe em relação a um servidor da Web bem testado e usado, de modo que basicamente se resume à configuração.

Com isso fora do caminho, aqui estão algumas coisas a serem consideradas.

  • Se este for um pequeno aplicativo da web em que você não espera mais usuários do que um único servidor pode suportar sem problemas (por exemplo, sua home page pessoal, a página inicial de uma escola pequena), um único uWSGI está totalmente correto. Como o uWSGI tem seu balanceador de carga próprio , você terá um substituto que pode lidar com o dimensionamento de pequenas instâncias (não tenho certeza sobre grandes implantações no entanto).
  • Se você tiver certeza de que seu aplicativo permanecerá hospedado agora (por exemplo, AWS), ainda poderá usar o número 1 e usar o balanceador de carga interno do hosters. Isso reduz sua sobrecarga e você não precisa se preocupar com configurações adicionais. Entretanto, você deve estar ciente de que os preços e o serviço podem mudar e os pequenos hosters podem sair do mercado (com o risco de que o AWS seja pequeno o suficiente).
  • Se você acha que seu aplicativo pode ser dimensionado rapidamente a partir de uma única VM e que seu balanceador de carga de hosters não é garantia, você deve realmente adicionar nginx. Como afirmei acima, não é muito uma sobrecarga e se você de repente precisar de uma segunda VM, ficará muito grato. Ele também permite lidar com falhas de seu aplicativo e filtrar solicitações (por exemplo, se você estiver no DOS). Se você adicionar https, o nginx também o ajudará.

TL; DR

Se você tem certeza de que seu aplicativo não vai escalar mais rápido do que você pode escalar o código (ou não escalar), você não precisa de recursos adicionais (seu aplicativo não é tão estável quanto você acho que é!) e você tem certeza de sua capacidade de balanceamento de carga hosters, pular nginx. Se não for ou se você não tiver 100% de certeza de que o que está acima permanecerá verdadeiro, use nginx. Não é muita sobrecarga, mas pode poupar muitos problemas.

    
por 05.12.2015 / 17:47