Am vorbit despre metodologia în articol, în acesta testăm HTTPS, dar în scenarii mai realiste. Pentru testare, am obținut un certificat Let's Encrypt și am activat compresia Brotli la 11.
De data aceasta vom încerca să reproducem scenariul implementării unui server pe un VDS sau ca o mașină virtuală pe o gazdă cu un procesor standard. În acest scop, a fost stabilită o limită la:
- 25% - Ceea ce este echivalent cu o frecvență de ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Numărul de conexiuni unice a fost redus de la 500 la 1, 3, 5, 7 și 9,
Rezultate:
Întârzieri:
TTFB a fost inclus în mod special ca un test separat, deoarece HTTPD Tools creează un utilizator nou pentru fiecare cerere individuală. Acest test este încă destul de detașat de realitate, deoarece utilizatorul va face totuși clic pe câteva pagini, iar în realitate TTFP va juca rolul principal.
Prima, în general, prima solicitare după prima pornire a mașinii virtuale IIS durează în medie 120 ms.
Toate solicitările ulterioare arată un TTFP de 1.5 ms. Apache și Nginx sunt în urmă în acest sens. Personal, autorul consideră acest test cel mai revelator și ar alege câștigătorul doar pe baza lui.
Rezultatul nu este surprinzător, deoarece IIS memorează în cache conținutul static deja comprimat și nu îl comprimă de fiecare dată când este accesat.
Timp petrecut per client
Pentru a evalua performanța, este suficient un test cu o singură conexiune.
De exemplu, IIS a finalizat un test de 5000 de utilizatori în 40 de secunde, adică 123 de solicitări pe secundă.
Graficele de mai jos arată timpul până când conținutul site-ului este transferat complet. Aceasta este proporția de solicitări finalizate într-un anumit timp. În cazul nostru, 80% din toate solicitările au fost procesate în 8 ms pe IIS și în 4.5 ms pe Apache și Nginx, iar 8% din toate solicitările pe Apache și Nginx au fost finalizate într-un interval de până la 98 milisecunde.
Timp în care au fost procesate 5000 de solicitări:
Timp în care au fost procesate 5000 de solicitări:
Dacă aveți o mașină virtuală cu un procesor de 3.5 GHz și 8 nuclee, atunci alegeți ceea ce doriți. Toate serverele web sunt foarte asemănătoare în această testare. Vom vorbi mai jos despre ce server web să alegem pentru fiecare gazdă.
Când vine vorba de o situație ceva mai realistă, toate serverele web merg cap la cap.
Randament:
Graficul întârzierilor față de numărul de conexiuni simultane. Mai neted și mai jos este mai bine. Ultimele 2% au fost eliminate din grafice pentru că le-ar face imposibil de citit.
Acum să luăm în considerare opțiunea în care serverul este găzduit pe găzduire virtuală. Să luăm 4 nuclee la 2.2 GHz și un nucleu la 1.8 GHz.
Cum să scalați
Dacă ați văzut vreodată cum arată caracteristicile curent-tensiune ale triodelor de vid, pentodelor și așa mai departe, aceste grafice vă vor fi familiare. Aceasta este ceea ce încercăm să prindem - saturația. Limita este atunci când indiferent câte nuclee ai arunca, creșterea performanței nu va fi vizibilă.
Anterior, întreaga provocare era să procesăm 98% din solicitări cu cea mai mică latență pentru toate solicitările, păstrând curba cât mai plată posibil. Acum, construind o altă curbă, vom găsi punctul optim de operare pentru fiecare dintre servere.
Pentru a face acest lucru, să luăm indicatorul Cereri pe secundă (RPR). Orizontală este frecvența, verticală este numărul de solicitări procesate pe secundă, liniile sunt numărul de nuclee.
Afișează o corelație a cât de bine procesează Nginx cererile una după alta. 8 nuclee funcționează mai bine în acest test.
Acest grafic arată clar cât de mai bine (nu mult) funcționează Nginx pe un singur nucleu. Dacă aveți Nginx, ar trebui să luați în considerare reducerea numărului de nuclee la unul dacă găzduiți numai nuclee statice.
IIS, deși are cel mai mic TTFB conform DevTools în Chrome, reușește să piardă atât în fața Nginx, cât și în Apache într-o luptă serioasă cu testul de stres de la Apache Foundation.
Toată curbura graficelor este reprodusă de fier.
Un fel de concluzie:
Da, Apache funcționează mai rău pe 1 și 8 nuclee, dar funcționează puțin mai bine pe 4.
Da, Nginx pe 8 nuclee procesează cererile mai bine una după alta, pe 1 și 4 nuclee și funcționează mai rău atunci când există multe conexiuni.
Da, IIS preferă 4 nuclee pentru sarcinile de lucru cu mai multe fire și preferă 8 nuclee pentru sarcinile cu un singur thread. În cele din urmă, IIS a fost puțin mai rapid decât toți ceilalți pe 8 nuclee sub sarcină mare, deși toate serverele erau la egalitate.
Aceasta nu este o eroare de măsurare, eroarea aici nu este mai mare de +-1 ms. în întârzieri și nu mai mult de +- 2-3 solicitări pe secundă pentru RPR.
Rezultatele în care 8 nuclee funcționează mai rău nu sunt deloc surprinzătoare, multe nuclee și SMT/Hyperthreading degradează foarte mult performanța dacă avem un interval de timp în care trebuie să finalizăm întreaga conductă.
Sursa: www.habr.com