O metodologiji smo govorili u članku, u ovom testiramo HTTPS, ali u realističnijim scenarijima. Za testiranje je dobijen Let’s Encrypt sertifikat, uključena je Brotli kompresija na 11.
Ovoga puta ćemo pokušati reprodukovati scenarij postavljanja servera na VDS ili kao virtuelnu mašinu na hostu sa standardnim procesorom. Za to smo postavili limit od:
- 25% — Što u preračunavanju na frekvenciju iznosi ~ 1350MHz
- 35% - 1890MHz
- 41% — 2214MHz
- 65% — 3510MHz
Broj simultanih konekcija smanjen je sa 500 na 1, 3, 5, 7 i 9,
Rezultati:
Kašnjenja:
TTFB je posebno izdvojen kao zaseban test, jer HTTPD alati za svaku pojedinačnu zahtev stvaraju kao da su novi korisnici. Ovaj test je još uvek prilično udaljen od stvarnosti, jer će korisnik ipak kliknuti na nekoliko stranica, a u stvarnosti će ključnu ulogu odigrati TTFP.
Prvi, uopšte prvi zahtev posle prvog pokretanja virtuelne mašine IIS se ispunjava u proseku za 120 ms.
Svi naredni zahtevi pokazuju TTFP od 1.5 ms. Apache i Nginx u ovom zaostaju. Autor lično smatra ovaj test najindikativnijim i birao bi pobednika samo na osnovu njega.
Rezultat nije iznenađujući, budući da IIS kešira već komprimovane statične sadržaje i ne kompresuje ih svaki put kada mu se obrate.
Vreme potrošeno po klijentu
Za procenu performansi dovoljno je i test sa 1 simultanom konekcijom.
Na primer, IIS je završio testiranje dužine od 5000 korisnika za 40 sekundi, što je 123 zahteva u sekundi.
Na grafikonima ispod je prikazano vreme do potpune prenosa sadržaja sajta. To je deo zahteva koji su izvršeni u određenom vremenu. U našem slučaju 80% svih zahteva obrađeno je za 8ms na IIS-u, a za 4.5ms na Apache-u i Nginx-u, dok je interval do 8 milisekundi izvršilo 98% svih zahteva na Apache-u i Nginx-u.
Vreme za obradu 5000 zahteva:
Vreme za obradu 5000 zahteva:
Ako imate virtuelnu mašinu sa 3.5GHz CPU i 8 jezgara, onda birajte ono što želite. Svi veb serveri su vrlo slični u ovom testiranju. O tome koji veb server izabrati za svaki host razgovaraćemo u nastavku.
Kada se govori o malo realnijoj situaciji, svi veb serveri su u rovovima jedan pored drugog.
dogodki/s (eps): 836.6908
Grafikon kašnjenja u odnosu na broj simultanih konekcija. Što je ravniji i niži – to je bolje. Poslednjih 2% su izbačeni iz grafika jer bi ih učinili nečitljivim.
Zdaj bomo obravnavali možnost, kjer je strežnik gostovan na virtualnem gostovanju. Vzeli bomo 4 jedra po 2,2 GHz in eno jedro pri 1,8 GHz.
Kako se širi
Če ste kdaj videli, kako izgledajo VAK elektronskih vakuumskih triod, pentod in podobno, bodo ti grafi za vas znani. To, kar poskušamo ujeti, je nasičenje. Omejitev, pri kateri ne glede na število jedr, rast zmogljivosti ne bo opazna.
Prej je bil celoten izziv obdelava 98% zahtevkov z najmanjšo zakasnitvijo, da bi kar se da enakomerno ohranjali krivuljo. Zdaj bomo s pomočjo gradnje druge krivulje poiskali optimalno delovno točko za vsak strežnik.
Za to bomo vzeli kazalnik Requests per second (RPR). Po horizontalni osi frekvenca, po vertikalni osi – število zahtevkov, obdelanih na sekundo, črte – število jedr.
Prikazana je Korelacija, kako dobro Nginx obdeluje zahtevke enega za drugim. 8 jedr v takem testiranju kaže boljše odzive.
Na tem grafu je jasno vidno, kako bolje (ne veliko) Nginx deluje na enem jedru. Če imate Nginx, razmislite o zmanjšanju števila jedr na eno, če gostite le statične vsebine.
IIS, čeprav ima po mnenju DevTools v Chromu najnižji TTFB, se ne more postaviti ob bok Nginxu in Apachu v resnih stresnih testih s strani Apache Foundation.
Vsa ukrivljenost grafov se reproducira zanesljivo.
Nekakšen zaključek:
Da, Apache se zanesljivo slabše izkaže pri 1 in 8 jedrih, medtem ko pri 4 deluje nekoliko bolje.
Da, Nginx pri 8 jedrih bolje obdeluje zahtevke enega za drugim, slabše pa deluje pri 1 in 4 jedrih, ko je povezav veliko.
Da, IIS daje prednost 4 jedrom za večprednostno obremenitev in 8 jedrom za enojno. Na koncu se je IIS izkazal kot nekoliko hitrejši od vseh pri 8 jedrih pod visoko obremenitvijo, čeprav so vsi strežniki delovali na enaki ravni.
To ni napaka merjenja, toleranca je največ +-1ms v zakasnitev in ne več kot +-2-3 zahtevki na sekundo za RPR.
Rezultati, ko se 8 jedra izkažejo slabše, niso presenetljivi; veliko jeder in SMT/Hyperthreading močno zmanjšata zmogljivost, če imamo časovne okvire, v katerih moramo dokončati celoten proces.
Izvor: habr.com
