BLOG | NGINX

Guia de tamanhos do NGINX Plus: Como testamos

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Faisal Memon
Faisal Memon
Publicado em 29 de novembro de 2016

No início deste ano, avaliamos o desempenho do NGINX Plus e criamos um guia de dimensionamento para implantá-lo em servidores bare metal. NGINX Open Source e NGINX Plus são amplamente utilizados para balanceamento de carga da Camada 7 , também conhecido como balanceamento de carga de aplicativo .

[ Editor – Atualizamos o guia de dimensionamento periodicamente para refletir as mudanças nos recursos do NGINX Plus e nos custos e desempenho do hardware. O link acima é sempre para o guia mais recente.

Para obter informações sobre o desempenho do NGINX e do NGINX Plus como um servidor web, consulte Testando o desempenho dos servidores web NGINX e NGINX Plus .]

O guia de dimensionamento descreve o desempenho que você pode esperar alcançar com o NGINX Plus em execução em vários tamanhos de servidor, juntamente com os custos estimados para o hardware. Você pode usar o guia de dimensionamento para especificar adequadamente as implantações do NGINX Plus e evitar o provisionamento excessivo, que custa dinheiro imediatamente, ou o provisionamento insuficiente, que pode causar problemas de desempenho e custar dinheiro a longo prazo, tanto quanto possível.

Recebemos muito interesse no guia de dimensionamento, juntamente com perguntas sobre a metodologia que usamos, de clientes e outros interessados em reproduzir nossos resultados. Esta postagem do blog fornece uma visão geral dos testes que realizamos para alcançar os resultados apresentados no guia de dimensionamento. Ele aborda a topologia que usamos, os testes que executamos e como encontramos os preços listados no guia de dimensionamento.

Observação : Embora tenhamos desenvolvido o guia de dimensionamento especificamente para o NGINX Plus, usamos o NGINX Open Source para testes, para que qualquer pessoa possa reproduzir nossos testes sem uma assinatura do NGINX Plus. Os testes não exercem nenhum dos recursos aprimorados do NGINX Plus, então os resultados para o NGINX Open Source e o NGINX Plus são os mesmos. A versão 1.9.7 do NGINX Open Source corresponde aproximadamente ao NGINX Plus Release 7.

Entretanto, para distinguir melhor o proxy reverso do servidor web de backend na topologia de teste, nos referimos ao NGINX Plus para o primeiro e ao NGINX (Open Source) para o último.

Topologia

Todos os testes foram feitos usando três máquinas separadas conectadas entre si com links duplos de 40 GbE em uma rede simples e plana de Camada 2.

Uma topologia padrão back-to-back-to-back foi usada para testar o desempenho do NGINX Plus

Para gerar tráfego da máquina cliente, usamos o wrk , uma ferramenta de teste de desempenho semelhante ao ab (ApacheBench). Conforme mostrado no diagrama, todo o tráfego foi direcionado para o NGINX Plus Reverse Proxy , que encaminhou as conexões para o backend do NGINX Open Source Web Server .

Hardware usado

Usamos o seguinte hardware para os testes.

Máquina CPU Rede Memória
Cliente 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 núcleos reais (ou 72 HT) 2x Intel XL710 40GbE QSFP+ (rev 01) 16 GB
proxy reverso 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 núcleos reais (ou 72 HT) 4x Intel XL710 40GbE QSFP+ (rev 01) 16 GB
Servidor da web 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2,30 GHz, 36 núcleos reais (ou 72 HT) 2x Intel XL710 40GbE QSFP+ (rev 01) 16 GB

Software usado

Utilizamos o seguinte software para os testes:

  • A versão 4.0.0 do wrk em execução na máquina cliente gerou o tráfego que o NGINX enviou por proxy. Nós o instalamos de acordo com estas instruções .
  • A versão 1.9.7 do NGINX Open Source foi executada em máquinas de proxy reverso e servidor Web . Nós o instalamos a partir do repositório oficial em nginx.org de acordo com estas instruções .
  • O Ubuntu Linux 14.04.1 foi executado em todas as três máquinas.

Metodologia de Teste

Testamos o desempenho do servidor proxy reverso NGINX Plus com diferentes números de CPUs. Um processo de trabalho do NGINX Plus consome uma única CPU, então, para medir o desempenho de diferentes números de CPUs, variamos o número de processos de trabalho , repetindo os testes com dois processos de trabalho , quatro, oito e assim por diante. Para uma visão geral da arquitetura NGINX, consulte nosso blog .

Observação : Para definir manualmente o número de processos de trabalho , use a diretiva worker_processes . O valor padrão é auto , que informa ao NGINX Plus para detectar o número de CPUs e executar um processo de trabalho por CPU.

