I den här artikeln kommer vi att pröva oss på reverse engineering, kan man säga. Vi kommer att lägga våra smutsiga händer under huven på varje webbserver och utnyttja dem på ett sätt som ingen någonsin skulle utnyttja.
Detta test är ett mått på en sfärisk häst i vakuum, inget annat än data som erhölls, och nu vet vi inte vad vi ska göra med det.
teknik
Operativsystemet för Nginx och Apache är Ubuntu 18.04 LTS, för IIS Windows Server Core 2019. Före testerna fick alla operativsystem de senaste uppdateringarna den 04.12.2019 december XNUMX.
Tester utfördes uteslutande över HTTP. Varje webbserver körde samma sida, en gratis Jekyll-mall från Codrops. . Varje webbserver hade gzip-komprimering inaktiverad.
Genomströmningstestet gjordes med Httpd-verktyg med argumenten:
ab -n 50000 -c 500 http://192.168.76.204:80/Servrarna var begränsade till 10, 5 och 1 procent av kärnan på 8, 4 och en kärna. Testbänken var en dator med 9900K@5400MHz, vilket innebär att servern som tar emot en 10%-gräns får ca 540MHz per kärna.
TTFB-testet utfördes när servern först startade och mätte med hjälp av DevTools; efter att ha mottagit resultatet stängdes servern av och rullades tillbaka till den tidigare kontrollpunkten för att eliminera uppkomsten av alla typer av cacher.
Testaren och webbservern fanns på samma värd och på samma virtuella switch.
För att omedelbart utvärdera diskundersystemet, resultaten av ATTO- och CrystalDIskMark-riktmärkena för att få en uppfattning om flaskhalsarna.
Data hämtade från den virtuella maskinen:
resultat:
TTFB:
Den genomsnittliga TTFB för IIS är den minsta, 0,5 ms, mot 1,4 ms för Apache och 4 ms för Nginx.
genomströmning:
Låt oss först titta på hur väl varje server skalas baserat på antalet kärnor.
Grafen visar antalet testanrop till webbservern och latens. Grafen visar att NGINX bearbetade 98 % av alla förfrågningar och levererade webbplatsen på 20 ms eller mindre. IIS, liksom Apache, slutförde de sista 5 % av alla samtal på 76 ms respektive 14 ms.
Grafen visar den genomsnittliga handläggningstiden för en begäran under ett stresstest.
Som du kan se från graferna blåste IIS bort både Apache och Nginx, vilket saktade ner betydligt under hög belastning.
IIS föredrog helt klart 4 kärnor framför XNUMX, visade lägre latenser på XNUMX, men favoriserade heller inte en kärna starkt.
NGINX skalar bra över alla 8 kärnor, och för Apache verkar single-core scenariot vara det bästa valet.
Skalbarhet:
Nginx:
Låt oss nu titta på skalbarhet i termer av frekvens och antal kärnor.
Nginx klarade inte tester med en gräns på 1 % för 4 och 1 kärnor; när den översteg 2000 förfrågningar, avslutade den anslutningen med testaren.
Apache:
Apache, precis som Nginx, efter att ha behandlat 2500 förfrågningar, gav upp och stängde anslutningen. Apache underkände testet på 8, 4 och 1 kärnor med en gräns på 1%, men dessutom underkände den testet med en gräns på 5% på en kärna, vilket är sämre än Nginx
IIS:
Under testerna samlade IIS en gigantisk kö av förfrågningar men bearbetade var och en av dem. Uppenbarligen finns det inga tidsgränser för bearbetning av begäran.
Diagrammet visar den tid det tog att slutföra testet. Helt absurda testkonfigurationer förkastades. Diagrammet visar hur krävande IIS är när det kommer till hårdvara, och hur underbart NGINX är.
Skalbarhet från disk:
Nginx:
Låt oss nu titta på skalbarhet i termer av frekvens och antal kärnor och diskhastighet.
Den här gången misslyckades Nginx 4 tester istället för två.
Apache:
Apache misslyckades med samma antal tester som förra gången.
IIS:
IIS visar en nästan identisk graf, som om det inte fanns några diskbegränsningar. I allmänhet förändrades inte grafiken på alla servrar mycket, vilket innebär att var och en av dem cachade statisk data i RAM och serverade den därifrån. Här ser vi huvudflaskhalsen - själva webbservern.
Det är för tidigt att dra slutsatser utifrån denna testning, vi har ännu inte testat HTTPS, komprimering och HTTP/2 med ett livecertifikat från Let's Encrypt. Vi kommer att prata om detta i nästa artikel.
Källa: will.com