Durante o último mês, fui forçado a aprender muitas coisas sobre a configuração do servidor, integração, AWS, etc. Eu nunca fiz isso até esse ponto.
Eu obtive tudo e corri bem para o meu aplicativo (principalmente graças à gem link e à ajuda do # canal de IRC # rubberec2) . No entanto, estou encontrando um problema misterioso (para mim).
Pilha
Estou executando o Nginx + Passenger atrás do HAProxy. Até agora apenas um host Nginx + Passenger está sendo usado, então o HAProxy ainda não faz muito, mas adicionaremos mais servidores de aplicativos no futuro.
Problema
Estou preso a erros ocasionais de 503 que se tornam irritantes em determinados momentos do dia (durante uma carga maior?). Esses erros estão acontecendo em ativos estáticos e em URLs roteados. Eu determinei que é o HAProxy que os lança, porque a página e seus cabeçalhos são idênticos aos que estão em /etc/haproxy/errors/503.http.
Eu achei que o nginx não se importa com quantos pedidos ele recebe, ele pode lidar com todos eles, já que ele tem seu próprio enfileiramento, e o passageiro distribui as coisas corretamente. Então, por que o HAProxy afirma que não havia servidor disponível para lidar com algumas solicitações?
Minha configuração do HAProxy
global
log 127.0.0.1 local0 warning
maxconn 1024
defaults
log global
mode http
retries 3
balance roundrobin
option abortonclose
option redispatch
option httplog
contimeout 4000
clitimeout 150000
srvtimeout 30000
listen passenger_proxy x.x.x.x:x
option forwardfor
server web01 web01:xxxx maxconn 20 check
Nota: os IPs e as portas são substituídos por x es.
P.S. Eu não sou bom nessas coisas, aprendendo como eu vou.
Atualizar
Eu usei siege para comparar o servidor e descobri que posso reproduzir os 503s ao executar cerca de 58 sessões simultâneas. A taxa de sucesso é de apenas 54% nesse caso.
Atualização 2
Descobri que o log de acesso do nginx gera "-" 400 0 "-" "-" "-" toda vez que recebo 503.
Atualização 3
Todo mundo diz que o nginx dá erros "400 Bad Request" quando os cookies são muito grandes. No entanto, a configuração de large_client_header_buffers directive não corrigiu isso para mim.
Atualização 4
Corri siege no servidor, direcionando o nginx diretamente para sua porta de escuta e agora o nginx começou a retornar 499 erros com o mesmo padrão usado para retornar 503s antes. O cerco me diz que a conexão expirou quando isso acontece. Parece que estou chegando perto.
Atualização 5
Eu notei que o nginx estava logando em dois lugares no meu sistema, e havia um log de erro retornando esta mensagem toda vez que o cerco mostrava "Conexão esgotada":
file=ext/nginx/HelperAgent.cpp:574 time=2011-09-15 07:43:22.196 ]: Couldn't forward the HTTP response back to the HTTP client: It seems the user clicked on the 'Stop' button in his browser.