Ajustando o NGINX para melhorar o desempenho

Rick NelsonVice-presidente regional de Engenharia de Soluções

O NGINX é amplamente conhecido como um balanceador de carga de alto desempenho, além de atuar como cache e servidor web, sendo usado por mais de 40% dos sites com maior tráfego do mundo. Para a maioria dos casos de uso, as configurações padrão do NGINX e do Linux funcionam bem, mas alcançar o desempenho ideal às vezes exige alguns ajustes. Este artigo aborda algumas das configurações do NGINX e do Linux que devem ser consideradas ao otimizar um sistema.

É possível ajustar praticamente qualquer configuração, mas este artigo se concentra nas poucas configurações cujo ajuste beneficia a maioria dos usuários. Recomendamos que algumas configurações sejam alteradas somente se você tiver um conhecimento profundo do NGINX e do Linux ou conforme a orientação de nossas equipes de Suporte ou Serviços Profissionais, e elas não são abordadas aqui. A equipe de Serviços Profissionais já trabalhou com alguns dos sites mais movimentados do mundo para ajustar o NGINX e obter o nível máximo de desempenho, e está disponível para ajudar você a aproveitar ao máximo sua implantação do NGINX ou NGINX Plus.

Introdução

Pressupõe-se um conhecimento básico da arquitetura do NGINX e dos conceitos de configuração. Este artigo não pretende reproduzir a documentação do NGINX, mas apresenta uma visão geral das diversas opções e links para a documentação relevante.

Uma boa regra a seguir ao fazer ajustes é alterar uma configuração por vez e restaurá-la ao valor padrão caso a mudança não melhore o desempenho.

Começamos com uma discussão sobre o ajuste do Linux, pois os valores de algumas configurações do sistema operacional determinam como você deve ajustar a configuração do NGINX.

Ajustando sua configuração do Linux

As configurações dos kernels Linux modernos (2.6 ou posteriores) são adequadas para a maioria das finalidades, mas alterar algumas delas pode ser benéfico. Verifique se há mensagens de erro no log do kernel indicando que o valor de uma configuração está muito baixo e ajuste-o conforme recomendado. Aqui, abordamos apenas as configurações que têm maior probabilidade de se beneficiar de ajustes sob cargas de trabalho normais. Para obter detalhes sobre como ajustar essas configurações, consulte a documentação do Linux.

A fila de backlog

