Razgovarali smo o metodologiji u članka, u ovom testiramo HTTPS, ali u realističnijim scenarijima. Za testiranje smo dobili certifikat Let's Encrypt i omogućili Brotli kompresiju na 11.
Ovaj put ćemo pokušati da reproduciramo scenario postavljanja servera na VDS ili kao virtuelne mašine na hostu 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 sa 500 na 1, 3, 5, 7 i 9,
Rezultati:
kašnjenja:
TTFB je posebno uključen kao poseban test, jer HTTPD Tools kreira novog korisnika za svaki pojedinačni zahtjev. Ovaj test je još uvijek prilično odvojen od stvarnosti, jer će korisnik i dalje kliknuti nekoliko stranica, a u stvarnosti će glavnu ulogu igrati TTFP.
Prvi, općenito prvi zahtjev nakon prvog pokretanja IIS virtuelne mašine traje u prosjeku 120 ms.
Svi naredni zahtjevi pokazuju TTFP od 1.5 ms. Apache i Nginx u tom pogledu zaostaju. Lično, autor ovaj test smatra najrazotkrivanijim i samo bi na osnovu njega izabrao pobjednika.
Rezultat nije iznenađujući jer IIS kešira već komprimirani statički sadržaj i ne komprimira ga svaki put kada mu se pristupi.
Vrijeme utrošeno po klijentu
Za procjenu performansi dovoljan je test sa 1 jednom vezom.
Na primjer, IIS je završio test od 5000 korisnika za 40 sekundi, što je 123 zahtjeva u sekundi.
Grafikoni u nastavku pokazuju vrijeme do potpunog prijenosa sadržaja stranice. Ovo je udio zahtjeva ispunjenih u datom vremenu. U našem slučaju, 80% svih zahtjeva obrađeno je za 8ms na IIS-u i 4.5ms na Apache i Nginx, a 8% svih zahtjeva na Apache i Nginx je završeno u intervalu do 98 milisekundi.
Vrijeme u kojem je obrađeno 5000 zahtjeva:
Vrijeme u kojem je obrađeno 5000 zahtjeva:
Ako imate virtuelnu mašinu sa 3.5GHz CPU-om i 8 jezgara, onda izaberite šta želite. Svi web serveri su vrlo slični u ovom testiranju. U nastavku ćemo razgovarati o tome koji web server odabrati za svaki host.
Kada je u pitanju malo realnija situacija, svi web serveri idu jedan uz drugog.
Propusnost:
Grafikon kašnjenja u odnosu na broj istovremenih veza. Bolje je glađe i niže. Posljednjih 2% uklonjeno je sa grafikona jer bi ih učinili nečitljivim.
Sada razmotrimo opciju gdje se server nalazi na virtuelnom hostingu. Uzmimo 4 jezgra na 2.2 GHz i jedno jezgro na 1.8 GHz.
Kako skalirati
Ako ste ikada vidjeli kako izgledaju strujno-naponske karakteristike vakuumskih trioda, pentoda i tako dalje, ovi grafovi će vam biti poznati. To je ono što pokušavamo uhvatiti - zasićenost. Ograničenje je kada bez obzira na to koliko jezgri bacite, povećanje performansi neće biti primjetno.
Ranije je cijeli izazov bio obraditi 98% zahtjeva s najmanjim kašnjenjem za sve zahtjeve, držeći krivulju što je moguće ravnom. Sada, konstruisanjem druge krive, naći ćemo optimalnu radnu tačku za svaki od servera.
Da bismo to učinili, uzmimo indikator zahtjeva u sekundi (RPR). Horizontalno je frekvencija, vertikalno je broj obrađenih zahtjeva u sekundi, linije su broj jezgara.
Pokazuje korelaciju koliko dobro Nginx obrađuje zahtjeve jedan za drugim. 8 jezgara radi bolje na ovom testu.
Ovaj grafikon jasno pokazuje koliko bolje (ne mnogo) Nginx radi na jednoj jezgri. Ako imate Nginx, trebali biste razmisliti o smanjenju broja jezgri na jedno ako hostirate samo statične.
IIS, iako ima najniži TTFB prema DevTools u Chromeu, uspijeva izgubiti i od Nginxa i od Apachea u ozbiljnoj borbi sa stres testom od Apache Foundation.
Sva zakrivljenost grafova je reprodukovana gvožđem.
Nekakav zaključak:
Da, Apache radi lošije na 1 i 8 jezgri, ali radi malo bolje na 4.
Da, Nginx na 8 jezgara bolje obrađuje zahtjeve jedan za drugim, na 1 i 4 jezgre, a radi lošije kada ima mnogo veza.
Da, IIS preferira 4 jezgra za radna opterećenja s više niti, a preferira 8 jezgara za jednonitna radna opterećenja. Na kraju, IIS je bio nešto brži od svih ostalih na 8 jezgara pod velikim opterećenjem, iako su svi serveri bili na nivou.
Ovo nije greška mjerenja, greška ovdje nije veća od +-1ms. u kašnjenjima i ne više od +- 2-3 zahtjeva u sekundi za RPR.
Rezultati u kojima 8 jezgara radi lošije nisu nimalo iznenađujući, mnoga jezgra i SMT/Hyperthreading uvelike degradiraju performanse ako imamo vremenski okvir u kojem moramo završiti cijeli pipeline.
izvor: www.habr.com