Falamos da técnica en artigo, neste probamos HTTPS, pero en escenarios máis realistas. Para probar, obtivemos un certificado Let's Encrypt e activamos a compresión de Brotli a 11.
Nesta ocasión tentaremos reproducir o escenario de implantación dun servidor nun VDS ou como máquina virtual nun host cun procesador estándar. Para estes efectos, estableceuse un límite en:
- 25% - O que equivale a unha frecuencia de ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
O número de conexións únicas reduciuse de 500 a 1, 3, 5, 7 e 9.
Resultados:
Atrasos:
TTFB incluíuse especificamente como unha proba separada, porque as ferramentas HTTPD crean un novo usuario para cada solicitude individual. Esta proba aínda está bastante afastada da realidade, porque o usuario aínda fará clic nun par de páxinas e, en realidade, TTFP desempeñará o papel principal.
A primeira, xeralmente a primeira solicitude despois do primeiro inicio da máquina virtual IIS leva unha media de 120 ms.
Todas as solicitudes posteriores mostran un TTFP de 1.5 ms. Apache e Nginx están atrasados neste sentido. Persoalmente, o autor considera esta proba a máis reveladora e elixiría o gañador só en función dela.
O resultado non é sorprendente xa que IIS almacena en caché contido estático xa comprimido e non o comprime cada vez que se accede a el.
Tempo dedicado por cliente
Para avaliar o rendemento, é suficiente unha proba cunha única conexión.
Por exemplo, IIS completou unha proba de 5000 usuarios en 40 segundos, o que supón 123 solicitudes por segundo.
Os gráficos de abaixo mostran o tempo ata que se transfire completamente o contido do sitio. Esta é a proporción de solicitudes completadas nun tempo determinado. No noso caso, o 80 % de todas as solicitudes procesáronse en 8 ms en IIS e en 4.5 ms en Apache e Nginx, e o 8 % de todas as solicitudes en Apache e Nginx completáronse nun intervalo de ata 98 milisegundos.
Tempo durante o cal se procesaron 5000 solicitudes:
Tempo durante o cal se procesaron 5000 solicitudes:
Se tes unha máquina virtual cunha CPU de 3.5 GHz e 8 núcleos, escolle o que queiras. Todos os servidores web son moi similares nesta proba. A continuación falaremos de que servidor web escoller para cada host.
Cando se trata dunha situación un pouco máis realista, todos os servidores web van cara a cara.
Rendemento:
Gráfico de atrasos fronte ao número de conexións simultáneas. Máis suave e máis baixo é mellor. O último 2% elimináronse dos gráficos porque os farían ilexíbeis.
Agora imos considerar a opción onde o servidor está aloxado en hospedaxe virtual. Tomemos 4 núcleos a 2.2 GHz e un núcleo a 1.8 GHz.
Como escalar
Se xa viches como son as características de tensión actual dos triodos, pentodos, etc. ao baleiro, estes gráficos serán familiares. Isto é o que estamos tentando captar: a saturación. O límite é cando non importa cantos núcleos lances, o aumento do rendemento non se notará.
Anteriormente, todo o reto consistía en procesar o 98% das solicitudes coa menor latencia para todas as solicitudes, mantendo a curva o máis plana posible. Agora, construíndo outra curva, atoparemos o punto de funcionamento óptimo para cada un dos servidores.
Para iso, tomemos o indicador Solicitudes por segundo (RPR). Horizontal é a frecuencia, vertical é o número de solicitudes procesadas por segundo, as liñas son o número de núcleos.
Mostra unha correlación do ben que Nginx procesa as solicitudes unha tras outra. 8 núcleos funcionan mellor nesta proba.
Este gráfico mostra claramente o mellor (non moito) que Nginx funciona nun só núcleo. Se tes Nginx, deberías considerar reducir o número de núcleos a un se aloxa só os estáticos.
IIS, aínda que ten o TTFB máis baixo segundo DevTools en Chrome, consegue perder tanto ante Nginx como con Apache nunha seria loita coa proba de esforzo da Fundación Apache.
Toda a curvatura das gráficas reprodúcese con revestimento de ferro.
Algún tipo de conclusión:
Si, Apache funciona peor en núcleos 1 e 8, pero funciona un pouco mellor en 4.
Si, Nginx en 8 núcleos procesa as solicitudes mellor unha tras outra, en 1 e 4 núcleos, e funciona peor cando hai moitas conexións.
Si, IIS prefire 4 núcleos para cargas de traballo con fíos múltiples e prefire 8 núcleos para cargas de traballo con fío único. En definitiva, IIS foi lixeiramente máis rápido que todos os demais en núcleos 8 con alta carga, aínda que todos os servidores estaban á altura.
Este non é un erro de medición, o erro aquí non é superior a +-1 ms. en atrasos e non máis de +- 2-3 solicitudes por segundo para RPR.
Os resultados nos que 8 núcleos funcionan peor non son para nada sorprendentes, moitos núcleos e SMT/Hyperthreading degradan moito o rendemento se temos un período de tempo no que temos que completar todo o pipeline.
Fonte: www.habr.com