nginx usando ip_conntrack muito mais rápido que o squid ... por que?

Question

Estou trabalhando na escalação de um servidor proxy de front-end, e até ontem eu estava usando o Squid como proxy reverso (embora basicamente nada estivesse sendo armazenado em cache, ou seja, o Squid era apenas proxy). Hoje tentei mudar para o nginx e percebi que estou atingindo os limites do ip_conntrack muito mais rapidamente.

Como uma solução temporária de curto prazo, estou apenas aumentando os limites ip_conntrack (conforme link ), mas eu queria saber se alguém aqui sabe por que o nginx está atingindo esses limites muito mais rapidamente, e se alguma coisa pode ser feita para corrigir isso? (isto é, conexões ejetadas das tabelas de rastreamento mais rapidamente).

As coisas em uso são uma caixa atualizada do Centos 5.5, o nginx 0.8.53 e o Squid 2.6. Tudo é instalado a partir de RPMs (seja o núcleo ou o EPEL).

Agradecemos antecipadamente por qualquer conselho ou esclarecimento de discussão.

Para minha própria referência, esse outro segmento foi útil neste tópico: Determine o reverso do nginx limites de carregamento de proxy

    

Answer 1

Não consigo encontrar a documentação diretamente vinculada à conntrack, mas veja este snippet da documentação do Nginx:

In a reverse proxy situation, max_clients becomes

max_clients = worker_processes * worker_connections/4

Since a browser opens 2 connections by default to a server and nginx uses the fds (file descriptors) from the same pool to connect to the upstream backend

O comportamento do Nginx com um navegador padrão é receber as duas conexões a partir dele e abrir duas conexões para os backends (proxy reverso), gerando assim 4 conexões totais. Essa pode ser a razão pela qual a conntrack está sendo preenchida mais rapidamente. Claro, isso é apenas um palpite semi-informado baseado no comportamento do trabalhador nginx.

    

Answer 2

Usar o ip_conntrack para a porta 80 é um desperdício de recursos. Marque esses pacotes como NOTRACK e use ip_conntrack para outras portas.