Socket Sharding no NGINX versão 1.9.1

O NGINX 1.9.1 apresenta um novo recurso que permite o uso da opção de soquete SO_REUSEPORT , que está disponível em versões mais recentes de muitos sistemas operacionais, incluindo DragonFly BSD e Linux (versão do kernel 3.9 e posteriores). Esta opção de soquete permite que vários soquetes escutem no mesmo endereço IP e combinação de portas. O kernel então balanceia a carga das conexões de entrada nos soquetes.

Editor – Para usuários do NGINX Plus, esse recurso é compatível com o NGINX Plus Release 7 (R7) e posteriores. Para uma visão geral de todos os novos recursos dessa versão, consulte Anunciando o NGINX Plus R7 em nosso blog.

A opção de soquete SO_REUSEPORT tem muitas aplicações potenciais no mundo real. Outros serviços podem usá-lo para atualizações contínuas fáceis de executáveis (o NGINX já oferece suporte a atualizações contínuas por diferentes meios ). Para o NGINX, habilitar esta opção de soquete pode melhorar o desempenho em certos cenários, reduzindo a contenção de bloqueio.

Conforme ilustrado na figura, quando a opção SO_REUSEPORT não está habilitada, um único soquete de escuta notifica os trabalhadores sobre conexões de entrada, e cada trabalhador tenta estabelecer uma conexão.

Com a opção SO_REUSEPORT habilitada, há vários ouvintes de soquete para cada combinação de endereço IP e porta, um para cada processo de trabalho. O kernel determina qual ouvinte de soquete disponível (e, por implicação, qual trabalhador) obtém a conexão. Isso pode reduzir a contenção de bloqueio entre trabalhadores que aceitam novas conexões e melhorar o desempenho em sistemas multicore. No entanto, isso também pode significar que quando um trabalhador é paralisado por uma operação de bloqueio, o bloqueio afeta não apenas as conexões que o trabalhador já aceitou, mas também as solicitações de conexão que o kernel atribuiu ao trabalhador desde que ele foi bloqueado.

Configurando o Socket Sharding

Para habilitar a opção de soquete SO_REUSEPORT , inclua o novo parâmetro reuseport na diretiva listen para tráfego HTTP ou TCP (módulo stream ), como nestes exemplos:

http { servidor { ouvir 80  reuseport ; nome_do_servidor localhost; # ... } } fluxo { servidor { ouvir 12345  reuseport ; # ... } }

Incluir o parâmetro reuseport também desabilita a diretiva accept_mutex para o soquete, porque o mutex é redundante com reuseport . Ainda pode valer a pena definir accept_mutex se houver portas nas quais você não definiu reuseport .

Desempenho de benchmarking com reuseport

Executei um benchmark de trabalho com 4 trabalhadores NGINX em uma instância AWS de 36 núcleos. Para eliminar efeitos de rede, executei o cliente e o NGINX no host local e também fiz o NGINX retornar a string OK em vez de um arquivo. Comparei três configurações do NGINX: a padrão (equivalente a accept_mutex on ), com accept_mutex off e com reuseport . Conforme mostrado na figura, o reuseport aumenta as solicitações por segundo em 2 a 3 vezes e reduz a latência e o desvio padrão da latência.

Também executei um benchmark relacionado com o cliente e o NGINX em hosts separados e com o NGINX retornando um arquivo HTML. Conforme mostrado na tabela a seguir, com o reuseport a diminuição na latência foi semelhante ao benchmark anterior, e o desvio padrão diminuiu ainda mais drasticamente (quase dez vezes). Outros resultados (não mostrados na tabela) também foram encorajadores. Com reuseport , a carga foi distribuída uniformemente entre os processos de trabalho. Na condição padrão (equivalente a accept_mutex ativado ), alguns trabalhadores obtiveram uma porcentagem maior da carga e, com accept_mutex desativado, todos os trabalhadores experimentaram alta carga.

Nesses benchmarks, a taxa de solicitações de conexão é alta, mas as solicitações não exigem processamento extensivo. Outros testes preliminares também indicam que o reuseport melhora mais o desempenho quando o tráfego corresponde a esse perfil. (O parâmetro reuseport não está disponível na diretiva listen no contexto de e-mail , por exemplo, porque o tráfego de e-mail definitivamente não corresponde ao perfil.) Recomendamos que você teste o reuseport para determinar se ele melhora o desempenho na sua implantação do NGINX, em vez de aplicá-lo por atacado. Para algumas dicas sobre como testar o desempenho do NGINX, confira a palestra de Konstantin Pavlov no nginx.conf 2014.

Agradecimentos

Agradecemos a Yingqi Lu da Intel e a Sepherosa Ziehau, que contribuíram com uma solução para o projeto NGINX que permite o uso da opção de soquete SO_REUSEPORT . A equipe NGINX combinou ideias de ambas as contribuições para criar o que acreditamos ser uma solução ideal.