Ajustando o NGINX para desempenho

O NGINX é conhecido como um balanceador de carga , cache e servidor web de alto desempenho, alimentando mais de 40% dos sites mais movimentados do mundo. Para a maioria dos casos de uso, as configurações padrão do NGINX e do Linux funcionam bem, mas às vezes é necessário um pouco de ajuste para atingir o desempenho ideal. Esta postagem do blog discute algumas das configurações do NGINX e do Linux a serem consideradas ao ajustar um sistema.

Você pode ajustar quase qualquer configuração, mas esta postagem se concentra nas poucas configurações para as quais o ajuste beneficia mais os usuários. Há configurações que recomendamos que você altere somente se tiver um conhecimento profundo do NGINX e do Linux, ou conforme orientado por nossas equipes de Suporte ou Serviços Profissionais , e não as abordaremos aqui. A equipe de Serviços Profissionais trabalhou com alguns dos sites mais movimentados do mundo para ajustar o NGINX para o nível máximo de desempenho e está disponível para trabalhar com você para aproveitar ao máximo sua implantação do NGINX ou NGINX Plus.

INTRODUÇÃO

É necessário um entendimento básico dos conceitos de arquitetura e configuração do NGINX. Esta postagem não tenta duplicar a documentação do NGINX, mas fornece uma visão geral das várias opções e links para a documentação relevante.

Uma boa regra a seguir ao ajustar é alterar uma configuração por vez e restaurá-la ao valor padrão se a alteração não melhorar o desempenho.

Começamos com uma discussão sobre o ajuste do Linux, porque o valor de algumas configurações do sistema operacional determina como você ajusta sua configuração do NGINX.

Ajustando sua configuração Linux

As configurações nos kernels Linux modernos (2.6+) são adequadas para a maioria dos propósitos, mas alterar algumas delas pode ser benéfico. Verifique o log do kernel em busca de mensagens de erro indicando que uma configuração está muito baixa e ajuste-a conforme recomendado. Aqui abordamos apenas as configurações que têm mais probabilidade de se beneficiar do ajuste em cargas de trabalho normais. Para obter detalhes sobre como ajustar essas configurações, consulte a documentação do Linux.

A fila de pendências

As configurações a seguir estão relacionadas às conexões e como elas são enfileiradas. Se você tiver uma alta taxa de conexões de entrada e estiver obtendo níveis irregulares de desempenho (por exemplo, algumas conexões parecem estar travando), alterar essas configurações pode ajudar.

• net.core. somaxconn – O número máximo de conexões que podem ser enfileiradas para aceitação pelo NGINX. O padrão geralmente é muito baixo e isso é geralmente aceitável porque o NGINX aceita conexões muito rapidamente, mas pode valer a pena aumentá-lo se seu site tiver tráfego pesado. Se mensagens de erro no log do kernel indicarem que o valor é muito pequeno, aumente-o até que os erros parem.

  Observação:  Se você definir um valor maior que 512, altere o parâmetro backlog para a diretiva de escuta do NGINX para corresponder.

• net.core. netdev_max_backlog – A taxa na qual os pacotes são armazenados em buffer pela placa de rede antes de serem entregues à CPU. Aumentar o valor pode melhorar o desempenho em máquinas com alta largura de banda. Verifique o log do kernel em busca de erros relacionados a essa configuração e consulte a documentação da placa de rede para obter conselhos sobre como alterá-la.

Descritores de arquivo

Descritores de arquivo são recursos do sistema operacional usados para representar conexões e abrir arquivos, entre outras coisas. O NGINX pode usar até dois descritores de arquivo por conexão. Por exemplo, se o NGINX estiver fazendo proxy, ele geralmente usa um descritor de arquivo para a conexão do cliente e outro para a conexão com o servidor proxy, embora essa proporção seja muito menor se keepalives HTTP forem usados. Para um sistema que atende a um grande número de conexões, as seguintes configurações podem precisar ser ajustadas:

• sys.fs. file-max – O limite de todo o sistema para descritores de arquivo
• nofile – O limite do descritor de arquivo do usuário, definido no arquivo /etc/security/limits.conf

