O número máximo de conexões é afetado por certos limites nos lados do cliente e do servidor, embora um pouco diferente.
No lado do cliente:
aumente o intervalo de portas epérmicas e diminua otcp_fin_timeout
Para descobrir os valores padrão:
sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.tcp_fin_timeout
O intervalo de portas epérmicas define o número máximo de soquetes de saída que um host pode criar a partir de um endereço IP específico. O fin_timeout
define o tempo mínimo em que esses soquetes permanecerão no TIME_WAIT
estado (inutilizáveis após serem usados uma vez). Os padrões usuais do sistema são:
net.ipv4.ip_local_port_range = 32768 61000
net.ipv4.tcp_fin_timeout = 60
Isso basicamente significa que seu sistema não pode garantir consistentemente mais do que (61000 - 32768) / 60 = 470
soquetes por segundo. Se você não estiver satisfeito com isso, poderá começar aumentando o port_range
. Definir o intervalo para 15000 61000
é bastante comum nos dias de hoje. Você pode aumentar ainda mais a disponibilidade diminuindo o fin_timeout
. Suponha que você faça as duas coisas, verá mais de 1500 conexões de saída por segundo, mais rapidamente.
Para alterar os valores :
sysctl net.ipv4.ip_local_port_range="15000 61000"
sysctl net.ipv4.tcp_fin_timeout=30
O acima não deve ser interpretado como os fatores que afetam a capacidade do sistema para fazer conexões de saída por segundo. Mas esses fatores afetam a capacidade do sistema de lidar com conexões simultâneas de maneira sustentável por longos períodos de "atividade".
Os valores padrão do Sysctl em uma caixa típica do Linux para tcp_tw_recycle
& tcp_tw_reuse
seriam
net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_tw_reuse=0
Eles não permitem a conexão de um soquete "usado" (em estado de espera) e forçam os soquetes a durar o time_wait
ciclo completo . Eu recomendo definir:
sysctl net.ipv4.tcp_tw_recycle=1
sysctl net.ipv4.tcp_tw_reuse=1
Isso permite um rápido ciclo de soquetes no time_wait
estado e reutilizá-los. Porém, antes de fazer essa alteração, verifique se isso não entra em conflito com os protocolos que você usaria para o aplicativo que precisa desses soquetes. Leia a postagem "Como lidar com o TCP TIME-WAIT" de Vincent Bernat para entender as implicações. A net.ipv4.tcp_tw_recycle
opção é bastante problemática para servidores voltados para o público, pois não processa conexões de dois computadores diferentes atrás do mesmo dispositivo NAT , o que é um problema difícil de detectar e está esperando para te morder. Observe que net.ipv4.tcp_tw_recycle
foi removido do Linux 4.12.
No lado do servidor:
o net.core.somaxconn
valor tem um papel importante. Limita o número máximo de solicitações na fila para um soquete de escuta. Se você tem certeza da capacidade do seu aplicativo de servidor, aumente do padrão 128 para algo como 128 a 1024. Agora você pode aproveitar esse aumento modificando a variável backlog de escuta na chamada de escuta do aplicativo, para um número igual ou superior.
sysctl net.core.somaxconn=1024
txqueuelen
O parâmetro de suas placas Ethernet também tem um papel a desempenhar. Os valores padrão são 1000, portanto, aumente-os para 5000 ou até mais, se o seu sistema puder lidar com isso.
ifconfig eth0 txqueuelen 5000
echo "/sbin/ifconfig eth0 txqueuelen 5000" >> /etc/rc.local
Da mesma forma, amplie os valores para net.core.netdev_max_backlog
e net.ipv4.tcp_max_syn_backlog
. Seus valores padrão são 1000 e 1024, respectivamente.
sysctl net.core.netdev_max_backlog=2000
sysctl net.ipv4.tcp_max_syn_backlog=2048
Agora, lembre-se de iniciar os aplicativos do lado do cliente e do servidor aumentando os limites de FD no shell.
Além da acima mencionada, uma técnica mais popular usada pelos programadores é reduzir o número de chamadas de gravação TCP . Minha preferência é usar um buffer no qual envio os dados que desejo enviar ao cliente e, em pontos apropriados, escrevo os dados no buffer no soquete real. Essa técnica permite que eu use pacotes de dados grandes, reduza a fragmentação, reduz a utilização da CPU tanto na área do usuário quanto no nível do kernel.