Métricas de desempenho

Medimos as seguintes métricas:

  • Solicitações por segundo (RPS) – Mede a capacidade de processar solicitações HTTP. Em nossos testes, cada cliente envia solicitações para um arquivo de 1 KB por meio de uma conexão keepalive. O Proxy Reverso processa cada solicitação e a encaminha para o Servidor Web por meio de outra conexão keepalive.
  • Transações SSL/TLS por segundo (TPS) – Mede a capacidade de processar novas conexões SSL/TLS. Em nossos testes, cada cliente envia uma série de solicitações HTTPS, cada uma em uma nova conexão. O proxy reverso analisa as solicitações e as encaminha para o servidor Web por meio de uma conexão keepalive estabelecida. O servidor Web envia uma resposta de 0 byte para cada solicitação.
  • Throughput – Mede o throughput que o NGINX Plus pode sustentar ao servir arquivos de 1 MB por HTTP.

Executando testes

Para gerar todo o tráfego do cliente, usamos o wrk com as seguintes opções:

  • A opção -c especifica o número de conexões TCP a serem criadas. Para nossos testes, definimos isso como 50 conexões.
  • A opção -d especifica por quanto tempo gerar tráfego. Executamos nossos testes por 3 minutos cada.
  • A opção -t especifica o número de threads a serem criados. Especificamos um único thread.

Para exercitar completamente cada CPU, usamos taskset , que pode fixar um único processo de trabalho em uma CPU. Este método produz resultados mais consistentes do que aumentar o número de threads de trabalho .

Solicitações por segundo

Para medir solicitações por segundo (RPS), executamos o seguinte script:

para i em `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; faça taskset -c $i wrk -t 1 -c 50 -d 180s http:// Endereço-IP-do-Servidor-Proxy-Reverso /1kb.bin & pronto

Este teste gerou uma cópia do wrk por CPU, 36 no total para nossa máquina cliente. Cada cópia criou 50 conexões TCP e fez solicitações contínuas de um arquivo de 1 KB por 3 minutos (180 segundos).

Transações SSL/TLS por segundo

Para medir transações SSL/TLS por segundo (TPS), executamos o seguinte script:

para i em `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; faça taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Conexão: fechar' https:// Endereço-IP-do-Servidor-Proxy-Reverso /0kb.bin & pronto

Este teste usa os mesmos valores para -c , -d e -t do teste anterior, mas difere em duas maneiras notáveis porque o foco está no processamento de conexões SSL/TLS:

  • O cliente abre e fecha uma conexão para cada solicitação (a opção -H define o cabeçalho HTTP Connection: close ).
  • O arquivo solicitado tem 0 (zero) bytes em vez de 1 KB de tamanho.

Taxa de transferência

Para medir a taxa de transferência, executamos o seguinte script:

para i em `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; faça taskset -c $i wrk -t 1 -c 50 -d 180s http:// Endereço-IP-do-Servidor-Proxy-Reverso /1mb.bin & pronto

A única diferença em relação ao primeiro teste é o tamanho do arquivo maior, de 1 MB. Descobrimos que usar um tamanho de arquivo ainda maior (10 MB) não aumentou o rendimento geral.

Várias placas de rede

Em nossos testes, usamos diversas placas de rede. O seguinte script ligeiramente modificado garantiu que o tráfego fosse distribuído uniformemente entre as duas placas:

para i em `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; faça n=`echo $(($i+ número-de-CPUs/2 ))`; taskset -c $i ./wrk -t 1 -c 50 -d 180s http:// Endereço-IP-1-do-Servidor-Proxy-Reverso /1kb.bin & taskset -c $n ./wrk -t 1 -c 50 -d 180s http:// Endereço-IP-2-do-Servidor-Proxy-Reverso /1kb.bin & feito

Preços

A etapa final, depois que obtivemos números de desempenho com diferentes números de núcleos, foi determinar o custo dos servidores com as especificações correspondentes. Usamos preços para servidores Dell PowerEdge com especificações semelhantes às do hardware Intel que usamos em nossos testes. O apêndice abaixo tem uma lista completa de materiais para cada servidor, juntamente com a configuração completa do NGINX para o Proxy Reverso e o Servidor Web .

Apêndice

Configurações de hardware da Dell

Os preços no guia de tamanhos são para as seguintes configurações de hardware Dell.

Observação : Os modelos de servidores com as especificações e preços indicados estavam disponíveis no momento em que realizamos nossos testes, mas estão sujeitos a alterações no futuro.

