Razgovarali smo o tehnici u članku, u ovom testiramo HTTPS, ali u realističnijim scenarijima. Za testiranje smo nabavili Let's Encrypt certifikat i omogućili Brotli kompresiju na 11.
Ovaj put pokušat ćemo reproducirati scenarij postavljanja poslužitelja na VDS ili kao virtualni stroj na glavnom računalu sa standardnim procesorom. U tu svrhu postavljeno je ograničenje na:
- 25% - Što je ekvivalentno frekvenciji od ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Broj jednokratnih priključaka smanjen je s 500 na 1, 3, 5, 7 i 9,
Rezultati:
Kašnjenja:
TTFB je posebno uključen kao zaseban test, jer HTTPD Tools stvara novog korisnika za svaki pojedinačni zahtjev. Ovaj test je još dosta odvojen od stvarnosti, jer će korisnik ipak kliknuti par stranica, au stvarnosti će glavnu ulogu imati TTFP.
Prvi, uglavnom prvi zahtjev nakon prvog pokretanja IIS virtualnog stroja traje u prosjeku 120 ms.
Svi sljedeći zahtjevi pokazuju TTFP od 1.5 ms. Apache i Nginx zaostaju u tom pogledu. Osobno, autor ovaj test smatra najotkrivenijim i samo bi na temelju njega izabrao pobjednika.
Rezultat nije iznenađujući jer IIS sprema već komprimirani statički sadržaj i ne komprimira ga svaki put kada mu se pristupi.
Vrijeme potrošeno po klijentu
Za procjenu performansi dovoljan je test s 1 jednom vezom.
Na primjer, IIS je završio test od 5000 korisnika u 40 sekundi, što je 123 zahtjeva u sekundi.
Grafikoni ispod prikazuju vrijeme do potpunog prijenosa sadržaja stranice. Ovo je udio zahtjeva ispunjenih u određenom vremenu. U našem slučaju, 80% svih zahtjeva obrađeno je za 8ms na IIS-u i za 4.5ms na Apacheu i Nginxu, a 8% svih zahtjeva na Apacheu i Nginxu završeno je unutar intervala do 98 milisekundi.
Vrijeme u kojem je obrađeno 5000 zahtjeva:
Vrijeme u kojem je obrađeno 5000 zahtjeva:
Ako imate virtualni stroj s CPU-om od 3.5 GHz i 8 jezgri, odaberite što želite. Svi su web poslužitelji vrlo slični u ovom testiranju. U nastavku ćemo govoriti o tome koji web poslužitelj odabrati za svaki host.
Kad je malo realnija situacija u pitanju, svi web serveri idu jedan uz drugog.
Propusnost:
Grafikon kašnjenja u odnosu na broj istodobnih veza. Glatkije i niže je bolje. Zadnjih 2% uklonjeno je s ljestvica jer bi ih učinilo nečitljivima.
Razmotrimo sada opciju gdje je poslužitelj smješten na virtualnom hostingu. Uzmimo 4 jezgre na 2.2 GHz i jednu jezgru na 1.8 GHz.
Kako mjeriti
Ako ste ikada vidjeli kako izgledaju strujno-naponske karakteristike vakuumskih trioda, pentoda i tako dalje, ovi će vam grafikoni biti poznati. To je ono što pokušavamo uhvatiti - zasićenje. Granica je kada bez obzira koliko jezgri bacite, povećanje performansi neće biti vidljivo.
Prethodno je cijeli izazov bio obraditi 98% zahtjeva s najnižom latencijom za sve zahtjeve, održavajući krivulju što ravnijom. Sada, konstruiranjem druge krivulje, pronaći ćemo optimalnu radnu točku za svaki od poslužitelja.
Da bismo to učinili, uzmimo indikator zahtjeva u sekundi (RPR). Horizontalno je frekvencija, okomito je broj zahtjeva obrađenih u sekundi, linije su broj jezgri.
Prikazuje korelaciju koliko dobro Nginx obrađuje zahtjeve jedan za drugim. 8 jezgri ima bolje rezultate u ovom testu.
Ovaj grafikon jasno pokazuje koliko bolje (ne puno) Nginx radi na jednoj jezgri. Ako imate Nginx, trebali biste razmisliti o smanjenju broja jezgri na jednu ako hostirate samo statičke.
IIS, iako ima najniži TTFB prema DevToolsu u Chromeu, uspijeva izgubiti i od Nginxa i od Apachea u ozbiljnoj borbi sa stres testom Apache Foundationa.
Sve zakrivljenosti grafova reproducirane su željezno.
Nekakav zaključak:
Da, Apache radi lošije na 1 i 8 jezgri, ali radi malo bolje na 4.
Da, Nginx na 8 jezgri bolje obrađuje zahtjeve jedan za drugim, na 1 i 4 jezgre, a radi lošije kada ima mnogo veza.
Da, IIS preferira 4 jezgre za radna opterećenja s više niti i preferira 8 jezgri za radna opterećenja s jednom niti. U konačnici, IIS je bio malo brži od svih ostalih na 8 jezgri pod velikim opterećenjem, iako su svi poslužitelji bili jednaki.
Ovo nije pogreška mjerenja, pogreška ovdje nije veća od +-1ms. u kašnjenjima i ne više od +- 2-3 zahtjeva u sekundi za RPR.
Rezultati gdje 8 jezgri rade lošije nisu nimalo iznenađujući, mnoge jezgre i SMT/Hyperthreading jako degradiraju performanse ako imamo vremenski okvir u kojem moramo dovršiti cijeli cjevovod.
Izvor: www.habr.com