Falamos sobre a metodologia em artigos, e neste estamos testando HTTPS, mas em cenários mais realistas. Para o teste, foi obtido um certificado Let's Encrypt, e a compressão Brotli foi ativada em 11.
Desta vez, tentaremos reproduzir um cenário de implantação de servidor em VDS ou como uma máquina virtual em um host com um processador padrão. Para isso, estabelecemos um limite de:
- 25% — O que se traduz em uma frequência de ~ 1350MHz
- 35% — 1890MHz
- 41% — 2214MHz
- 65% — 3510MHz
O número de conexões simultâneas foi reduzido de 500 para 1, 3, 5, 7 e 9,
Resultados:
Atrasos:
O TTFB foi especificamente destacado como um teste separado, porque o HTTPD Tools cria como que um novo usuário para cada solicitação individual. Este teste ainda está bastante desconectado da realidade, porque o usuário clicará em algumas páginas, e, na realidade, o TTFP terá um papel principal.
A primeira, na verdade, a primeira solicitação após o primeiro início da máquina virtual IIS leva, em média, 120 ms.
Todas as solicitações subsequentes mostram TTFP de 1,5 ms. Apache e Nginx ficam atrás nisso. O autor pessoalmente considera este teste o mais revelador e escolheria o vencedor apenas com base nele.
O resultado não é surpreendente, pois o IIS já cacheia o conteúdo estático comprimido e não o recompresso toda vez que é solicitado.
Tempo gasto por cliente
Para avaliação de desempenho, é suficiente um teste com 1 conexão simultânea.
Por exemplo, o IIS completou o teste com 5000 usuários em 40 segundos, o que equivale a 123 solicitações por segundo.
Nos gráficos abaixo, está o tempo até a transmissão completa do conteúdo do site. Esta é a proporção de solicitações concluídas em um determinado tempo. No nosso caso, 80% de todas as solicitações foram processadas em 8 ms no IIS e 4,5 ms no Apache e Nginx, e o intervalo até 8 milissegundos foi concluído por 98% de todas as solicitações no Apache e Nginx.
Tempo que levou para processar 5000 solicitações:
Tempo que levou para processar 5000 solicitações:
Se você tem uma máquina virtual com 3,5GHz de CPU e 8 núcleos, escolha o que preferir. Todos os servidores web são muito parecidos neste teste. Vamos falar sobre qual servidor web escolher para cada host abaixo.
Quando se trata de uma situação um pouco mais realista, todos os servidores web estão lado a lado.
Taxa de transferência:
Gráfico de atrasos em relação ao número de conexões simultâneas. Plano 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 em um hospedagem virtual. Vamos usar 4 núcleos de 2.2GHz e um núcleo de 1.8GHz.
Como escalar
Se você já viu como são as curvas de características de triodes, pentodos e assim por diante, esses gráficos serão familiares para você. É exatamente isso que estamos tentando capturar - saturação. O limite em que não importa quantos núcleos você adicione, o aumento de desempenho não será perceptível.
Anteriormente, o desafio era processar 98% das solicitações com a menor latência em todas as requisições, mantendo a curva o mais uniforme possível. Agora, utilizando a construção de uma nova curva, encontraremos o ponto de operação ideal para cada um dos servidores.
Para isso, usaremos a métrica Requests per second (RPR). No eixo horizontal, a frequência; no vertical — o número de solicitações processadas por segundo, as linhas representam o número de núcleos.
Mostra a correlação de quão bem o Nginx processa as solicitações uma após a outra. 8 núcleos mostram-se melhores nesse tipo de teste.
Neste gráfico, é claramente visível quão melhor (não muito) o Nginx opera em um núcleo. Se você está utilizando Nginx, vale a pena considerar a redução do número de núcleos para um, caso você esteja hospedando apenas conteúdo estático.
Embora o IIS tenha o menor TTFB segundo o DevTools no Chrome, ele acaba perdendo para o Nginx e o Apache em uma séria disputa durante o teste de estresse da Apache Foundation.
Toda a curvatura dos gráficos é reproduzida de forma muito precisa.
Uma espécie de conclusão:
Sim, o Apache realmente trabalha pior com 1 e 8 núcleos, e com 4 funciona um pouco melhor.
Sim, o Nginx com 8 núcleos processa melhor as solicitações uma a uma, enquanto em 1 e 4 núcleos funciona pior quando há muitas conexões.
Sim, o IIS prefere 4 núcleos para carga multithread e prefere 8 núcleos para carga de thread única. No final, o IIS é um pouco mais rápido que todos os outros em 8 núcleos sob alta carga, embora todos os servidores se igualem.
Isso não é um erro de medição, a margem de erro aqui é de no máximo ±1ms em latência e no máximo ±2-3 requisições por segundo para o RPR.
Os resultados onde 8 núcleos se mostram piores não são surpreendentes; muitos núcleos e SMT/Hyperthreading reduzem significativamente o desempenho se temos prazos para concluir todo o pipeline.
Fonte: habr.com