Portos Efémeros

Quando o NGINX está agindo como um proxy, cada conexão com um servidor upstream usa uma porta temporária ou efêmera . Talvez você queira alterar esta configuração:

• net.ipv4. ip_local_port_range – O início e o fim do intervalo de valores de porta. Se você perceber que está ficando sem portas, aumente o alcance. Uma configuração comum são as portas 1024 a 65000.

Ajustando sua configuração NGINX

A seguir estão algumas diretivas NGINX que podem afetar o desempenho. Conforme mencionado acima, só discutimos diretrizes que são seguras para você ajustar por conta própria. Recomendamos que você não altere as configurações de outras diretivas sem orientação da equipe do NGINX.

Processos de trabalho

O NGINX pode executar vários processos de trabalho, cada um capaz de processar um grande número de conexões simultâneas. Você pode controlar o número de processos de trabalho e como eles lidam com conexões com as seguintes diretivas:

• worker_processes – O número de processos de trabalho do NGINX (o padrão é 1). Na maioria dos casos, executar um processo de trabalho por núcleo de CPU funciona bem, e recomendamos definir esta diretiva como auto para conseguir isso. Há momentos em que você pode querer aumentar esse número, como quando os processos de trabalho precisam fazer muita E/S de disco.
• worker_connections – O número máximo de conexões que cada processo de trabalho pode manipular simultaneamente. O padrão é 512, mas a maioria dos sistemas tem recursos suficientes para suportar um número maior. A configuração apropriada depende do tamanho do servidor e da natureza do tráfego e pode ser descoberta por meio de testes.

Conexões Keepalive

As conexões Keepalive podem ter um grande impacto no desempenho, reduzindo a sobrecarga da CPU e da rede necessária para abrir e fechar conexões. O NGINX encerra todas as conexões do cliente e cria conexões separadas e independentes com os servidores upstream. O NGINX oferece suporte a keepalives para clientes e servidores upstream. As seguintes diretivas se referem aos keepalives do cliente:

• keepalive_requests – O número de solicitações que um cliente pode fazer em uma única conexão keepalive. O padrão é 100, mas um valor muito maior pode ser especialmente útil para testes com uma ferramenta de geração de carga, que geralmente envia um grande número de solicitações de um único cliente.
• keepalive_timeout – Quanto tempo uma conexão keepalive ociosa permanece aberta.

A seguinte diretiva se refere aos keepalives upstream:

• keepalive – O número de conexões keepalive ociosas para um servidor upstream que permanecem abertas para cada processo de trabalho. Não há valor padrão.

Para habilitar conexões keepalive com servidores upstream, você também deve incluir as seguintes diretivas na configuração:

proxy_http_version 1.1; proxy_set_header Conexão "";

Registro de acesso

O registro de cada solicitação consome ciclos de CPU e de E/S, e uma maneira de reduzir o impacto é habilitar o buffer de log de acesso. Com o buffer, em vez de executar uma operação de gravação separada para cada entrada de log, o NGINX armazena em buffer uma série de entradas e as grava no arquivo juntas em uma única operação.

Para habilitar o buffer do log de acesso, inclua o parâmetro buffer= size na diretiva access_log ; o NGINX grava o conteúdo do buffer no log quando o buffer atinge o valor de tamanho . Para que o NGINX grave o buffer após um período de tempo especificado, inclua o parâmetro flush= time . Quando ambos os parâmetros são definidos, o NGINX grava entradas no arquivo de log quando a próxima entrada de log não couber no buffer ou as entradas no buffer forem mais antigas que o tempo especificado, respectivamente. As entradas de log também são gravadas quando um processo de trabalho reabre seus arquivos de log ou é encerrado. Para desabilitar completamente o registro de acesso, inclua o parâmetro off na diretiva access_log .

Enviar arquivo

