Conversamos sobre a metodologia em artigo, neste testamos HTTPS, mas em cenários mais realistas. Para teste, obtivemos um certificado Let's Encrypt e habilitamos a compactação Brotli para 11.
Desta vez tentaremos reproduzir o cenário de implantação de um servidor em um VDS ou como uma máquina virtual em um host com processador padrão. Para tanto, foi estabelecido um limite em:
- 25% – O que equivale a uma frequência de ~1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
O número de conexões únicas foi reduzido de 500 para 1, 3, 5, 7 e 9,
Resultados:
Atrasos:
O TTFB foi incluído especificamente como um teste separado, porque as ferramentas HTTPD criam um novo usuário para cada solicitação individual. Este teste ainda está bastante distante da realidade, pois o usuário ainda clicará em algumas páginas e, na realidade, o TTFP terá o papel principal.
A primeira, geralmente a primeira solicitação após a primeira inicialização da máquina virtual IIS, leva em média 120 ms.
Todas as solicitações subsequentes mostram um TTFP de 1.5 ms. Apache e Nginx estão atrasados nesse aspecto. Pessoalmente, o autor considera este teste o mais revelador e escolheria o vencedor apenas com base nele.
O resultado não é surpreendente, pois o IIS armazena em cache o conteúdo estático já compactado e não o compacta toda vez que é acessado.
Tempo gasto por cliente
Para avaliar o desempenho, é suficiente um teste com 1 única conexão.
Por exemplo, o IIS concluiu um teste de 5000 usuários em 40 segundos, ou seja, 123 solicitações por segundo.
Os gráficos abaixo mostram o tempo até que o conteúdo do site seja completamente transferido. Esta é a proporção de solicitações concluídas em um determinado período. No nosso caso, 80% de todas as solicitações foram processadas em 8ms no IIS e em 4.5ms no Apache e Nginx, e 8% de todas as solicitações no Apache e Nginx foram concluídas em um intervalo de até 98 milissegundos.
Tempo durante o qual 5000 solicitações foram processadas:
Tempo durante o qual 5000 solicitações foram processadas:
Se você possui uma máquina virtual com CPU de 3.5 GHz e 8 núcleos, escolha o que deseja. Todos os servidores web são muito semelhantes neste teste. Falaremos sobre qual servidor web escolher para cada host a seguir.
Quando se trata de uma situação um pouco mais realista, todos os servidores web se enfrentam.
Taxa de transferência:
Gráfico de atrasos versus número de conexões simultâneas. Quanto mais suave e mais baixo, melhor. Os últimos 2% foram removidos dos gráficos porque os tornariam ilegíveis.
Agora vamos considerar a opção onde o servidor está hospedado na hospedagem virtual. Vamos pegar 4 núcleos a 2.2 GHz e um núcleo a 1.8 GHz.
Como escalar
Se você já viu como são as características de corrente-tensão de triodos de vácuo, pentodos e assim por diante, esses gráficos serão familiares para você. É isso que estamos tentando capturar: saturação. O limite é quando não importa quantos núcleos você jogue, o aumento de desempenho não será perceptível.
Anteriormente, todo o desafio era processar 98% das solicitações com a menor latência para todas as solicitações, mantendo a curva o mais plana possível. Agora, construindo outra curva, encontraremos o ponto ótimo de operação para cada um dos servidores.
Para fazer isso, vamos usar o indicador Solicitações por segundo (RPR). Horizontal é a frequência, vertical é o número de solicitações processadas por segundo, linhas são o número de núcleos.
Mostra uma correlação de quão bem o Nginx processa solicitações uma após a outra. 8 núcleos têm melhor desempenho neste teste.
Este gráfico mostra claramente o quão melhor (não muito) o Nginx funciona em um único núcleo. Se você possui Nginx, considere reduzir o número de núcleos para um se estiver hospedando apenas núcleos estáticos.
O IIS, embora tenha o TTFB mais baixo de acordo com o DevTools no Chrome, consegue perder tanto para o Nginx quanto para o Apache em uma briga séria com o teste de estresse da Apache Foundation.
Toda a curvatura dos gráficos é reproduzida com ferro.
Algum tipo de conclusão:
Sim, o Apache funciona pior em 1 e 8 núcleos, mas funciona um pouco melhor em 4.
Sim, o Nginx em 8 núcleos processa melhor as solicitações uma após a outra, em 1 e 4 núcleos, e funciona pior quando há muitas conexões.
Sim, o IIS prefere 4 núcleos para cargas de trabalho multithread e prefere 8 núcleos para cargas de trabalho de thread único. No final das contas, o IIS foi um pouco mais rápido do que todos os outros em 8 núcleos sob alta carga, embora todos os servidores estivessem no mesmo nível.
Este não é um erro de medição, o erro aqui não é superior a +-1ms. em atrasos e não mais que +- 2-3 solicitações por segundo para RPR.
Os resultados onde 8 núcleos apresentam pior desempenho não são nada surpreendentes, muitos núcleos e SMT/Hyperthreading degradam bastante o desempenho se tivermos um período de tempo em que temos que concluir todo o pipeline.
Fonte: habr.com