In dit artikel gaan we ons wagen aan reverse engineering, zo gezegd. We zullen met onze vieze handen onder de motorkap van elke webserver kijken, ze uitbuitend zoals niemand ooit zou doen.
Deze test is een meting van een sferisch paard in een vacuüm, niet meer dan de gegevens die zijn verkregen, en we weten nu niet wat we ermee moeten doen.
Methodiek
De besturingssystemen voor Nginx en Apache zijn Ubuntu 18.04 LTS, voor IIS Windows Server Core 2019. Alle besturingssystemen hebben vóór de tests de laatste updates ontvangen op datum 04.12.2019.
De tests werden uitsluitend via HTTP uitgevoerd. Op elke webserver draaide dezelfde pagina, een gratis sjabloon voor Jekyll van Codrops. . Op elke webserver was gzip-compressie uitgeschakeld.
De doorvoer test werd uitgevoerd met Httpd-tools met de argumenten:
ab -n 50000 -c 500 http://192.168.76.204:80/De servers kregen een limiet van 10, 5 en 1 procent van de kern op 8, 4 en één kern. Voor de testopstelling werd een computer met 9900K@5400 MHz gebruikt, wat betekent dat de server die de limiet van 10% kreeg, ongeveer 540 MHz per kern ontvangt.
De TTFB-test werd uitgevoerd bij de eerste serveropstart en werd gemeten met behulp van DevTools. Na het verkrijgen van het resultaat werd de server uitgeschakeld en teruggezet naar het vorige controlepunt om de verschijning van enige vorm van caching uit te sluiten.
De tester en de webserver bevonden zich op dezelfde host en op dezelfde virtuele switch.
Om onmiddellijk de schijfsysteem te evalueren, zijn de resultaten van de benchmarks ATTO en CrystalDiskMark gepresenteerd om een idee te krijgen van knelpunten.
Gegevens zijn verzameld van de virtuele machine:
Resultaten:
TTFB:
De gemiddelde TTFB van IIS is de laagste van allemaal, 0,5 ms, vergeleken met 1,4 ms voor Apache en 4 ms voor Nginx.
Throughput:
Laten we eerst bekijken hoe goed elke server opschaalt met het aantal kernen.
In de grafiek is het aantal verzoeken van de tester aan de webserver en de latentie weergegeven. In de grafiek is te zien dat NGINX 98% van alle verzoeken heeft afgehandeld, de site binnen 20 ms en minder heeft geleverd. IIS en Apache verwerkten de laatste 5% van alle verzoeken in respectievelijk 76 ms en 14 ms.
De grafiek toont de gemiddelde verwerkingstijd van één verzoek tijdens de stresstest.
Zoals te zien is in de grafieken, heeft IIS het afgelegd tegen zowel Apache als Nginx, en vertraagde het sterk onder hoge belasting.
IIS gaf duidelijk de voorkeur aan 4 kernen boven acht, met kleinere vertragingen op vier, maar vond ook één kern niet echt geschikt.
NGINX schaalt perfect over alle 8 kernen, terwijl het voor Apache, op het eerste gezicht, het beste is om een single-core scenario te kiezen.
Schaalbaarheid:
Nginx:
Laten we nu de schaalbaarheid bekijken op basis van frequentie en aantal kernen.
Tests met een limiet van 1% op 4 en 1 kern hebben Nginx niet doorstaan; bij meer dan 2000 verzoeken verbrak het de verbinding met de tester.
Apache:
Apache, net als Nginx, gaf na 2500 verzoeken de geest en verbrak de verbinding. Apache slaagde niet voor de test op 8, 4 en 1 kernen met een limiet van 1%, en bovendien faalde het ook de test met een 5% limiet op één kern, wat slechter is dan Nginx.
IIS:
IIS genereerde tijdens de tests een enorme wachtrij van verzoeken, maar verwerkte elk van hen. Blijkbaar zijn er standaard geen time-outs voor verzoekverwerking ingesteld.
In de grafiek is de tijd te zien die nodig was om de test te voltooien. Volledig absurde testconfiguraties zijn weggelaten. Uit de grafiek blijkt hoe veeleisend IIS is voor hardware en hoe uitstekend NGINX is.
Schaalbaarheid van de schijf:
Nginx:
Laten we nu de schaalbaarheid bekijken op basis van frequentie, aantal kernen en schijf snelheid.
Deze keer heeft Nginx 4 tests niet doorstaan, in plaats van twee.
Apache:
Apache heeft hetzelfde aantal tests niet doorstaan als voorheen.
IIS:
IIS laat bijna een identieke grafiek zien, alsof er geen beperkingen op de schijf waren. Over het algemeen zijn de grafieken van alle servers niet veel veranderd, wat betekent dat elke server de statische inhoud in het RAM heeft gecached en deze daaruit heeft geleverd. Hier zien we de grootste bottleneck – de webserver zelf.
Het is te vroeg om conclusies te trekken op basis van deze test, we hebben HTTPS, compressie en HTTP/2 met een live certificaat van Let's Encrypt nog niet getest. We zullen hierover in het volgende artikel berichten.
Bron: habr.com
