Teste de Estresse

Quais fatores afetam os resultados do teste de estresse?

• Latência da rede do gerador de carga até o servidor (recomenda-se testar na rede interna ou local)
• Largura de banda do gerador de carga até o servidor (recomenda-se testar na rede interna ou local)
• Se o HTTP keep-alive está ativado (recomenda-se ativar)
• Se o número de conexões simultâneas é suficiente (para testes na rede externa, deve-se tentar aumentar as conexões simultâneas)
• Se o número de processos no servidor é razoável (recomenda-se que o número de processos do serviço helloworld seja igual ao número de CPUs, e o número de processos do serviço de banco de dados seja quatro vezes o número de CPUs ou mais)
• Desempenho da própria aplicação (por exemplo, se um banco de dados externo está sendo utilizado)

O que é HTTP keep-alive?

O mecanismo HTTP Keep-Alive é uma técnica utilizada para enviar múltiplos pedidos e respostas HTTP em uma única conexão TCP, e tem um grande impacto nos resultados dos testes de desempenho. Desativar o keep-alive pode fazer com que o QPS diminua drasticamente. Atualmente, os navegadores têm o keep-alive ativado por padrão, o que significa que, após acessar um endereço HTTP, o navegador mantém a conexão temporariamente aberta e a reutiliza para solicitações subsequentes, melhorando assim o desempenho. Recomenda-se ativar o keep-alive durante os testes de estresse. Além disso, se o keep-alive não estiver ativado durante o teste, as portas locais do cliente rapidamente podem se esgotar no estado timewait, resultando em falhas na solicitação quando o número total de solicitações ultrapassa um certo limite (geralmente cerca de 28 mil).

Como ativar o HTTP keep-alive durante o teste de estresse?

Se você estiver usando o programa ab para o teste de estresse, precisa adicionar o parâmetro -k, por exemplo ab -n100000 -c200 -k http://127.0.0.1:8787/. O apipost precisa retornar o cabeçalho gzip para ativar o keep-alive (bug do apipost, consulte abaixo). Outros programas de teste geralmente têm o keep-alive ativado por padrão.

Por que o QPS do teste na rede externa é tão baixo?

A latência na rede externa geralmente resulta em um QPS baixo, o que é um fenômeno normal. Por exemplo, o QPS ao testar a página do baidu pode ser apenas algumas dezenas. Recomenda-se realizar testes na rede interna ou local para eliminar a influência da latência da rede. Se você precisa realmente testar na rede externa, pode aumentar o número de conexões simultâneas para aumentar a taxa de transferência (desde que a largura de banda seja suficiente).

Por que o desempenho diminui após passar pelo proxy nginx?

A execução do nginx consome recursos do sistema. Além disso, a comunicação entre o nginx e o webman também consome uma quantidade considerável de recursos. No entanto, os recursos do sistema são limitados, e o webman não pode acessar todos os recursos do sistema, portanto, é normal que o desempenho geral do sistema possa diminuir. Para minimizar o impacto no desempenho causado pelo proxy nginx, você pode considerar desativar os logs do nginx (access_log off;), e ativar o keep-alive entre o nginx e o webman, consulte nginx proxy.

Além disso, HTTPS consome mais recursos do que HTTP, pois o HTTPS requer a realização do handshake SSL/TLS, criptografia e descriptografia dos dados, e o tamanho dos pacotes aumenta, ocupando mais largura de banda, o que pode causar uma diminuição no desempenho. Se o teste for realizado com conexões curtas (sem ativar o HTTP keep-alive), cada solicitação exigirá a comunicação adicional do handshake SSL/TLS, resultando em uma significativa redução no desempenho. Recomenda-se ativar o HTTP keep-alive ao testar HTTPS.

Como saber se o sistema atingiu o limite de desempenho?

De modo geral, quando a CPU atinge 100%, isso indica que o desempenho do sistema atingiu o limite. Se a CPU ainda tiver capacidade ociosa, significa que o limite ainda não foi atingido, e você pode aumentar o número de conexões simultâneas para melhorar o QPS. Se aumentar as conexões simultâneas não aumentar o QPS, isso pode indicar que o número de processos do webman é insuficiente, então aumente adequadamente o número de processos do webman. Se ainda assim não conseguir melhorar, verifique se a largura de banda é suficiente.

Por que meu resultado do teste mostra que o desempenho do webman é inferior ao do framework gin do go?

Os testes de techempower mostram que o webman superou o gin em quase todas as métricas, como texto puro, consultas de banco de dados e atualizações de banco de dados. Se os seus resultados forem diferentes, pode ser que você esteja usando ORM no webman, o que trouxe uma grande perda de desempenho. Você pode tentar comparar webman + PDO nativo com gin + SQL nativo.

Quanto desempenho será perdido ao usar ORM no webman?

Aqui estão alguns dados de teste.

Ambiente
Servidor Alibaba Cloud com 4 núcleos e 4 GB, banco de dados MySQL local, consulta aleatória de um registro entre 100 mil, retorno em JSON, teste em máquina local.

Se usar PDO nativo
webman QPS é de 17.800

Se usar Db::table() do Laravel
webman QPS reduz para 9.400 QPS

Se usar Model do Laravel
webman QPS reduz para 7.200 QPS

Os resultados do thinkORM são semelhantes, sem grandes diferenças.

Dica
Embora o uso de ORM resulte em uma perda de desempenho, para 99% das aplicações, o desempenho já é amplamente satisfatório. Se você estiver na margem de 1% que exige melhor desempenho, pode facilmente resolver isso aumentando a CPU ou o servidor. Devemos encontrar um equilíbrio entre eficiência de desenvolvimento, manutenabilidade e desempenho, ao invés de buscar apenas o desempenho.

Por que o QPS dos testes com apipost é tão baixo?

O módulo de teste de estresse do apipost tem um bug, se o servidor não retornar o cabeçalho gzip, o keep-alive não pode ser mantido, resultando em uma grande queda no desempenho. A solução é comprimir os dados ao retornar e adicionar o cabeçalho gzip, por exemplo:

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

Além disso, em algumas circunstâncias, o apipost pode não conseguir gerar a carga desejada, mostrando que, com a mesma quantidade de conexões, o apipost tem um QPS cerca de 50% inferior ao do ab. Recomenda-se usar o ab, wrk ou outro software de teste de estresse profissional em vez do apipost.

Definindo um número apropriado de processos

O webman por padrão ativa um número de processos igual a cpu*4. Na verdade, para testes de desempenho do serviço helloworld, onde não há IO de rede, ter o número de processos igual ao número de núcleos da CPU proporciona o melhor desempenho, pois reduz a sobrecarga da troca de processos. Se o serviço envolver um banco de dados, redis ou IO de bloqueio, o número de processos pode ser definido entre 3 a 8 vezes o número de CPUs, pois nesse caso mais processos são necessários para aumentar a concorrência, enquanto a sobrecarga de troca de processos pode ser considerada irrelevante em relação ao IO de bloqueio.

Algumas faixas de referência para testes de estresse

Servidor na nuvem com 4 núcleos, 4 GB, 16 processos, teste local/rede interna

Dados de teste de terceiros do techempower

Exemplo de comandos de teste de estresse

ab

# 100000 solicitações, 200 concorrentes, keep-alive ativado
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 solicitações, 200 concorrentes, keep-alive desativado
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 concorrentes, teste por 10 segundos, keep-alive ativado (padrão)
wrk -c 200 -d 10s http://example.com