Por que a configuração do Nginx como proxy reverso é uma boa ideia?

Question

Eu tenho um site do Django em execução no Gunicorn com um proxy reverso através do Nginx. O Nginx não é apenas uma sobrecarga extra desnecessária? Como adicionar isso em cima da ajuda do Gunicorn?

    

Answer 1

Vou me concentrar no comportamento lento do cliente e em como sua configuração lida com isso, mas não fique tentado a acreditar que esse é o único benefício. O mesmo método que beneficia os clientes lentos também traz benefícios para clientes rápidos, manuseio de SSL, lidar com surtos de tráfego e outros aspectos da veiculação de HTTP na Internet.

Gunicorn é um software de pré-bifurcação. Para comunicações de baixa latência, como o balanceador de carga para o servidor de aplicativos ou a comunicação entre serviços, os sistemas de pré-fork podem ser muito bem-sucedidos. Não há nenhum custo na criação de um processo para manipular a solicitação e um único processo pode ser dedicado a manipular uma única solicitação; a eliminação dessas coisas pode levar a um sistema global mais rápido e eficiente até que o número de conexões simultâneas exceda o número de processos disponíveis para lidar com elas.

Na sua situação, você está lidando com clientes de alta latência na Internet. Esses clientes lentos podem comprometer esses mesmos processos. Quando o QPS é importante, o código do aplicativo precisa receber, manipular e resolver a solicitação o mais rápido possível para que ela possa passar para outra solicitação. Quando os clientes lentos se comunicam diretamente com seu sistema, eles atam esse processo e o atrasam. Em vez de manipular e descartar a solicitação o mais rápido possível, esse processo agora também precisa aguardar o cliente lento. QPS efetivo cai.

Lidar com um grande número de conexões com muito pouca CPU e custo de memória é o que os servidores assíncronos como o Nginx são bons. Eles não são afetados da mesma maneira negativa por clientes lentos porque são adeptos de lidar com um grande número de clientes simultaneamente. No caso do Nginx, rodando em hardware moderno, ele pode lidar com dezenas de milhares de conexões de uma só vez.

O Nginx na frente de um servidor de pré-separação é uma ótima combinação. O Nginx lida com comunicações com clientes e não sofre penalidade por lidar com clientes lentos. Ele envia solicitações para o back-end com a mesma rapidez com que o back-end pode lidar com essas solicitações, permitindo que o backend seja tão eficiente quanto possível com os recursos do servidor. O backend retorna o resultado assim que é calculado, e o Nginx armazena essa resposta para alimentá-lo para desacelerar os clientes em seu próprio ritmo. Enquanto isso, o backend pode passar a lidar com outro pedido, mesmo que o cliente lento ainda esteja recebendo o resultado.

    

Answer 2

@blueben está certo. Um exemplo específico e comum do que pode acontecer quando um proxy reverso não é usado é que um banco de dados de back-end pode executar identificadores de conexão de banco de dados onde não há proxy e há um pico de tráfego. Isso se deve ao fato de as conexões serem lentas para serem liberadas como descrito @blueben.

Um primeiro instinto em ver as alças de banco de dados se esgotando pode ser o de suportar mais conexões de banco de dados. Mas, ao adicionar um proxy reverso na frente do aplicativo, você verá o número de conexões de banco de dados necessárias para alta carga, que caem significativamente e se estabilizam - o nível de conexão do banco de dados não aumentará muito quando houver um pico de tráfego.

O Nginx também é ótimo para servir conteúdo estático, armazenamento em cache e várias outras tarefas HTTP, permitindo que o servidor de aplicativos se concentre em ser um servidor de aplicativos.

    

Answer 3

@naill Donegan menciona isso no comentário acima, mas é importante o suficiente para justificar uma resposta.

Nginx interrompe o lento ataque de loris que o gunicorn não suporta.