Veebiserverite lahing. Osa 2 – realistlik HTTPS stsenaarium:

Meetodist rääkisime esimeses osas artiklis, siin testime HTTPS-i, kuid realistlikumates stsenaariumites. Testimiseks saadi Let’s Encrypt sertifikaat, rakendati Brotli tihendust 11-l.

Seekord proovime luua serveri paigaldamise stsenaariumi VDS-is või virtuaalmasinana hostis, millel on tüüpiline protsessor. Selleks seadsime limiidiks:

• 25% — mis vastab sagedusele ~ 1350MHz
• 35% - 1890MHz
• 41% — 2214MHz
• 65% — 3510MHz

Samal ajal vähenes samaaegsete ühenduste arv 500-lt 1, 3, 5, 7 ja 9-le,

Tulemused:

Viivitused:

TTFB eraldi testina, kuna HTTPD Tools loob iga jälgimise jaoks tegelikult uue kasutaja. See test on endiselt piisavalt kaugel reaalsusest, kuna mõned lehed, mida kasutaja ikkagi külastab, ja tegelikus elus mängib peamist rolli TTFP.

Esimene, kõige esimene päring pärast virtuaalmasina IIS esimest käivitamist, kestab keskmiselt 120 ms.

Kõik järgnevad päringud näitavad TTFP-d 1,5 ms. Apache ja Nginx jäävad siin maha. Isiklikult peab autor seda testi kõige kõnekamaks ja valida saaks võitjat ainult selle põhjal.
Tulemus ei ole üllatav, kuna IIS salvestab juba tihendatud staatilise sisu ja ei tihenda seda iga kord, kui sellele pöördutakse.

Aega, mis kulus ühe kliendi jaoks

Efektiivsuse hindamiseks piisab ühest ainulaadsest ühendusest.
Näiteks lõpetas IIS 5000 kasutaja testimise 40 sekundiga, see on 123 päringut sekundis.

Allpool olevatel joonistel on näidatud aega, mille jooksul veebisaidi sisu täielikult edastatakse. See on osa päringutest, mis töötati teatud aja jooksul. Meie juhul töötati 80% kõigist päringutest 8 ms jooksul IIS-is ja 4,5 ms jooksul Apache ja Nginx-is, samas kui vahemiku jooksul 8 millisekundit töötati 98% kõigist päringutest Apache ja Nginx-is.

Aeg, mille jooksul 5000 päringut töödeldi:

Aeg, mille jooksul 5000 päringut töödeldi:

Kui teil on virtuaalmasin sagedusega 3,5 GHz ja 8 tuumaga, siis valige, mida soovite. Kõik veebiserverid on selles testimises väga sarnased. Millist veebiserverit igale hostile valida, räägime allpool.

Kui rääkida veidi rohkem reaalsest olukorrast, lähevad kõik veebiserverid ninapidi kokku.

Läbilaskevõime:

Viivituste graafik samaaegsete ühenduste arvust. Ühtlasem ja madalam – parem. Viimased 2% jäeti graafikutest välja, kuna need muudaksid need loetamatuks.

Nüüd vaatame varianti, kus server asub virtuaalses hostimises. Võtame 4 tuuma 2,2 GHz ja ühe tuuma 1,8 GHz.

Kuidas skaleeritakse

Kui olete kunagi näinud, kuidas näevad välja elektrovakuumtriod, pentoodid jne, siis need graafikud on teile tuttavad. Just seda me üritame tabada – küllastus. Piir, kus palju tuumasid pole, ei pruugi jõudlust olla märgatavate muutustega.

Varasemalt seisnes kogu väljakutse 98% päringute töötlemises, omades kõigi päringute jooksul võimalikult madalat viivitust, hoides kõverat ühtlasena. Nüüd, edasi liikudes, leiame iga serveri jaoks optimaalse tööpunkti, luues teise kõvera.

Selle jaoks võtame näitaja Requests per second (RPR). Horisontaalselt sagedus, vertikaalselt — sekundis töödeldud päringute arv, jooned – tuumade arv.

Näidatud korrelatsioon, kui hästi Nginx töötleb päringuid järjestikku. 8 tuuma sellises testimises näitavad end paremini.

Sellel graafikul on hästi näha, kui palju paremini (mitte palju) Nginx töötab ühel tuumal. Kui teil on Nginx, siis tasub kaaluda tuumade arvu vähendamist ühele, kui hostite ainult staatilist sisu.

Kuigi IIS-l on Chrome'i DevTools arvates madalaim TTFB, suudab see kaotada Nginx-ile ja Apache-le tõsises stressitestides Apache Foundationilt.

Kogu graafikute kumerus on arusaadavalt olemas.

Oma laadset järeldust:

Jah, Apache töötab sõltumatult 1 ja 8 tuumaga halvemini, samas kui 4 tuumaga töötab veidi paremini.

Jah, Nginx töötleb paremini päringuid 8 tuumaga järjestikku, kuid 1 ja 4 tuumaga töötab halvemini, kui ühendusi on palju.

Jah, IIS eelistab 4 tuuma mitme koolutuse koormuse puhul ja 8 tuuma ühetuuma korral. Lõpuks osutus IIS veidi kiiremaks, kui 8 tuuma all kõrge koormuse korral, kuigi kõik serverid olid tasakaalus.

See pole mõõtmise viga, veaulatuses on viivitustes mitte üle ±1ms ja mitte üle ±2-3 päringu sekundis RPR jaoks.

Tulemused, kui 8 tuuma töötab halvasti, pole sugugi üllatavad, kuna palju tuumasid ja SMT/Hyperthreading halvendavad tõhusust, kui me peame enne kogu torujuhtme lõpetamist jääma ajaraamidesse.

Allikas: habr.com