In dit artikel zullen we proberen reverse engineering uit te voeren, zou je kunnen zeggen. We zullen onze vuile handen onder de motorkap van elke webserver steken en ze exploiteren op manieren die niemand ooit zou exploiteren.
Deze test is een meting van een bolvormig paard in een vacuüm, niets meer dan gegevens die zijn verkregen, en nu weten we niet wat we ermee moeten doen.
techniek
Het besturingssysteem voor Nginx en Apache is Ubuntu 18.04 LTS, voor IIS Windows Server Core 2019. Vóór de tests ontvingen alle besturingssystemen vanaf 04.12.2019 december XNUMX de nieuwste updates.
Tests werden uitsluitend via HTTP uitgevoerd. Elke webserver draaide dezelfde pagina, een gratis Jekyll-sjabloon van Codrops. . Op elke webserver was gzip-compressie uitgeschakeld.
De doorvoertest werd gedaan met Httpd-tools met de argumenten:
ab -n 50000 -c 500 http://192.168.76.204:80/Servers waren beperkt tot 10, 5 en 1 procent van de kern op 8, 4 en één kern. De testbank was een computer met 9900K@5400MHz, wat betekent dat de server die een limiet van 10% ontvangt, ongeveer 540MHz per core ontvangt.
De TTFB-test werd uitgevoerd toen de server voor het eerst opstartte en gemeten met DevTools; na ontvangst van het resultaat werd de server uitgeschakeld en teruggezet naar het vorige controlepunt om het verschijnen van elke vorm van caches te elimineren.
De tester en de webserver bevonden zich op dezelfde host en op dezelfde virtuele switch.
Om het schijfsubsysteem onmiddellijk te evalueren, de resultaten van de ATTO- en CrystalDIskMark-benchmarks om een idee te krijgen van de knelpunten.
Gegevens afkomstig van de virtuele machine:
Resultaten:
TTFB:
De gemiddelde TTFB voor IIS is de kleinste, 0,5 ms, versus 1,4 ms voor Apache en 4 ms voor Nginx.
Doorvoer:
Laten we eerst eens kijken hoe goed elke server schaalt op basis van het aantal kernen.
De grafiek toont het aantal testeroproepen naar de webserver en de latentie. De grafiek laat zien dat NGINX 98% van alle verzoeken verwerkte, waardoor de site binnen 20 ms of minder werd opgeleverd. IIS voltooide, net als Apache, de laatste 5% van alle oproepen in respectievelijk 76 ms en 14 ms.
De grafiek toont de gemiddelde verwerkingstijd van één aanvraag tijdens een stresstest.
Zoals je in de grafieken kunt zien, heeft IIS zowel Apache als Nginx weggeblazen, waardoor de snelheid aanzienlijk werd vertraagd onder hoge belasting.
IIS gaf duidelijk de voorkeur aan 4 cores boven XNUMX, met lagere latenties op XNUMX, maar gaf ook niet sterk de voorkeur aan één core.
NGINX schaalt goed over alle acht cores, en voor Apache lijkt het single-core scenario de beste keuze.
Schaalbaarheid:
Nginx:
Laten we nu eens kijken naar de schaalbaarheid in termen van frequentie en aantal cores.
Nginx slaagde niet voor tests met een limiet van 1% voor 4 en 1 cores; toen het meer dan 2000 verzoeken overschreed, werd de verbinding met de tester verbroken.
Apache:
Apache gaf, net als Nginx, 2500 verzoeken verwerkt, het op en verbrak de verbinding. Apache slaagde niet voor de test op 8, 4 en 1 cores met een limiet van 1%, maar daarnaast faalde het ook voor de test met een limiet van 5% op één core, wat slechter is dan Nginx
IIS:
Tijdens de tests verzamelde IIS een gigantische rij verzoeken, maar verwerkte ze allemaal. Blijkbaar zijn er standaard geen time-outs ingesteld voor de verwerking van verzoeken.
Het diagram toont de tijd die nodig was om de test te voltooien. Volkomen absurde testconfiguraties werden weggegooid. Het diagram laat zien hoe veeleisend IIS is als het om hardware gaat, en hoe geweldig NGINX is.
Schaalbaarheid vanaf schijf:
Nginx:
Laten we nu eens kijken naar de schaalbaarheid in termen van frequentie, aantal cores en schijfsnelheid.
Deze keer faalde Nginx voor vier tests in plaats van twee.
Apache:
Apache slaagde niet voor hetzelfde aantal tests als de vorige keer.
IIS:
IIS toont een vrijwel identieke grafiek, alsof er geen schijfbeperkingen zijn. Over het algemeen veranderden de grafische afbeeldingen van alle servers niet veel, wat betekent dat elk van hen statische gegevens in het RAM-geheugen opsloeg en van daaruit serveerde. Hier zien we het belangrijkste knelpunt: de webserver zelf.
Het is nog te vroeg om conclusies te trekken op basis van deze tests; we hebben HTTPS, compressie en HTTP/2 nog niet getest met een live certificaat van Let’s Encrypt. We zullen hierover in het volgende artikel praten.
Bron: www.habr.com