Võib öelda, et selles artiklis proovime kätt pöördprojekteerimisel. Me paneme oma määrdunud käed iga veebiserveri kapoti alla, kasutades neid ära viisil, mida keegi kunagi ära ei kasutaks.
See test on sfäärilise hobuse mõõtmine vaakumis, mitte midagi muud kui saadud andmed ja nüüd me ei tea, mida sellega peale hakata.
Metoodika
Nginxi ja Apache operatsioonisüsteemiks on Ubuntu 18.04 LTS, IIS Windows Server Core 2019 jaoks. Enne teste said kõik operatsioonisüsteemid 04.12.2019. detsembri XNUMX seisuga uusimad uuendused.
Testid viidi läbi ainult HTTP kaudu. Iga veebiserver jooksis sama lehte, Codropsi tasuta Jekylli malli. . Igas veebiserveris oli gzipi tihendamine keelatud.
Läbilaskevõime test viidi läbi Httpd-tööriistadega järgmiste argumentidega:
ab -n 50000 -c 500 http://192.168.76.204:80/Serverite arv oli piiratud 10, 5 ja 1 protsendiga 8, 4 ja ühe tuumaga. Testilauaks oli arvuti sagedusega 9900K@5400MHz, mis tähendab, et 10% limiidi saav server saab umbes 540MHz tuuma kohta.
TTFB test viidi läbi serveri esmakordsel käivitamisel ja DevToolsi abil mõõtmisel; pärast tulemuse saamist lülitati server välja ja viidi tagasi eelmisele kontrollpunktile, et välistada igasuguste vahemälude ilmumine.
Tester ja veebiserver olid samas hostis ja samas virtuaalses lülitis.
Ketta alamsüsteemi koheseks hindamiseks ATTO ja CrystalDISkMarki etalonide tulemused, et saada aimu kitsaskohtadest.
Virtuaalsest masinast võetud andmed:
Tulemused:
TTFB:
IIS-i keskmine TTFB on väikseim, 0,5 ms, Apache 1,4 ms ja Nginxi puhul 4 ms.
Läbilaskevõime:
Kõigepealt vaatame, kui hästi iga server tuumade arvu alusel skaleerub.
Graafik näitab testijate veebiserveri kõnede arvu ja latentsust. Graafik näitab, et NGINX töötles 98% kõigist päringutest, edastades saidi 20 ms või vähemaga. IIS, nagu Apache, lõpetas viimased 5% kõigist kõnedest vastavalt 76 ms ja 14 ms.
Graafik näitab ühe päringu keskmist töötlemisaega stressitesti ajal.
Nagu graafikutelt näha, paiskas IIS minema nii Apache'i kui ka Nginxi, aeglustades suure koormuse korral märkimisväärselt.
IIS eelistas selgelt nelja tuuma 4 asemel, näidates XNUMX-l madalamat latentsust, kuid ei eelistanud ka tugevalt ühte tuuma.
NGINX skaleerub hästi kõigis 8 tuumas ja Apache'i jaoks näib ühetuumaline stsenaarium olevat parim valik.
Skaleeritavus:
nginx:
Nüüd vaatame skaleeritavust sageduse ja tuumade arvu osas.
Nginx ei läbinud teste 1% piiranguga 4 ja 1 tuuma puhul; kui see ületas 2000 päringut, katkestas ta ühenduse testeriga.
Apache:
Apache, nagu ka Nginx, pärast 2500 päringu töötlemist loobus ja sulges ühenduse. Apache ebaõnnestus testis 8, 4 ja 1 tuumal piiranguga 1%, kuid lisaks kukkus läbi ka ühe tuuma 5% piiranguga test, mis on halvem kui Nginx
IIS:
Testide ajal kogus IIS hiiglasliku järjekorda taotlusi, kuid töötles neid kõiki. Ilmselt pole päringu töötlemiseks ühtegi ajalõpu määratud.
Diagramm näitab testi sooritamiseks kulunud aega. Täiesti absurdsed testimiskonfiguratsioonid jäeti kõrvale. Diagramm näitab, kui nõudlik on IIS riistvara osas ja kui imeline on NGINX.
Skaleeritavus kettalt:
nginx:
Nüüd vaatame skaleeritavust sageduse ja tuumade arvu ning ketta kiiruse osas.
Seekord ebaõnnestus Nginx kahe testi asemel 4 testis.
Apache:
Apache ebaõnnestus sama arvu testidega kui eelmisel korral.
IIS:
IIS näitab peaaegu identset graafikut, nagu poleks kettapiiranguid. Üldiselt ei muutunud kõigi serverite graafika palju, mis tähendab, et igaüks salvestas staatilisi andmeid RAM-i ja teenindas neid sealt. Siin näeme peamist kitsaskohta – veebiserverit ennast.
Selle testimise põhjal on veel vara järeldusi teha, me pole veel Let's Encrypti reaalajas sertifikaadiga HTTPS-i, tihendamist ja HTTP/2 testinud. Sellest räägime järgmises artiklis.
Allikas: www.habr.com