I denne artikel vil vi forsøge os med reverse engineering, kan man sige. Vi får vores beskidte hænder under hætten på hver webserver og udnytter dem på måder, som ingen nogensinde ville udnytte.
Denne test er en måling af en kugleformet hest i et vakuum, intet andet end data, der blev opnået, og nu ved vi ikke, hvad vi skal gøre med det.
teknik
Operativsystemet til Nginx og Apache er Ubuntu 18.04 LTS, til IIS Windows Server Core 2019. Før testene modtog alle operativsystemer de seneste opdateringer pr. 04.12.2019. december XNUMX.
Testene blev udelukkende udført over HTTP. Hver webserver kørte den samme side, en gratis Jekyll-skabelon fra Codrops. . Hver webserver havde gzip-komprimering deaktiveret.
Gennemløbstesten blev udført med Httpd-værktøjer med argumenterne:
ab -n 50000 -c 500 http://192.168.76.204:80/Servere var begrænset til 10, 5 og 1 procent af kernen på 8, 4 og en kerne. Testbænken var en computer med 9900K@5400MHz, hvilket betyder, at serveren, der modtager en grænse på 10 %, modtager omkring 540MHz pr. kerne.
TTFB-testen blev udført, da serveren først startede og målte ved hjælp af DevTools; efter at have modtaget resultatet, blev serveren slukket og rullet tilbage til det tidligere kontrolpunkt for at eliminere forekomsten af enhver form for caches.
Testeren og webserveren var på den samme vært og på den samme virtuelle switch.
For øjeblikkeligt at evaluere diskundersystemet, resultaterne af ATTO- og CrystalDIskMark-benchmarks for at få en idé om flaskehalsene.
Data taget fra den virtuelle maskine:
resultater:
TTFB:
Den gennemsnitlige TTFB for IIS er den mindste, 0,5 ms, mod 1,4 ms for Apache og 4 ms for Nginx.
gennemløb:
Lad os først se på, hvor godt hver server skalerer baseret på antallet af kerner.
Grafen viser antallet af testopkald til webserveren og latenstid. Grafen viser, at NGINX behandlede 98 % af alle anmodninger og leverede webstedet på 20 ms eller mindre. IIS gennemførte ligesom Apache de sidste 5% af alle opkald på henholdsvis 76 ms og 14 ms.
Grafen viser den gennemsnitlige behandlingstid for én anmodning under en stresstest.
Som du kan se på graferne, blæste IIS både Apache og Nginx væk, hvilket sænkede farten betydeligt under høj belastning.
IIS foretrak klart 4 kerner frem for XNUMX, der viste lavere latenser på XNUMX, men favoriserede heller ikke en kerne.
NGINX skalerer godt på tværs af alle 8 kerner, og for Apache ser single-core scenariet ud til at være det bedste valg.
Skalerbarhed:
Nginx:
Lad os nu se på skalerbarhed med hensyn til frekvens og antal kerner.
Nginx bestod ikke tests med en grænse på 1 % for 4 og 1 kerner; da den oversteg 2000 anmodninger, afsluttede den forbindelsen med testeren.
Apache:
Apache, ligesom Nginx, efter at have behandlet 2500 anmodninger, opgav og lukkede forbindelsen. Apache fejlede testen på 8, 4 og 1 kerner med en grænse på 1%, men derudover fejlede den også testen med en 5% grænse på en kerne, hvilket er dårligere end Nginx
IIS:
Under testene akkumulerede IIS en gigantisk kø af anmodninger, men behandlede hver af dem. Tilsyneladende er der uden for boksen sat timeouts for anmodningsbehandling.
Diagrammet viser den tid, det tog at gennemføre testen. Helt absurde testkonfigurationer blev kasseret. Diagrammet viser, hvor krævende IIS er, når det kommer til hardware, og hvor vidunderligt NGINX er.
Skalerbarhed fra disk:
Nginx:
Lad os nu se på skalerbarhed i form af frekvens og antal kerner og diskhastighed.
Denne gang fejlede Nginx 4 tests i stedet for to.
Apache:
Apache fejlede det samme antal tests som sidste gang.
IIS:
IIS viser en næsten identisk graf, som om der ikke var nogen diskrestriktioner. Generelt ændrede grafikken på alle servere sig ikke meget, hvilket betyder, at hver af dem cachelagde statiske data i RAM og serverede dem derfra. Her ser vi hovedflaskehalsen - selve webserveren.
Det er for tidligt at drage konklusioner baseret på denne test, vi har endnu ikke testet HTTPS, komprimering og HTTP/2 med et live-certifikat fra Let's Encrypt. Vi vil tale om dette i den næste artikel.
Kilde: www.habr.com