Neste artigo, tentaremos um pouco de engenharia reversa, por assim dizer. Vamos espiar com nossas mãos sujas sob o capô de cada um dos servidores web, explorando-os da maneira que ninguém jamais exploraria.
Este teste é uma medição de um cavalo esférico no vácuo, nada mais do que dados que foram obtidos, e agora não sabemos o que fazer com eles.
Metodologia
O sistema operacional utilizado para Nginx e Apache é o Ubuntu 18.04 LTS, e para IIS é o Windows Server Core 2019. Todos os sistemas operacionais receberam as últimas atualizações até 04.12.2019.
Os testes foram conduzidos exclusivamente via HTTP. Em cada um dos servidores web, estava rodando a mesma página, um template gratuito para Jekyll da Codrops. . A compactação gzip foi desativada em todos os servidores web.
O teste de largura de banda foi realizado com o Httpd-tools utilizando os seguintes argumentos:
ab -n 50000 -c 500 http://192.168.76.204:80/Foi aplicado um limite de 10%, 5% e 1% do núcleo para 8, 4 e um núcleo. A configuração do teste foi um computador com 9900K@5400MHz, o que significa que o servidor que recebeu a limitação de 10% recebe cerca de 540MHz por núcleo.
O teste TTFB foi conduzido na primeira carga do servidor e foi medido usando o DevTools. Após obter o resultado, o servidor foi desligado e revertido para o ponto de controle anterior para excluir qualquer tipo de cache.
O testador e o servidor web estavam no mesmo host e no mesmo switch virtual.
Para avaliar imediatamente o subsistema de disco, os resultados do benchmark ATTO e CrystalDiskMark foram coletados para ter uma noção dos gargalos.
Os dados foram coletados da máquina virtual:
Resultados:
TTFB:
O TTFB médio do IIS é o menor de todos, 0,5ms, contra 1,4ms do Apache e 4ms do Nginx.
Taxa de transferência:
Primeiro, vamos observar quão bem cada um dos servidores escala em relação ao número de núcleos.
O gráfico mostra o número de acessos do testador ao servidor web e a latência. Nele, pode-se ver que o NGINX lidou com 98% de todos os acessos, entregando o site em 20ms ou menos. O IIS, assim como o Apache, levou os últimos 5% de todos os acessos em 76ms e 14ms, respectivamente.
O gráfico exibe o tempo médio de processamento de uma única solicitação durante o teste de estresse.
Como pode ser observado nos gráficos, o IIS ficou atrás tanto do Apache quanto do Nginx, desacelerando bastante sob carga alta.
O IIS claramente preferiu 4 núcleos em vez de oito, mostrando menores latências em quatro, mas também não apoiou muito um único núcleo.
O NGINX escala perfeitamente em todos os 8 núcleos, enquanto para o Apache, aparentemente, um cenário de núcleo único parece ser a melhor escolha.
Escalabilidade:
Nginx:
Agora, vamos considerar a escalabilidade em relação à frequência e ao número de núcleos.
Os testes com um limite de 1% em 4 e 1 núcleo não foram bem-sucedidos para o Nginx; ao ultrapassar 2000 requisições, ele cortou a conexão com o testador.
Apache:
Assim como o Nginx, o Apache também se rendeu e cortou a conexão depois de processar 2500 requisições. O Apache não passou no teste em 8, 4 e 1 núcleo com limite de 1%, e além disso, não passou no teste com o limite de 5% em um único núcleo, o que é pior do que o Nginx.
IIS:
Durante os testes, o IIS acumulou uma enorme fila de requisições, mas processou cada uma delas. Aparentemente, não há timeouts de processamento de requisições configurados por padrão.
O gráfico apresenta o tempo em que o teste foi concluído. Configurações de teste totalmente absurdas foram descartadas. O gráfico revela o quanto o IIS é exigente em termos de hardware e o quão excelente é o NGINX.
Escalabilidade a partir do disco:
Nginx:
Agora, vamos analisar a escalabilidade com relação à frequência, número de núcleos e velocidade do disco.
Desta vez, o Nginx não passou em 4 testes, em vez de 2.
Apache:
O Apache falhou no mesmo número de testes que na última vez.
IIS:
O IIS apresenta um gráfico quase idêntico, como se não houvesse limitações no disco. De modo geral, os gráficos de todos os servidores não mudaram significativamente, o que significa que cada um deles armazenou a estática na memória RAM e serviu a partir dela. Aqui vemos o principal gargalo – o próprio servidor web.
É cedo para tirar conclusões com base neste teste; ainda não testamos HTTPS, compressão e HTTP/2 com um certificado ativo do Let’s Encrypt. Falaremos sobre isso no próximo artigo.
Fonte: habr.com
