Despre metodă am vorbit în a articolului, în aceasta testăm HTTPS, dar în scenarii mai realiste. Pentru testare, a fost obținut un certificat Let’s Encrypt, iar compresia Brotli a fost activată la 11.
De această dată vom încerca să reproducem un scenariu de implementare a unui server pe VDS sau ca mașină virtuală pe un host cu procesor standard. Pentru aceasta, am stabilit un limită de:
- 25% — ceea ce echivalează cu o frecvență de ~ 1350MHz
- 35% - 1890MHz
- 41% — 2214MHz
- 65% — 3510MHz
Numărul de conexiuni simultane a scăzut de la 500 la 1, 3, 5, 7 și 9,
Rezultatele:
întârzieri:
TTFB a fost special dedicat ca un test separat, deoarece HTTPD Tools creează un utilizator nou pentru fiecare cerere. Acest test este totuși destul de detașat de realitate, deoarece utilizatorul tot va da clic pe câteva pagini, iar în realitate, TTFP va juca un rol principal.
Prima, cu adevărat prima cerere după prima pornire a mașinii virtuale IIS, durează în medie 120 ms.
Toate cererile ulterioare arată un TTFP de 1.5 ms. Apache și Nginx dezvăluie un dezavantaj în acest sens. Personal, autorul consideră acest test cel mai concludent și ar alege câștigătorul doar pe baza acestuia.
Rezultatul nu este surprinzător, deoarece IIS cachează deja conținutul static comprimat și nu îl recompresase de fiecare dată când este accesat.
Timpul petrecut pe un client
Pentru a evalua performanța, un test cu 1 conexiune simultană este suficient.
De exemplu, IIS a finalizat testul cu 5000 de utilizatori în 40 de secunde, ceea ce înseamnă 123 de cereri pe secundă.
În graficele de mai jos este prezentat timpul până la transferul complet al conținutului site-ului. Aceasta este proporția cererilor efectuate la un anumit timp. În cazul nostru, 80% din toate cererile au fost procesate în 8ms pe IIS și în 4.5ms pe Apache și Nginx, iar intervalul până la 8 milisecunde s-a realizat pentru 98% din cereri pe Apache și Nginx.
Timpul în care 5000 de cereri au fost procesate:
Timpul în care 5000 de cereri au fost procesate:
Dacă aveți o mașină virtuală cu un CPU de 3.5GHz și 8 nuclei, atunci alegeți ceea ce doriți. Toate serverele web sunt foarte asemănătoare în acest test. Despre ce server web să alegeți pentru fiecare host vom discuta mai jos.
Când vine vorba de o situație puțin mai reală, toate serverele web se află una lângă alta.
Debitul:
Graficele de întârziere în funcție de numărul de conexiuni simultane. Cu cât linia este mai plată și mai jos, cu atât este mai bine. Ultimele 2% au fost excluse din grafice deoarece le-ar face ilizibile.
Acum să luăm în considerare varianta în care serverul este găzduit pe un server virtual. Să luăm 4 nuclee de 2,2 GHz și un nucleu de 1,8 GHz.
Cum se scalează
Dacă ai văzut vreodată cum arată curbele caracteristicilor electrice ale triodelor și pentodelor, aceste grafice îți vor fi familiare. Acesta este ceea ce încercăm să surprindem – saturația. Limita în care, indiferent câte nuclee adaugi, creșterea performanței nu va fi vizibilă.
Anterior, întreaga provocare consta în a procesa 98% din cereri având cea mai mică întârziere. Acum, prin construirea unei alte curbe, vom găsi punctul de lucru optim pentru fiecare dintre servere.
Pentru aceasta, vom lua indicatorul Cereri pe secundă (RPR). Pe orizontală este frecvența, pe verticală – numărul de cereri procesate pe secundă, iar liniile – numărul de nuclee.
Aici este arătată corelația cât de bine Nginx procesează cererile una după alta. 8 nuclee în acest tip de testare își demonstrează superioritatea.
Acest grafic arată foarte bine cât de mult mai bine (nu cu mult) Nginx funcționează pe un singur nucleu. Dacă ai Nginx, merită să te gândești să reduci numărul de nuclee la unul, dacă găzduiești doar fișiere statice.
Deși IIS are cel mai mic TTFB conform DevTools în Chrome, reușește să piardă în fața atât a Nginx, cât și a Apache în testele de stres riguroase de la Apache Foundation.
Toată curvatura graficelor este reproduse exact.
O concluzie de acest gen:
Da, Apache funcționează clar mai rău pe 1 și 8 nuclee, iar pe 4 funcționează puțin mai bine.
Da, Nginx pe 8 nuclee procesează mai bine cererile una după alta, iar pe 1 și 4 nuclee funcționează mai slab, când sunt multe conexiuni.
Da, IIS preferă 4 nuclee pentru sarcini multi-threading și preferă 8 nuclee pentru sarcini single-threading. În cele din urmă, IIS s-a dovedit puțin mai rapid decât toate pe 8 nuclee sub o sarcină mare, deși toate serverele au fost la egalitate.
Aceasta nu este o eroare de măsurare, deviația nu depășește +-1 ms în întârziere și nu mai mult de +-2-3 cereri pe secundă pentru RPR.
Rezultatele în care 8 nuclee se comportă mai rău nu sunt deloc surprinzătoare; multe nuclee și SMT/Hyperthreading afectează semnificativ performanța, dacă avem o fereastră de timp în care trebuie să finalizăm întregul pipeline.
Sursa: habr.com