A chamada de sistema sendfile() do sistema operacional copia dados de um descritor de arquivo para outro, geralmente alcançando cópia zero, o que pode acelerar as transferências de dados TCP. Para permitir que o NGINX o utilize, inclua a diretiva sendfile no contexto http ou em um contexto de servidor ou local . O NGINX pode então gravar conteúdo em cache ou em disco em um soquete sem nenhuma troca de contexto para o espaço do usuário, tornando a gravação extremamente rápida e consumindo menos ciclos de CPU. Observe, no entanto, que como os dados copiados com sendfile() ignoram o espaço do usuário, eles não estão sujeitos à cadeia de processamento regular do NGINX e aos filtros que alteram o conteúdo, como gzip . Quando um contexto de configuração inclui a diretiva sendfile e diretivas que ativam um filtro de alteração de conteúdo, o NGINX desabilita automaticamente o sendfile para esse contexto.

Limites

Você pode definir vários limites que ajudam a evitar que os clientes consumam muitos recursos, o que pode prejudicar o desempenho do seu sistema, bem como a segurança e a experiência do usuário. Seguem algumas das diretivas relevantes:

• limit_conn e limit_conn_zone – Limitam o número de conexões de cliente que o NGINX aceita, por exemplo, de um único endereço IP. Defini-los pode ajudar a evitar que clientes individuais abram muitas conexões e consumam mais do que sua cota de recursos.
• limit_rate – Limita a taxa na qual as respostas são transmitidas a um cliente, por conexão (para que clientes que abrem várias conexões possam consumir essa quantidade de largura de banda para cada conexão). Definir um limite pode evitar que o sistema seja sobrecarregado por determinados clientes, garantindo uma qualidade de serviço mais uniforme para todos os clientes.
• limit_req e limit_req_zone – Limitam a taxa de solicitações processadas pelo NGINX, o que tem os mesmos benefícios de definir limit_rate . Eles também podem melhorar a segurança, especialmente para páginas de login, limitando a taxa de solicitação a um valor razoável para usuários humanos, mas muito lento para programas que tentam sobrecarregar seu aplicativo com solicitações (como bots em um ataque DDoS ).
• Parâmetro max_conns para a diretiva do servidor em um bloco de configuração upstream – Define o número máximo de conexões simultâneas aceitas por um servidor em um grupo upstream. Impor um limite pode ajudar a evitar que os servidores upstream fiquem sobrecarregados. Definir o valor como 0 (zero, o padrão) significa que não há limite.
• queue (NGINX Plus) – Cria uma fila na qual as solicitações são colocadas quando todos os servidores disponíveis no grupo upstream atingiram seu limite max_conns . Esta diretiva define o número máximo de solicitações na fila e, opcionalmente, o tempo máximo que elas esperam (60 segundos por padrão) antes que um erro seja retornado. As solicitações não serão enfileiradas se você omitir esta diretiva.

O cache e a compactação podem melhorar o desempenho

Alguns recursos adicionais do NGINX que podem ser usados para aumentar o desempenho de um aplicativo da web não se enquadram realmente no título de ajuste, mas vale a pena mencionar porque seu impacto pode ser considerável. Eles incluem cache e compactação.

Cache

Ao habilitar o cache em uma instância do NGINX que está balanceando a carga de um conjunto de servidores web ou de aplicativos, você pode melhorar drasticamente o tempo de resposta aos clientes e, ao mesmo tempo, reduzir drasticamente a carga nos servidores de back-end. O cache é um tópico à parte e não tentaremos abordá-lo aqui. Consulte o Guia de administração do NGINX Plus .

Compressão

Compactar as respostas enviadas aos clientes pode reduzir bastante seu tamanho, usando menos largura de banda de rede. No entanto, como a compactação de dados consome recursos da CPU, ela é mais útil quando realmente vale a pena reduzir o uso da largura de banda. É importante observar que você não deve habilitar a compactação para objetos que já estão compactados, como arquivos JPEG. Para obter mais informações, consulte o Guia de administração do NGINX Plus .

Para mais informações, consulte:

• Comparação do NGINX: Melhor precisão e resultados significativos (webinar sob demanda)
• Documentação de referência do NGINX em nginx.org
• Comparar modelos NGINX
• Especificações técnicas do NGINX Plus

Para experimentar o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para uma demonstração.