Modelo de servidor Especificações Preço
Dell PowerEdge R230 CPU: 2 núcleos Intel Core I3 6100 3,7 GHz, 2C/4T
BATER: 4GB
Disco rígido: 500 GB
Placa de rede: Intel X710 2×10 Gbe
$ 1.200
CPU: Intel® Xeon® E3‑1220 v5 3,0 GHz, 4C/8T
BATER: 4GB
Disco rígido: 500 GB
Placa de rede: Intel XL710 2×40 Gbe
$ 1.400
Dell PowerEdge R430 CPU: Intel® Xeon® E5‑2630 v3 2,4 GHz, 8C/16T
BATER: 4GB
Disco rígido: 500 GB
Placa de rede: Intel XL710 2×40 Gbe
$ 2.200
CPU: 2x Intel® Xeon® E5‑2630 v3 2,4 GHz, 8C/16T
BATER: 8 GB
Disco rígido: 500 GB
Placa de rede: Intel XL710 2×40 Gbe
$ 3.000
Dell PowerEdge R630 CPU: 2x Intel® Xeon® E5‑2697A v4 2,6 GHz, 16C/32T
BATER: 8 GB
Disco rígido: 500 GB
Placa de rede: Intel XL710 2×40 Gbe
$ 8.000
CPU: 2x Intel® Xeon® E5‑2699 v3 2,3 GHz, 18C/36T
BATER: 8 GB
Disco rígido: 500 GB
Placa de rede: Intel XL710 2×40 Gbe
$ 11.000

Configuração do proxy reverso NGINX Plus

A configuração a seguir foi usada no NGINX Plus Reverse Proxy . Observe os dois conjuntos de diretivas keepalive_timeout e keepalive_requests :

  • Para testes SSL/TLS TPS, definimos os valores para ambas as diretivas para que as conexões permanecessem abertas para apenas uma solicitação, já que o objetivo desse teste é ver quantas conexões SSL/TLS por segundo o NGINX Plus pode processar. O cache de sessão SSL/TLS também foi desabilitado.
  • Para os testes RPS, as diretivas foram ajustadas para manter as conexões ativas pelo maior tempo possível.

A configuração é uma configuração de servidor proxy reverso bastante padrão, com o NGINX Plus fazendo proxy para um servidor web usando a diretiva proxy_pass .

usuário nginx;processos_de_trabalhador auto; worker_rlimit_nofile 10240; pid /var/run/nginx.pid; eventos { conexões_de_trabalhador 10240; accept_mutex desativado; multi_accept desativado; } http { log_de_acesso desativado; incluir /etc/nginx/mime.types; tipo_padrão aplicativo/fluxo_de_octeto; formato_de_log principal '$endereço_remoto - $usuário_remoto [$tempo_local] "$solicitação" ' '$status $body_bytes_sent "$http_referer" ' '"$http_usuário_agent" "$http_x_forwarded_for" "$cifra_ssl" ' '"$protocolo_ssl" '; sendfile ativado; # Testes RPS keepalive_timeout 300s; keepalive_requests 1000000; # Testes SSL/TLS TPS #keepalive_timeout 0; #keepalive_requests 1; servidor web upstream { servidor Endereço-IP-do-servidor-web ; } servidor { escutar 80; escutar 443 ssl backlog=102400 reuseport; certificado_ssl /etc/nginx/ssl/rsa-cert.crt; chave_certificado_ssl /etc/nginx/ssl/rsa-key.key; ssl_session_tickets off; cache_session_ssl off; raiz /var/www/html; localização / { senha_proxy http://servidor-web; } } } }

Configuração do servidor web NGINX

A configuração abaixo foi usada no servidor Web NGINX. Ele serve arquivos estáticos de /var/www/html/ , conforme configurado pela diretiva root . Os arquivos estáticos foram gerados usando dd ; este exemplo cria um arquivo de 1 KB de zeros:

dd if=/dev/zero de=1kb.bin bs=1KB contagem=1

A configuração:

usuário nginx;
processos_de_trabalhador auto;
limite_de_trabalhador_r_nofile 10240;
pid /var/run/nginx.pid;

eventos {
conexões_de_trabalhador 10240;
aceitar_mutex desativado;
multi_aceitar desativado;
}

http {
log_de_acesso desativado;
incluir /etc/nginx/mime.types;
tipo_padrão aplicativo/fluxo_de_octeto;

formato_de_log principal '$endereço_remoto - $usuário_remoto [$tempo_local] "$solicitação" '
'$status $bytes_corpo_enviado "$http_referer" '
'"$http_usuário_agent" "$http_x_encaminhado_para" "$cifra_ssl" '
'"$protocolo_ssl" ';

enviar_arquivo ativado;

tempo_limite_de_manutenção_de_atividade 300s; keepalive_requests 1000000;

servidor {
ouvir 80;
raiz /var/www/html;
}
}

Para experimentar o NGINX Plus, comece hoje mesmo um teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."