WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:

Mes kalbėjome apie techniką pirmoji dalis Šiame straipsnyje mes išbandome HTTPS, bet realistiškesniais scenarijais. Bandymui gavome sertifikatą Let's Encrypt ir įjungėme „Brotli“ glaudinimą iki 11.

Šį kartą pabandysime atkartoti scenarijų, kai serveris įdiegiamas VDS arba kaip virtuali mašina pagrindiniame kompiuteryje su standartiniu procesoriumi. Šiuo tikslu buvo nustatytas limitas:

  • 25% – tai atitinka ~ 1350 MHz dažnį
  • 35% -1890MHz
  • 41% - 2214 MHz
  • 65% - 3510 MHz

Vienkartinių jungčių skaičius sumažintas nuo 500 iki 1, 3, 5, 7 ir 9,

Rezultatai:

Vėlavimai:

TTFB buvo specialiai įtrauktas kaip atskiras testas, nes HTTPD įrankiai kiekvienai individualiai užklausai sukuria naują vartotoją. Šis testas dar gana atitrūkęs nuo realybės, nes vartotojas vis tiek spustels porą puslapių, o realiai pagrindinį vaidmenį atliks TTFP.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Pirmoji, paprastai pati pirmoji užklausa po pirmojo IIS virtualiosios mašinos paleidimo trunka vidutiniškai 120 ms.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Visos paskesnės užklausos rodo 1.5 ms TTFP. Šiuo atžvilgiu „Apache“ ir „Nginx“ atsilieka. Asmeniškai autorius šį testą laiko labiausiai atskleidžiančiu ir tik pagal jį rinktų nugalėtoją.
Rezultatas nenuostabu, nes IIS talpykloje saugo jau suglaudintą statinį turinį ir nesuglaudina jo kiekvieną kartą, kai jis pasiekiamas.

Laikas, praleistas vienam klientui

Norint įvertinti našumą, pakanka bandymo su 1 vienu ryšiu.
Pavyzdžiui, IIS atliko 5000 vartotojų testą per 40 sekundžių, tai yra 123 užklausos per sekundę.

Toliau pateiktose diagramose parodytas laikas, iki kurio svetainės turinys bus visiškai perkeltas. Tai per tam tikrą laiką įvykdytų užklausų dalis. Mūsų atveju 80 % visų užklausų buvo apdorotos per 8 ms naudojant IIS ir per 4.5 ms naudojant Apache ir Nginx, o 8 % visų užklausų Apache ir Nginx buvo įvykdytos per 98 milisekundžių intervalą.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Laikas, per kurį buvo apdorota 5000 XNUMX užklausų:

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Laikas, per kurį buvo apdorota 5000 XNUMX užklausų:

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Jei turite virtualią mašiną su 3.5 GHz procesoriumi ir 8 branduoliais, pasirinkite, ko norite. Visi žiniatinklio serveriai šiame bandyme yra labai panašūs. Toliau kalbėsime apie tai, kurį žiniatinklio serverį pasirinkti kiekvienam pagrindiniam kompiuteriui.

Kalbant apie šiek tiek realesnę situaciją, visi žiniatinklio serveriai eina vienas į kitą.

Pralaidumas:

Vėlavimų ir vienalaikių jungčių skaičiaus grafikas. Lygesnis ir žemesnis yra geriau. Paskutiniai 2% buvo pašalinti iš diagramų, nes dėl jų jie taptų neįskaitomi.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Dabar apsvarstykime parinktį, kur serveris yra priglobtas virtualioje priegloboje. Paimkime 4 branduolius 2.2 GHz dažniu ir vieną branduolį 1.8 GHz dažniu.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:

Kaip nustatyti mastelį

Jei kada nors matėte, kaip atrodo vakuuminių triodų, pentodų ir tt srovės-įtampos charakteristikos, šie grafikai jums bus žinomi. Tai ir bandome pagauti – prisotinimą. Riba yra tada, kai nesvarbu, kiek branduolių išmestumėte, našumo padidėjimas nebus pastebimas.

Anksčiau visas iššūkis buvo apdoroti 98 % užklausų su mažiausia visų užklausų delsa, išlaikant kuo plokštesnę kreivę. Dabar, sukonstruodami kitą kreivę, rasime optimalų kiekvieno serverio veikimo tašką.

Norėdami tai padaryti, paimkime užklausų per sekundę (RPR) indikatorių. Horizontalus – dažnis, vertikalus – per sekundę apdorojamų užklausų skaičius, linijos – branduolių skaičius.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Rodo ryšį, kaip gerai Nginx apdoroja užklausas vieną po kitos. Šiame teste geriau veikia 8 branduoliai.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Šis grafikas aiškiai parodo, kiek geriau (ne daug) Nginx veikia viename branduolyje. Jei turite „Nginx“, turėtumėte apsvarstyti galimybę sumažinti branduolių skaičių iki vieno, jei talpinate tik statinius.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
IIS, nors pagal DevTools in Chrome turi mažiausią TTFB, rimtai kovodama su Apache fondo testavimu nepalankiausiomis sąlygomis sugeba pralaimėti ir Nginx, ir Apache.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:
Visas grafikų kreivumas atkuriamas geležiniu būdu.

Kažkokia išvada:

Taip, „Apache“ blogiau veikia su 1 ir 8 branduoliais, bet veikia šiek tiek geriau su 4 branduoliais.

Taip, „Nginx“ 8 branduoliuose geriau apdoroja užklausas vieną po kitos, 1 ir 4 branduoliuose, ir veikia prasčiau, kai yra daug jungčių.

Taip, IIS teikia pirmenybę 4 branduoliams kelių gijų darbo krūviams ir 8 branduoliams vienos gijos darbo krūviams. Galiausiai IIS buvo šiek tiek greitesnis nei visi kiti 8 branduoliuose esant didelei apkrovai, nors visi serveriai buvo lygiaverčiai.

Tai nėra matavimo paklaida, čia paklaida yra ne didesnė kaip +-1 ms. vėlavimai ir ne daugiau kaip +- 2-3 užklausos per sekundę RPR.

Rezultatai, kai 8 branduoliai veikia prasčiau, visiškai nestebina, daug branduolių ir SMT/Hyperthreading labai pablogina našumą, jei turime laiko tarpą, per kurį turime užbaigti visą dujotiekį.

WEB serverių mūšis. 2 dalis – Realus HTTPS scenarijus:

Šaltinis: www.habr.com

Добавить комментарий