As configurações a seguir estão relacionadas às conexões e à forma como elas são enfileiradas. Se você recebe um grande volume de conexões e observa níveis de desempenho irregulares (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 valor padrão costuma ser muito baixo, o que geralmente é aceitável porque o NGINX aceita conexões muito rapidamente, mas pode valer a pena aumentá-lo se o seu site receber muito tráfego. Se as mensagens de erro no log do kernel indicarem que o valor é muito baixo, aumente-o até que os erros parem.Observação: Se você definir esse parâmetro com um valor superior a 512, altere o parâmetro backlog da diretiva listen do NGINX para que corresponda a esse valor.
• net.core.netdev_max_backlog – A taxa na qual os pacotes são armazenados em buffer pela placa de rede antes de serem encaminhados à CPU. Aumentar esse valor pode melhorar o desempenho em máquinas com alta largura de banda. Verifique se há erros relacionados a essa configuração no log do kernel e consulte a documentação da placa de rede para obter orientações sobre como alterá-la.

Descritores de arquivos

Descritores de arquivo são recursos do sistema operacional usados para representar conexões e arquivos abertos, entre outras coisas. O NGINX pode usar até dois descritores de arquivo por conexão. Por exemplo, quando atua como proxy, o NGINX geralmente usa um descritor de arquivo para a conexão do cliente e outro para a conexão com o servidor de destino, embora essa proporção seja muito menor quando conexões HTTP persistentes são usadas. Em um sistema que atende a um grande número de conexões, talvez seja necessário ajustar as seguintes configurações:

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

Portas efêmeras

Quando o NGINX atua como proxy, cada conexão com um servidor upstream usa uma porta temporária, ou efêmera,. Talvez seja conveniente 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 as portas estão se esgotando, aumente o intervalo. Uma configuração comum é usar as portas de 1024 a 65000.

Ajustando sua configuração do NGINX

A seguir estão algumas diretivas do NGINX que podem afetar o desempenho. Conforme mencionado acima, abordamos apenas as diretivas que você pode ajustar por conta própria com segurança. Recomendamos que você não altere as configurações de outras diretivas sem a 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 as conexões usando 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 essa diretiva como auto para obter esse resultado. Em alguns casos, pode ser necessário aumentar esse número, por exemplo, quando os processos de trabalho precisam realizar muitas operações de E/S em disco.
• worker_connections – O número máximo de conexões que cada processo de trabalho pode gerenciar simultaneamente. O padrão é 512, mas a maioria dos sistemas tem recursos suficientes para comportar um número maior. A configuração adequada depende do porte do servidor e da natureza do tráfego e pode ser determinada por meio de testes.

Conexões keepalive

Conexões keepalive podem ter um grande impacto no desempenho, reduzindo a sobrecarga de CPU e de rede necessária para abrir e fechar conexões. O NGINX encerra todas as conexões dos clientes e cria conexões separadas e independentes com os servidores upstream. O NGINX oferece suporte a keepalive tanto para clientes quanto para servidores upstream. As diretivas a seguir estão relacionadas ao keepalive dos clientes:

• keepalive_requests – O número de solicitações que um cliente pode fazer por meio de 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 – Por quanto tempo uma conexão keepalive ociosa permanece aberta.

A diretiva a seguir está relacionada a conexões keepalive com servidores upstream:

• keepalive – O número de conexões keepalive ociosas com um servidor upstream que permanecem abertas para cada processo worker. 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 Connection "";

Registro de acesso

O registro de cada solicitação consome ciclos de CPU e de E/S. Uma forma de reduzir esse impacto é habilitar o armazenamento em buffer do log de acesso. Com esse recurso, em vez de realizar uma operação de gravação separada para cada entrada de log, o NGINX armazena uma série de entradas em buffer e as grava no arquivo de uma só vez.

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 size. Para que o NGINX grave o buffer após um período especificado, inclua o parâmetro flush=time. Quando ambos os parâmetros estão definidos, o NGINX grava as entradas no arquivo de log quando a próxima entrada não cabe no buffer ou quando as entradas no buffer são mais antigas que o período 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 log de acesso, inclua o parâmetro off na diretiva access_log.

Sendfile

A chamada de sistema sendfile() do sistema operacional copia dados de um descritor de arquivo para outro, muitas vezes sem realizar cópias, o que pode acelerar as transferências de dados via TCP. Para permitir que o NGINX a utilize, inclua a diretiva sendfile no contexto http ou em um contexto server ou location. Assim, o NGINX pode gravar conteúdo armazenado em cache ou em disco diretamente 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. No entanto, como os dados copiados com sendfile() ignoram o espaço do usuário, eles não passam pela cadeia de processamento normal do NGINX nem por filtros que alteram o conteúdo, como gzip. Quando um contexto de configuração inclui tanto a diretiva sendfile quanto diretivas que ativam um filtro de alteração de conteúdo, o NGINX desativa automaticamente a diretiva sendfile nesse contexto.

Limites

Você pode definir vários limites para evitar que os clientes consumam recursos em excesso, o que pode afetar negativamente o desempenho do sistema, a segurança e a experiência do usuário. Estas são algumas das diretivas relevantes:

• limit_conn e limit_conn_zone – Limitam o número de conexões de clientes aceitas pelo NGINX, por exemplo, de um único endereço IP. Configurá-las pode ajudar a impedir que clientes individuais abram conexões demais e consumam mais recursos do que sua cota.
• limit_rate – Limita a taxa de transmissão das respostas para um cliente por conexão (portanto, clientes que abrem várias conexões podem consumir essa quantidade de largura de banda em cada conexão). Definir um limite pode evitar que determinados clientes sobrecarreguem o sistema, 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, oferecendo os mesmos benefícios da configuração de limit_rate. Também podem aumentar a segurança, especialmente em páginas de login, limitando a taxa de solicitações a um valor adequado para usuários humanos, mas lento demais para programas que tentam sobrecarregar sua aplicação com solicitações (como bots em um ataque DDoS).
• max_conns parâmetro da diretiva server 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 de upstream. A imposição de um limite pode ajudar a evitar a sobrecarga dos servidores upstream. 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 atingem o limite de max_conns. Essa diretiva define o número máximo de solicitações na fila e, opcionalmente, o tempo máximo de espera (60 segundos por padrão) antes que um erro seja retornado. As solicitações não são enfileiradas se essa diretiva for omitida.

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

Alguns recursos adicionais do NGINX que podem ser usados para melhorar o desempenho de uma aplicação web não se enquadram exatamente na categoria de otimização, mas vale a pena mencioná-los, pois seu impacto pode ser considerável. Entre eles estão o armazenamento em cache e a compactação.

Cache

Ao habilitar o cache em uma instância do NGINX que esteja fazendo o balanceamento de carga de um conjunto de servidores web ou de aplicativos, você pode melhorar significativamente o tempo de resposta aos clientes e, ao mesmo tempo, reduzir drasticamente a carga nos servidores de backend. O cache é um assunto à parte e não tentaremos abordá-lo aqui. Consulte o Guia de Administração do NGINX Plus.

Compactação

Compactar as respostas enviadas aos clientes pode reduzir significativamente o tamanho delas, fazendo com que consumam menos largura de banda da 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á estejam compactados, como arquivos JPEG. Para obter mais informações, consulte o Guia de Administração do NGINX Plus.

Para obter mais informações, consulte:

• Benchmarking do NGINX: mais precisão e resultados relevantes (webinar sob demanda)
• Documentação de referência do NGINX em nginx.org
• Compare os modelos do NGINX
• Especificações técnicas do NGINX Plus

Para experimentar o NGINX Plus, inicie sua avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para solicitar uma demonstração.

Sobre o autor

Rick NelsonVice-presidente regional de Engenharia de Soluções

Mais publicações de Rick Nelson