Minha empresa está lançando um novo site com potencialmente grandes ondas de visitantes em janelas muito curtas (a estimativa é de cerca de 14 mil visitantes em uma janela de 2 minutos).
Então, estou revisando nossa configuração, e meu maior problema agora é nosso frontend HTTP de nó único que usa keep-alive. O frontend está rodando o lighttpd 1.4 no CentOS 5.4.
Algumas suposições:
Portanto, 6 * 14000 = 84.000 conexões TCP. 84.000 * 150 KB ~ = 12 GB de memória. Aqui está o problema: 1. Eu não tenho essa quantidade de memória disponível no front end. 2. O lighttpd 1.4 não está muito confortável com essa quantidade de conexões para gerenciar. dói muito os hits.
Mas, do outro lado, estou preocupado com o RTT de 80ms se eu desativar o keepalive.
Vou atenuar alguns desses problemas com um CDN e um registro www secundário com um lighttpd secundário. mas o debate diz respeito ao recurso keep-alive. Eu gostaria de desligá-lo, mas estou preocupado que o impacto no tempo de abertura da página seja alto (alto RTT e o dobro da quantidade de pacotes).
Uma vez que a recuperação de conteúdo é feita, temos vários pedidos de ajax para navegar no site que geralmente se encaixam em uma única conexão tcp. Mas não tenho certeza de que o navegador liberará as outras conexões e mantenha apenas uma aberta.
Eu sei que tem havido uma série de discussões sobre o keep-alive consumindo muitos recursos. Eu meio que concordo com isso, mas considerando as suposições e a situação (um RTT entre 80ms e 100ms para metade dos nossos usuários), você acha que é sensato desativá-lo?
Como uma questão secundária: você sabe onde posso encontrar as informações sobre o tamanho da conexão e o tamanho do conntrack no kernel? (diferente de printf size_of (sk_buff)).
--- editar: alguns resultados de teste Configurei o conntrack para aceitar conexões de 500k (considerando a área ocupada pela memória, não deve exceder 200MB) e iniciar um teste ab.
ab -n 20000 -c 20000 -k http://website.com/banner.jpg
Pelo que vi no tcpdump, o ab estabelece todas as conexões antes de fazer o GET. Então eu tenho uma idéia de quanta memória é consumida por essas conexões de 20k.
retornos slabtop
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
40586 40586 100% 0.30K 3122 13 12488K ip_conntrack
e topo
PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA COMMAND
15 0 862m 786m 780 S 22.9 3.3 1:44.86 76m 172 786m lighttpd
12MB para ip_conntrack e 786MB para lighttpd são bons para minha configuração. Eu posso facilmente gerenciar 4x isso.
Então, keepalive ou seja, com um tempo limite ocioso configurado para 5 segundos.
Por que não definir o tempo limite de atividade como, digamos, 15 segundos? Não vejo motivo para manter cada conexão por dois minutos. E não acho que o navegador manterá a conexão por dois minutos, de acordo com este link: link , 1 minuto o tempo limite parece ser mais realista.
Eu aconselho tempos limite de keep-alive muito baixos (1s).
se você fez o seu trabalho básico no perf lado do cliente (ordenação correta de JS / CSS, JS no fundo ou assíncrono ...) você pode definir seu keep-alive muito baixo (1s), porque não haverá muito atraso entre 2 reutilizações de suas conexões TCP.
Em caso de dúvida, webpagetest sua página com 5s e 1s (visão de conexão), você verá se isso quebra a reutilização de suas conexões TCP.
Eu tentei ter 0s em um front end do Apache, e isso é definitivamente muito pequeno, mas 1s em bom
Tags performance lighttpd keepalive