U ovom članku ćemo pokušati malo s reverznim inženjeringom. Pogledat ćemo svojim prljavim rukama ispod haube svakog od web poslužitelja, iskorištavajući ih kao što ih nitko nikada ne bi iskoristio.
Ovaj test je mjerenje sfernog konja u vakuumu, samo podatci koje smo prikupili i sada ne znamo što s njima učiniti.
Metodologija
Kao operativni sustav za Nginx i Apache koristi se Ubuntu 18.04 LTS, a za IIS Windows Server Core 2019. Svi operativni sustavi su prije testiranja ažurirani na stanje 04.12.2019.
Testovi su provedeni isključivo putem HTTP-a. Na svakom od web poslužitelja vrtjela se ista stranica, besplatni predložak za Jekyll od Codrops. . Na svakom od web poslužitelja isključena je gzip kompresija.
Test propusnosti proveden je s Httpd-tools s argumentima:
ab -n 50000 -c 500 http://192.168.76.204:80/Na serverima je postavljen limit od 10, 5 i 1 posto od jezgre na 8, 4 i jedno jezgro. Kao testna platforma korišten je računar s 9900K@5400MHz, što znači da server koji je dobio limit od 10% dobiva oko 540MHz po jezgri.
TTFB test je proveden prilikom prvog učitavanja servera i mjeren je pomoću DevTools-a, nakon dobivanja rezultata server je isključen i vraćen na prethodnu kontrolnu točku, kako bi se isključila pojava bilo kakvih keševa.
Tester i web poslužitelj nalazili su se na istom hostu i na istom virtualnom switchu.
Da bismo odmah procijenili diskovni sustav, rezultati benchmarka ATTO i CrystalDiskMark, da bismo imali predstavu o uskim grlima.
Podaci su uzeti s virtualne mašine:



Rezultati:
TTFB:

Prosječni TTFB kod IIS-a je najmanji, 0,5ms, naspram 1,4ms kod Apache i 4ms kod Nginxa.
Propusnost:
Prvo ćemo razmotriti koliko dobro svaki od poslužitelja skalira s brojem jezgri.

Na grafikonu je prikazan broj zahtjeva testera prema web poslužitelju i latencija. Na grafikonu se vidi da je NGINX obradio 98% svih zahtjeva, isporučujući stranicu za 20ms ili manje. IIS i Apache su posljednjih 5% svih zahtjeva obradili za 76ms i 14ms respektivno.



Na grafikonu je prikazano prosječno vrijeme obrade jednog zahtjeva tijekom stres testa.
Kao što se može primijetiti iz grafova, IIS je izgubio od Apachea i Nginxa, značajno usporavajući pod visokim opterećenjem.
IIS je očito preferirao 4 jezgre umjesto osam, pokazujući manje kašnjenje na četiri, ali također nije previše odobrio ni jedno jezgro.
NGINX se izvrsno skalira na svih 8 jezgri, dok se za Apache, čini se, najbolji izbor čini scenarij s jednom jezgrom.
Skalabilnost:
Nginx:
Sada ćemo razmotriti skalabilnost prema frekvenciji i broju jezgri.

Testovi s ograničenjem od 1% na 4 i 1 jezgri Nginx nije prošao, prekidao se nakon 2000 zahtjeva.
Apache:

Apache je, poput Nginxa, obradio 2500 zahtjeva i odustao, prekinuvši vezu. Apache nije prošao test na 8, 4 i 1 jezgri s limitom od 1%, a osim toga nije prošao ni test s ograničenjem od 5% na jednoj jezgri, što je lošije od Nginxa.
IIS:

IIS je tijekom testova stvorio ogroman red zahtjeva, ali je obradio svaki od njih. Čini se da iz kutije nije postavljen vremenski limit za obradu zahtjeva.

Na dijagramu je predstavljeno vrijeme za koje je test završen. Potpuno apsurdne konfiguracije testiranja su odbačene. Iz dijagrama se vidi koliko je IIS zahtjevan prema hardveru i koliko je NGINX izvrstan.
Skalabilnost s diska:
Nginx:
Sada ćemo razmotriti skalabilnost prema frekvenciji, broju jezgri i brzini diska.

Ovoga puta Nginx nije prošao 4 testa, umjesto 2.
Apache:

Apache je podbacio s istim brojem testova kao i prošli put.
IIS:

IIS pokazuje gotovo identičan grafikon, kao da ograničenja na disk nisu postojala. Općenito, grafikon svih servera se nije značajno promijenio, što znači da su svi njihovi keširali statički sadržaj u RAM-u i pružali ga od tamo. Ovdje vidimo glavno usko grlo – sam web server.
Rano je donositi zaključke na temelju ovog testiranja, još nismo testirali HTTPS, kompresiju i HTTP/2 s živim certifikatom od Let’s Encrypt. O tome ćemo pisati u sljedećem članku.
Izvor: habr.com
