Guia de dimensionamento do NGINX Plus: como realizamos os testes

Faisal MemonEngenheiro de Software

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 aplicações.

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

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

O guia de dimensionamento descreve o desempenho que você pode esperar obter ao executar o NGINX Plus em servidores de vários portes, juntamente com os custos estimados do hardware. Você pode usar o guia de dimensionamento para definir adequadamente as especificações das implantações do NGINX Plus e evitar, tanto quanto possível, o superdimensionamento – que gera custos imediatos – ou o subdimensionamento – que pode causar problemas de desempenho e gerar custos a longo prazo.

O guia de dimensionamento despertou muito interesse, e recebemos perguntas de clientes e de outras pessoas interessadas em reproduzir nossos resultados sobre a metodologia que utilizamos. Esta publicação no blog apresenta uma visão geral dos testes que realizamos para chegar aos resultados apresentados no guia de dimensionamento. Ela aborda a topologia utilizada, os testes executados e como determinamos os preços indicados no guia de dimensionamento.

Observação: embora tenhamos desenvolvido o guia de dimensionamento especificamente para o NGINX Plus, usamos o NGINX Open Source nos testes para que qualquer pessoa possa reproduzi-los sem uma assinatura do NGINX Plus. Os testes não utilizam nenhum dos recursos avançados do NGINX Plus, portanto, os resultados do NGINX Open Source e do NGINX Plus são os mesmos. A versão 1.9.7 do NGINX Open Source corresponde aproximadamente à versão 7 do NGINX Plus.

No entanto, para diferenciar melhor o proxy reverso do servidor web de backend na topologia de teste, usamos NGINX Plus para nos referirmos ao primeiro e NGINX (Open Source) para nos referirmos ao segundo.

Topologia

Todos os testes foram realizados usando três máquinas distintas, interconectadas por dois links de 40 GbE em uma rede simples e plana de Camada 2.

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

Hardware utilizado

Usamos o seguinte hardware para os testes.

Máquina CPU Rede MemóriaCliente 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 36 núcleos reais (ou 72 HT) 2x Intel XL710 40GbE QSFP+ (rev. 01) 16 GBProxy reverso 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 36 núcleos reais (ou 72 HT) 4x Intel XL710 40GbE QSFP+ (rev. 01) 16 GBServidor web 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 36 núcleos reais (ou 72 HT) 2x Intel XL710 40GbE QSFP+ (rev. 01) 16 GB

Software utilizado

Usamos os seguintes softwares para os testes:

• A versão 4.0.0 do wrk executada na máquina cliente gerou o tráfego encaminhado pelo NGINX. Nós a instalamos de acordo com estas instruções.
• A versão 1.9.7 do NGINX Open Source foi executada nas máquinas de proxy reverso e servidor web. Nós a instalamos usando o repositório oficial em nginx.org, de acordo com estas instruções.
• Ubuntu Linux 14.04.1 foi executado nas três máquinas.

Metodologia de Testes

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

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

Métricas de desempenho

Medimos as seguintes métricas:

• Requisições por segundo (RPS) – Mede a capacidade de processar requisições HTTP. Em nossos testes, cada cliente envia requisições de um arquivo de 1 KB por meio de uma conexão persistente. O Proxy Reverso processa cada requisição e a encaminha para o Servidor Web por meio de outra conexão persistente.
• 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 ao Servidor Web por meio de uma conexão keepalive estabelecida. O Servidor Web retorna uma resposta de 0 byte para cada solicitação.
• Taxa de transferência – Mede a taxa de transferência que o NGINX Plus consegue sustentar ao disponibilizar arquivos de 1 MB via HTTP.

Executando testes

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

• A opção -c especifica o número de conexões TCP a serem criadas. Em nossos testes, definimos esse valor como 50 conexões.
• A opção -d especifica por quanto tempo o tráfego deve ser gerado. Executamos cada teste por 3 minutos.
• A opção -t especifica o número de threads a serem criadas. Especificamos uma única thread.

Para utilizar plenamente cada CPU, usamos o taskset, que pode vincular um único processo do wrk a uma CPU. Esse método produz resultados mais consistentes do que aumentar o número de threads do wrk.

