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.
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.
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 .
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 |
Utilizamos o seguinte software para os testes:
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 .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.
Medimos as seguintes métricas:
Para gerar todo o tráfego do cliente, usamos o wrk
com as seguintes opções:
-c
especifica o número de conexões TCP a serem criadas. Para nossos testes, definimos isso como 50 conexões.-d
especifica por quanto tempo gerar tráfego. Executamos nossos testes por 3 minutos cada.-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
.
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).
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:
-H
define o cabeçalho HTTP Connection:
close
).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.
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
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 .
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 |
A configuração a seguir foi usada no NGINX Plus Reverse Proxy . Observe os dois conjuntos de diretivas keepalive_timeout
e keepalive_requests
:
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; } } } }
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."