OpenResty FAQ | Estrutura de Rede para Testes, Recursos Relacionados a SSL, DSL, Ferramenta `ab`

A série de artigos do OpenResty foi atualizada até agora, e já concluímos a parte sobre testes. Parabéns por não ficar para trás, por aprender e praticar operações ativamente, e por deixar entusiasticamente seus pensamentos.

Muitas das perguntas levantadas nos comentários são valiosas, e algumas das mais típicas e interessantes foram especialmente extraídas como o Q&A de hoje.

Vamos dar uma olhada nessas cinco questões hoje.

Pergunta 1: Como construir a estrutura de rede para testes?

Q: O cliente que executa o wrk deve ser colocado em uma máquina na rede externa ou em uma máquina na mesma LAN que o servidor? Qual desses dois é mais significativo para testes de desempenho?

R: Para testar serviços relacionados à web, escolher a ferramenta de teste certa é apenas um bom começo, e como construir a estrutura de rede para testes também é uma parte essencial do acompanhamento.

Geralmente, queremos testar os limites de desempenho do serviço sozinho, excluindo todas as interferências da rede. Para isso, podemos ter duas maneiras de construir a rede para fazer o teste de estresse.

O primeiro método é implantar o wrk e as aplicações do servidor na mesma máquina com bom desempenho. Por exemplo, podemos ativar oito workers no NGINX e dividir os recursos restantes da CPU entre o wrk, então há apenas comunicação de rede local, minimizando o impacto da rede.

O segundo método é construir uma LAN com um roteador dedicado e conectar a máquina onde o wrk está localizado à máquina onde o servidor está localizado.

Não é recomendado testar diretamente em uma rede existente porque a maioria das redes tem switches e firewalls, que podem limitar o teste de estresse de grandes volumes de tráfego e causar resultados de teste imprecisos.

Além disso, gostaria de mencionar mais algumas palavras sobre ferramentas de teste de desempenho. Primeiro, as ferramentas de teste de desempenho podem ter problemas de Coordinated Omission, que você deve prestar atenção especial ao analisar os dados de latência da ferramenta.

Coordinated Omission significa que, ao fazer testes de desempenho, não é suficiente contar o tempo entre o envio e o recebimento de uma resposta, que é apenas o tempo de serviço, então as estatísticas perderão muitos problemas potenciais. Portanto, também precisamos incluir o tempo de espera da solicitação de teste, que no geral é o tempo de resposta que os usuários se importam. Claro, se o seu programa do lado do servidor pode estar bloqueando, você só precisa considerar essa questão. Caso contrário, você pode ignorá-la.

Pergunta 2: O test::nginx pode testar recursos relacionados ao SSL?

Q: É impossível testar recursos relacionados ao SSL com o test::nginx?

R: Isso não é verdade. O test::nginx pode testar recursos relacionados ao SSL; você pode consultar ssl.t. Este arquivo de caso de teste testa todo o processo do certificado SSL. Primeiro, como você pode ver, o caso de teste usa código Lua para ler as chaves pública e privada do certificado local; então, ele configura o certificado através da API HTTP; finalmente, ele usa cosocket para fazer o handshake SSL e o acesso para verificar se o certificado é válido.

Na verdade, não apenas o SSL, mas também os recursos incluídos no OpenResty podem ser sobrescritos usando o test::nginx.

Quando você não tem certeza se um recurso específico pode ser implementado com o test::nginx, você pode primeiro pesquisar os casos de teste do lua-nginx-module e outros projetos de código aberto do OpenResty, e você geralmente pode encontrar exemplos correspondentes. Afinal, o test::nginx é muito jogável e variável, e algumas combinações e truques inesperados estão esperando para serem descobertos.

Pergunta 3: O que exatamente é DSL?

Q: O que exatamente são DSL e test::nginx?

R: DSL significa Domain Specific Language. O propósito do DSL é diferente das linguagens de desenvolvimento comuns. Ele não é para resolver as necessidades de um domínio geral, mas de algum domínio. O DSL mais famoso é o SQL, a Structured Query Language usada no domínio de banco de dados.

Quanto ao test::nginx, ele é um DSL criado para atender às necessidades de teste do NGINX e do OpenResty. Na verdade, os autores do OpenResty inventaram muitas ideias de DSL e trouxeram muitas novas tentativas e soluções para a comunidade OpenResty. No entanto, como mencionado no artigo anterior, o DSL é uma faca de dois gumes, e o principal critério para medir o valor do DSL é se ele pode trazer melhoria de produtividade para os usuários finais.

Pergunta 4: Problema de instalação do test::nginx

Q: Depois de executar o git clone, preciso executar o seguinte comando para instalar o test::nginx?

cd test-nginx
perl Makefile.PL
make
sudo make install

R: Na verdade, isso não é necessário. Aqui você pode consultar alguns projetos de código aberto.

Passo 1: instale-o via o gerenciador de pacotes

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

Passo 2: git clone o test::nginx mais recente

git clone https://github.com/openresty/test-nginx.git test-nginx

Passo 3: inclua o diretório test-nginx quando você usar o comando prove

prove -Itest-nginx/lib -r t

Como mencionei anteriormente, os melhores guias para instalar o OpenResty e os projetos ao redor estão no CI, não na documentação. Isso pode ser diferente de outros projetos, principalmente porque o OpenResty mantém seu próprio fork ou versões específicas de alguns dos projetos ao redor e porque o OpenResty também é fortemente dependente do CI. Portanto, você deve usar e testar o OpenResty da mesma forma que ele é construído no CI para garantir consistência com o oficial.

Pergunta 5: A ferramenta de teste ab é boa ou não?

Q: Como eu me lembro de Yichun Zhang frequentemente mencionar o ab como a melhor ferramenta de teste no Google Groups?

R: Como mencionei no artigo, o ab não é uma boa ferramenta de teste de desempenho em termos de recursos da ferramenta, porque ele não pode gerar pressão de solicitação suficiente. No entanto, o desempenho do programa do lado do servidor é poderoso agora. Usamos o ab em vez do wrk no test::nginx porque no modo TEST_NGINX_BENCHMARK, o test::nginx usa o ab ou o weighttp, dependendo da versão do protocolo HTTP, como a ferramenta para teste de desempenho.

Além disso, espero que você note que a tecnologia da Internet está mudando muito rapidamente, e cada um de nós precisa atualizar nossos conhecimentos e habilidades em tempo. Por exemplo, na minha opinião, essa escolha do test::nginx agora precisa ser atualizada, e Yichun Zhang pode não saber da existência do wrk naquela época. Claro, talvez haja ferramentas de teste de desempenho melhores do que o wrk no futuro, e devemos naturalmente ter uma mente positiva e aberta para aprender e escolher.

Hoje, respondi principalmente às perguntas mencionadas acima. Espero que, através da comunicação e Q&A, eu possa ajudá-lo a transformar o que você aprende no que você obtém. Você também é bem-vindo a encaminhar este artigo para que possamos nos comunicar e progredir juntos.