I denne artikel vil vi prøve os med reverse engineering, man kan sige. Vi vil kigge med vores beskidte hænder under motorhjelmen på hver enkelt webserver og udnytte dem som ingen nogensinde ville udnytte.
Denne test er som at måle en sfærisk hest i et vakuum, ikke mere end data, der er blevet indsamlet, og vi ved nu ikke, hvad vi skal gøre med dem.
Metodologi
Som operativsystem for Nginx og Apache bruges Ubuntu 18.04 LTS, mens IIS kører på Windows Server Core 2019. Alle operativsystemer fik de nyeste opdateringer inden testene den 04.12.2019.
Testene blev udelukkende udført over HTTP. På hver af webserverne blev der kørt den samme side, en gratis skabelon til Jekyll fra Codrops. . På hver af webserverne var gzip-komprimering slået fra.
Testen af båndbredde blev udført med Httpd-tools med argumenterne:
ab -n 50000 -c 500 http://192.168.76.204:80/Serverne fik et loft på 10, 5 og 1 procent af kernerne på henholdsvis 8, 4 og 1 kerne. Testopstillingen var en computer med 9900K@5400MHz, hvilket betyder, at serveren med 10% begrænsning får cirka 540MHz pr. kerne.
TTFB-testen blev udført ved den første indlæsning af serveren og blev målt med DevTools. Efter den modtagne værdi blev serveren slukket og rullet tilbage til det tidligere kontrolpunkt for at udelukke tilstedeværelsen af cache.
Testeren og webserveren befandt sig på den samme vært og på den samme virtuelle switch.
For straks at vurdere diskundersystemet, resultaterne fra benchmarkene ATTO og CrystalDiskMark for at få en idé om flaskehalsene.
Data er hentet fra en virtuel maskine:
Resultater:
TTFB:
Den gennemsnitlige TTFB for IIS er den laveste af alle, 0,5 ms, mod 1,4 ms for Apache og 4 ms for Nginx.
Gennemstrømning:
Først vil vi se på, hvor godt hver af serverne skalerer efter antallet af kerner.
Grafen viser antallet af testeranmodninger til webserveren og latency. Grafen viser, at NGINX håndterede 98% af alle anmodninger, og leverede siden på 20 ms eller mindre. IIS og Apache brugte henholdsvis 76 ms og 14 ms på de sidste 5% af alle anmodninger.
Grafen viser den gennemsnitlige behandlingstid for en enkelt anmodning under stresstesten.
Som man kan se fra graferne, tabte IIS til både Apache og Nginx, idet den blev væsentligt langsommere under høj belastning.
IIS foretrak tydeligt 4 kerner frem for otte, idet den viste mindre latency på fire, men heller ikke var særlig tilfreds med en enkelt kerne.
NGINX skalerer perfekt på alle 8 kerner, mens det for Apache synes, at en single-core-scenario er det bedste valg.
Skalerbarhed:
Nginx:
Lad os nu se på skalerbarheden med hensyn til frekvens og antal kerner.
Testen med en 1% grænse på 4 og 1 kerne bestod Nginx ikke, da det nåede over 2000 forespørgsler og afbrød forbindelsen til testeren.
Apache:
Apache, ligesom Nginx, gav op efter at have behandlet 2500 forespørgsler og brød forbindelsen. Apache bestod ikke testen på 8, 4 og 1 kerner med en 1% grænse, og derudover bestod den heller ikke testen på 5% grænsen på én kerne, hvilket er værre end Nginx.
IIS:
IIS skabte en kæmpe kø af forespørgsler under testene, men behandlede hver enkelt af dem. Det ser ud til, at der ikke er indbygget tidsgrænser til behandlingen af forespørgsler i det.
Diagrammet viser den tid, der blev brugt på at afslutte testen. Total absurde testkonfigurationer blev udeladt. Fra diagrammet kan man se, hvor krævende IIS er til hardwaren, og hvor fremragende NGINX er.
Skalerbarhed fra disken:
Nginx:
Lad os nu se på skalerbarheden med hensyn til frekvens, antal kerner og diskhastighed.
Denne gang bestod Nginx ikke 4 tests, i stedet for de to.
Apache:
Apache fejlede det samme antal tests som sidste gang.
IIS:
IIS viser næsten et identisk diagram, som om der ikke var nogen begrænsninger på disken. Generelt har diagrammerne for alle serverne ikke ændret sig meget, hvilket betyder, at hver enkelt har cachet statikken i RAM og leveret derfra. Her ser vi det vigtigste flaskehals – selve webserveren.
Det er tidligt at drage konklusioner baseret på denne testning; vi har endnu ikke testet HTTPS, komprimering og HTTP/2 med et live certifikat fra Let’s Encrypt. Dette vil vi tale om i næste artikel.
Kilde: habr.com
