Falamos sobre a técnica na
primeira parte do artigo, neste testamos o HTTPS, mas em cenários mais realistas. Para o teste, o certificado Let's Encrypt foi recebido, a compactação Brotli por 11 foi ativada.
Desta vez, tentaremos reproduzir o cenário de implantação do servidor no VDS ou como uma máquina virtual em um host com um processador típico. Para fazer isso, defina o limite para:
- 25% - Que em termos de frequência ~ 1350MHz
- 35% -1890MHz
- 41% - 2214MHz
- 65% - 3510MHz
O número de conexões únicas diminuiu de 500 para 1, 3, 5, 7 e 9,
Resultados:
Atrasos:
O TTFB foi feito especialmente como um teste separado, porque o HTTPD Tools cria um novo usuário para cada solicitação individual. Esse teste ainda está bastante separado da realidade, porque o usuário clica em algumas páginas de qualquer maneira e, na realidade, o TTFP desempenhará o papel principal.
A primeira, geralmente a primeira solicitação, após o primeiro início da máquina virtual, o IIS processa uma média de 120 ms.
Todas as solicitações subseqüentes mostram um TTFP de 1,5 ms. Apache e Nginx estão atrasados. Pessoalmente, o autor considera esse teste o mais revelador e escolheria apenas um vencedor.
O resultado não é surpreendente, pois o IIS armazena em cache o conteúdo estático já compactado e não o pinça toda vez que é acessado.
Tempo gasto em um cliente
Para avaliar o desempenho, basta um teste com 1 conexão única.
Por exemplo, o IIS concluiu o teste com 5.000 usuários em 40 segundos, ou seja, 123 solicitações por segundo.
Os gráficos abaixo mostram o tempo até a transferência completa do conteúdo do site. Essa é a porcentagem de solicitações concluídas em um horário específico. No nosso caso, 80% de todas as solicitações foram processadas em 8ms no IIS e 4.5ms no Apache e Nginx, e 98% de todas as solicitações no Apache e Nginx foram executadas dentro de um intervalo de 8 milissegundos.
O tempo necessário para processar 5000 solicitações:
O tempo necessário para processar 5000 solicitações:
Se você possui uma máquina virtual com uma CPU de 3,5 GHz e 8 núcleos, escolha o que deseja. Todos os servidores da web são muito semelhantes neste teste. Falaremos sobre qual servidor web escolher para cada host abaixo.
Quando se trata de uma situação um pouco mais real, todos os servidores da Web ficam cara a cara.
Rendimento:
Programação de atrasos no número de conexões simultâneas. Mais suave e mais baixo é melhor. Os últimos 2% foram jogados fora dos gráficos porque os tornariam ilegíveis.
Agora considere a opção em que o servidor está hospedado em uma hospedagem compartilhada. Tome 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 I-V dos triodos de eletro-vácuo, pentodos, etc., esses gráficos lhe serão familiares. É isso que estamos tentando entender - saciedade. O limite é que, quando você não joga quantos núcleos, o crescimento da produtividade não será perceptível.
Anteriormente, todo o desafio era processar 98% das solicitações com o menor atraso em todas as solicitações, para manter a curva o mais uniforme possível. Agora, usando a construção de outra curva, encontramos o ponto operacional ideal para cada um dos servidores.
Para fazer isso, use a métrica Solicitações por segundo (RPR). Frequência horizontal, vertical - o número de solicitações processadas por segundo, linhas - o número de núcleos.
É mostrada uma correlação de quão bem o Nginx lida com as solicitações uma a uma. 8 núcleos em tais testes se mostram melhor.
Este gráfico mostra claramente quanto melhor (não muito) o Nginx é executado em um único núcleo. Se você possui o Nginx, considere reduzir o número de núcleos para um se hospedar apenas estática.
O IIS, embora tenha o TTFB mais baixo de acordo com o DevTools no Chrome, consegue perder o Nginx e o Apache em uma luta séria contra o teste de estresse da Apache Foundation.
Toda a curvatura dos gráficos é reproduzida por trem.
Uma espécie de conclusão:
Sim, o Apache funciona pior nos núcleos 1 e 8 e no 4 funciona um pouco melhor.
Sim, o Nginx em 8 núcleos lida com solicitações melhores uma após a outra, nos núcleos 1 e 4 e funciona pior quando há muitas conexões.
Sim, o IIS prefere 4 núcleos para carga multithread e 8 núcleos para single threaded. No final, o IIS foi um pouco mais rápido do que todos os 8 núcleos sob alta carga, embora todos os servidores tenham sido liberados.
Este não é um erro de medição, o erro aqui não passa de + -1ms. em atrasos e não mais que + - 2-3 solicitações por segundo para RPR.
Os resultados, quando oito núcleos são piores, não surpreendem, muitos núcleos e o SMT / Hyperthreading degradam severamente o desempenho se tivermos o prazo para o qual devemos concluir todo o pipeline.
Oferecemos uma tarifa atualizada do UltraLite
Windows VDS por 99 rublos com o Windows Server 2019 Core instalado.
