Veebiserverite lahing. Osa 2 – realistlik stsenaarium HTTPS:

Meetodist rääkisime esimeses osas artiklis, siin testime HTTPS-i, kuid realistlikumates stsenaariumides. Testimiseks kasutati Let’s Encrypt'i sertifikaati, samuti aktiveeriti Brotli kokkusurumine 11.

Seekord proovime korrata serveri juurutamise stsenaariumi VDS-is või virtuaalse masina lõikes hostis, millel on tavaline protsessor. Selle jaoks seadsime piiri järgmistele väärtustele:

• 25% – mis konverteerituna tähistab sagedust ~ 1350 MHz
• 35% – 1890 MHz
• 41% – 2214 MHz
• 65% – 3510 MHz

Samal ajal kui samadeaegsete ühenduste arv kahanes 500-lt 1, 3, 5, 7 ja 9-le,

Tulemused:

Viivitused:

TTFB toodi eraldi testina esile, kuna HTTPD Tools genereerib iga eraldi päringu jaoks justkui uue kasutaja. See test on endiselt piisavalt eemal reaalsusest, sest paarile lehele klikkides mängib tõeliselt suurt rolli TTFP.

Esimene, kõige esimene päring pärast virtuaalse masina IIS käivitamist toimub keskmiselt 120 ms jooksul.

Kõik järgmised päringud näitavad TTFP-d 1.5 ms. Apache ja Nginx jäävad sellega maha. Isiklikult peab autor seda testi kõige näitlikumaks ja valiks võitja vaid selle põhjal.
Tulemus ei ole üllatav, kuna IIS vahemälestab juba kompresseeritud staatilist sisu ja ei kompressi seda iga kord, kui sellele pöördutakse.

Aeg, mis kulub ühe kliendi peale

Tootlikkuse hindamiseks piisab ka 1 samadeaegse ühenduse testimisest.
Näiteks lõpetas IIS 5000 kasutaja testi 40 sekundiga, see tähendab 123 päringut sekundis.

Allpool olevates diagrammides on näidatud aeg, mis kulus saidi sisu täielikuks edastamiseks. See on suvandi arv, mis on täidetud kindla aja jooksul. Meie juhul töötati välja 80% kõigist päringutest IIS-i ja 4.5 ms Apache ja Nginx-i puhul 8ms jooksul, samas kui kuni 8 millisekundit töötleti 98% kõigist päringutest Apache ja Nginx-i puhul.

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

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

Kui teil on virtuaalne masin 3.5 GHz protsessoriga ja 8 tuumaga, valige, mida soovite. Kõik veebiserverid on sellises testimises väga sarnased. Millist veebiserverit iga hosti jaoks valida, sellest räägime allpool.

Kui jutt käib veidi reaalsemast olukorrast, siis kõik veebiserverid on omavahel puksiiri teinud.

sündmusi/s (eps): 836,6908

Viivituste graafik samadeaegsete ühenduste arvust. Mida ühtlasem ja madalam, seda parem. Viimased 2% jäeti graafikutest välja, kuna muudaks need loetamatuks.

Nüüd vaatame olukorda, kus server asub virtuaalses hostimises. Võtame 4 tuuma, igaühe sagedus on 2.2GHz ja üks tuum 1.8GHz.

Kuidas skaleeritakse

Kui olete kunagi näinud, kuidas elektronkahesüsteemide, pentoodide ja muude mõõdikute graafikud välja näevad, on need diagrammid teile tuttavad. Just seda üritame tabada – küllastumist. Piir, kus olenemata sellest, kui palju tuumi lisada, ei ole jõudluse kasv enam märgatav.

Varem seisnes kogu väljakutse 98% päringute töötlemises, hoides samal ajal kõigi päringute viivitust võimalikult madalana, püüdes kinnitusjoont tasakaalus hoida. Nüüd leiame uue kõvera ehitamise abil igale serverile optimaalse tööpunkti.

Selleks võtame aluseks Requests per second (RPR). Horisontaalteljel on sagedus, vertikaalteljel – sekundis töödeldud päringute arv, jooned – tuumade arv.

Graafik näitab, kui hästi Nginx töötleb päringuid järjestikku. 8 tuuma testis näitavad end paremini.

Sellel graafikul on selgelt näha, kui palju paremini (mitte oluliselt) Nginx töötab ühel tuumal. Kui kasutate Nginx'i, tasub kaaluda tuumade arvu vähendamist ühele, kui hostite ainult staatilist sisu.

Kuigi IIS-il on DevTools'i järgi Chrome'is madalaim TTFB, suudab see siiski Nginx'ile ja Apache'ile tõsises stressitestides alla jääda.

Kogu graafikute kõverus on usaldusväärne.

Oma laadi järeldus:

Jah, Apache töötab 1 ja 8 tuumaga tõestatud halvemini, 4 tuumaga töötab aga veidi paremini.

Jah, Nginx töötleb 8 tuumaga paremini päringuid järjestikku, 1 ja 4 tuumaga on see halvem, kui ühenduste arv on suur.

Jah, IIS eelistab 4 tuuma mitme niidi koormuse jaoks ja 8 tuuma ühe niidi jaoks. Lõppkokkuvõttes osutus IIS 8 tuumaga kõrge koormuse all veidi kiiremaks, kuigi kõik serverid käisid üksteisega samas tempos.

See pole mõõtumisse vale, vea ulatus on siin maksimaalselt +-1ms viivitustes ja mitte rohkem kui +-2-3 päringut sekundis RPR jaoks.

Tulemused, kus 8 tuuma saavutavad halvemad näidud, pole kaugeltki üllatavad, liiga palju tuumi ja SMT/Hüperharjutamine halvendavad jõudlust, kui meil on ajaraamid, mille jooksul peame kogu torujuhtme lõpule viima.

Allikas: habr.com