Requisições por segundo

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin &
done

Esse teste iniciou uma instância do wrk por CPU, totalizando 36 em nossa máquina cliente. Cada instância criou 50 conexões TCP e fez solicitações contínuas de um arquivo de 1 KB por meio delas durante 3 minutos (180 segundos).

Transações SSL/TLS por segundo

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin &
done

Este teste usa os mesmos valores para -c, -d e -t que o teste anterior, mas apresenta duas diferenças importantes, pois 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: como close).
• O arquivo solicitado tem 0 (zero) bytes, em vez de 1 KB.

Taxa de transferência

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin &
done

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

Várias placas de rede

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

for i in `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; do    n=`echo $(($i+number-of-CPUs/2))`;
    taskset -c $i ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-1/1kb.bin &
    taskset -c $n ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-2/1kb.bin &
done

Preços

A etapa final, depois de obtermos os números de desempenho com diferentes quantidades de núcleos, foi determinar o custo dos servidores com as especificações correspondentes. Usamos os preços de servidores Dell PowerEdge com especificações semelhantes às do hardware Intel utilizado em nossos testes. O apêndice abaixo contém uma lista completa de materiais para cada servidor, além da configuração completa do NGINX tanto para o proxy reverso quanto para o servidor web.

Apêndice

Configurações de hardware da Dell

Os preços no guia de dimensionamento referem-se às seguintes configurações de hardware da Dell.

Observação: os modelos de servidor com as especificações e os preços indicados estavam disponíveis quando realizamos nossos testes, mas podem sofrer alterações no futuro.

Modelo do servidor Especificações PreçoDell PowerEdge R230 CPU: Intel Core i3 6100 de 2 núcleos, 3,7 GHz, 2C/4T
RAM: 4 GB
HDD: 500 GB
NIC: Intel X710 2×10 GbE US$ 1.200CPU: Intel® Xeon® E3‑1220 v5 3,0 GHz, 4C/8T
RAM: 4 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE US$ 1.400Dell PowerEdge R430 CPU: Intel® Xeon® E5‑2630 v3 2,4 GHz, 8C/16T
RAM: 4 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE US$ 2.200CPU: 2x Intel® Xeon® E5‑2630 v3 2,4 GHz, 8C/16T
RAM: 8 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE US$ 3.000Dell PowerEdge R630 CPU: 2x Intel® Xeon® E5‑2697A v4 2,6 GHz, 16C/32T
RAM: 8 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE US$ 8.000CPU: 2x Intel® Xeon® E5‑2699 v3 2,3 GHz, 18C/36T
RAM: 8 GB
HDD: 500 GB
NIC: Intel XL710 2×40 GbE US$ 11.000

Configuração do proxy reverso do NGINX Plus

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

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

Fora isso, a configuração é bastante convencional para um servidor proxy reverso, com o NGINX Plus encaminhando as solicitações para um servidor web por meio da diretiva proxy_pass.

user                 nginx;worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log    off;
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    # RPS tests
    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    # SSL/TLS TPS tests
    #keepalive_timeout  0;  
    #keepalive_requests 1; 
  
    upstream webserver {
        server Web-Server-IP-address;
    }

    server {
        listen 80;
        listen 443 ssl backlog=102400 reuseport;

        ssl_certificate     /etc/nginx/ssl/rsa-cert.crt;
        ssl_certificate_key /etc/nginx/ssl/rsa-key.key;
        ssl_session_tickets off;
        ssl_session_cache   off;

        root /var/www/html;
            location / {
                proxy_pass http://webserver;
            }
        }
    }
}

Configuração do servidor web NGINX

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

dd if=/dev/zero of=1kb.bin bs=1KB count=1

A configuração:

user                 nginx;
worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log   off;
    include      /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
                    '"$ssl_protocol" ';

    sendfile on;

    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    server {
        listen 80;
        root /var/www/html;
    }
}

Para experimentar o NGINX Plus, inicie hoje mesmo uma avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Faisal MemonEngenheiro de Software

Mais publicações de Faisal Memon