Pogovarjali smo se o metodologiji v v tem članku testiramo HTTPS, vendar v bolj realističnih scenarijih. Za testiranje je bil pridobljen certifikat Let’s Encrypt, kompresija Brotli je bila omogočena pri 11.
Tokrat bomo poskušali reproducirati scenarij postavitve strežnika na VDS ali kot virtualni stroj na gostitelju s standardnim procesorjem. V ta namen je bila določena omejitev:
- 25% - kar je enakovredno frekvenci ~ 1350 MHz
- 35 % -1890MHz
- 41 % - 2214 MHz
- 65 % - 3510 MHz
Število enkratnih povezav se je zmanjšalo s 500 na 1, 3, 5, 7 in 9,
Rezultati:
Zamude:
TTFB je bil posebej vključen kot ločen test, ker HTTPD Tools ustvari novega uporabnika za vsako posamezno zahtevo. Ta test je še vedno precej odmaknjen od realnosti, saj bo uporabnik vseeno kliknil par strani, v resnici pa bo imel glavno vlogo TTFP.
Prva, praviloma prva zahteva po prvem zagonu virtualnega stroja IIS traja v povprečju 120 ms.
Vse nadaljnje zahteve kažejo TTFP 1.5 ms. Apache in Nginx v tem pogledu zaostajata. Osebno avtor meni, da je ta test najbolj razkrit in bi zmagovalca izbral samo na podlagi njega.
Rezultat ni presenetljiv, saj IIS predpomni že stisnjeno statično vsebino in je ne stisne ob vsakem dostopu.
Čas, porabljen na stranko
Za oceno delovanja zadostuje preizkus z eno samo povezavo.
IIS je na primer opravil test 5000 uporabnikov v 40 sekundah, kar je 123 zahtev na sekundo.
Spodnji grafi prikazujejo čas do popolnega prenosa vsebine spletnega mesta. To je delež zahtev, izpolnjenih v določenem času. V našem primeru je bilo 80 % vseh zahtev obdelanih v 8 ms na IIS in v 4.5 ms na Apache in Nginx, 8 % vseh zahtev na Apache in Nginx pa je bilo dokončanih v intervalu do 98 milisekund.
Čas, v katerem je bilo obdelanih 5000 zahtev:
Čas, v katerem je bilo obdelanih 5000 zahtev:
Če imate virtualni stroj s 3.5 GHz procesorjem in 8 jedri, potem izberite, kar želite. Vsi spletni strežniki so si pri tem testiranju zelo podobni. Spodaj bomo govorili o tem, kateri spletni strežnik izbrati za posameznega gostitelja.
Ko gre za nekoliko realnejšo situacijo, gredo vsi spletni strežniki nasproti.
Pretočnost:
Graf zakasnitev glede na število sočasnih povezav. Bolje je bolj gladko in nižje. Zadnja 2 % sta bila odstranjena z lestvic, ker bi ju naredila neberljive.
Zdaj pa razmislimo o možnosti, kjer strežnik gostuje na virtualnem gostovanju. Vzemimo 4 jedra pri 2.2 GHz in eno jedro pri 1.8 GHz.
Kako meriti
Če ste kdaj videli, kako izgledajo tokovno-napetostne karakteristike vakuumskih triod, pentod in tako naprej, vam bodo ti grafi znani. To je tisto, kar poskušamo ujeti - nasičenost. Meja je, ko ne glede na to, koliko jeder vržete, povečanje zmogljivosti ne bo opazno.
Prej je bil celoten izziv obdelati 98 % zahtev z najnižjo zakasnitvijo za vse zahteve, pri čemer je bila krivulja čim bolj ravna. Zdaj bomo s konstruiranjem druge krivulje našli optimalno delovno točko za vsakega od strežnikov.
Če želite to narediti, vzemimo indikator zahtev na sekundo (RPR). Vodoravno je frekvenca, navpično je število obdelanih zahtev na sekundo, črte so število jeder.
Prikazuje korelacijo med tem, kako dobro Nginx obdeluje zahteve eno za drugo. 8 jeder se v tem testu obnese bolje.
Ta graf jasno prikazuje, koliko bolje (ne veliko) Nginx deluje na enem jedru. Če imate Nginx, razmislite o zmanjšanju števila jeder na eno, če gostite samo statična.
IIS, čeprav ima najnižji TTFB glede na DevTools v Chromu, uspe izgubiti tako Nginx kot Apache v resnem boju s stresnim testom Apache Foundation.
Vsa ukrivljenost grafov je reproducirana kot železo.
Nekakšen zaključek:
Da, Apache deluje slabše na 1 in 8 jedrih, vendar malo bolje na 4.
Ja, Nginx na 8 jedrih bolje obdeluje zahteve eno za drugo, na 1 in 4 jedrih, slabše pa dela, če je povezav veliko.
Da, IIS ima prednost 4 jedra za večnitne delovne obremenitve in 8 jeder za enonitne delovne obremenitve. Konec koncev je bil IIS nekoliko hitrejši od vseh ostalih z 8 jedri pod visoko obremenitvijo, čeprav so bili vsi strežniki enaki.
To ni merilna napaka, napaka tukaj ni večja od +-1ms. v zamudah in ne več kot +- 2-3 zahteve na sekundo za RPR.
Rezultati, kjer se 8 jeder obnese slabše, sploh niso presenetljivi, veliko jeder in SMT/Hyperthreading zelo poslabšajo zmogljivost, če imamo časovni okvir, v katerem moramo dokončati celoten pipeline.
Vir: www.habr.com