Ons het gesels oor die tegniek in artikel, in hierdie een toets ons HTTPS, maar in meer realistiese scenario's. Vir toetsing is 'n Let's Encrypt-sertifikaat verkry, Brotli-kompressie is op 11 geaktiveer.
Hierdie keer sal ons probeer om die scenario weer te gee van die implementering van 'n bediener op 'n VDS of as 'n virtuele masjien op 'n gasheer met 'n standaardverwerker. Vir hierdie doel is 'n limiet gestel op:
- 25% - Wat gelykstaande is aan 'n frekwensie van ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Die aantal eenmalige verbindings is verminder van 500 na 1, 3, 5, 7 en 9,
Resultate:
Vertragings:
TTFB is spesifiek ingesluit as 'n aparte toets, omdat HTTPD Tools 'n nuwe gebruiker vir elke individuele versoek skep. Hierdie toets is nog redelik los van die werklikheid, want die gebruiker sal nog 'n paar bladsye klik, en in werklikheid sal TTFP die hoofrol speel.
Die eerste, gewoonlik die heel eerste versoek na die eerste aanvang van die IIS virtuele masjien duur gemiddeld 120 ms.
Alle daaropvolgende versoeke toon 'n TTFP van 1.5 ms. Apache en Nginx loop agter in hierdie verband. Persoonlik beskou die skrywer hierdie toets as die mees onthullende en sou die wenner slegs op grond daarvan kies.
Die resultaat is nie verbasend nie, aangesien IIS reeds saamgeperste statiese inhoud in die kas kas en dit nie saampers elke keer as dit toegang verkry word nie.
Tyd spandeer per kliënt
Om prestasie te evalueer, is 'n toets met 1 enkele verbinding voldoende.
Byvoorbeeld, IIS het 'n toets van 5000 gebruikers in 40 sekondes voltooi, wat 123 versoeke per sekonde is.
Die grafieke hieronder toon die tyd totdat die webwerf-inhoud heeltemal oorgedra is. Dit is die verhouding van versoeke wat in 'n gegewe tyd voltooi is. In ons geval is 80% van alle versoeke in 8ms op IIS en in 4.5ms op Apache en Nginx verwerk, en 8% van alle versoeke op Apache en Nginx is binne 'n interval van tot 98 millisekondes voltooi.
Tyd waartydens 5000 versoeke verwerk is:
Tyd waartydens 5000 versoeke verwerk is:
As jy 'n virtuele masjien het met 'n 3.5GHz SVE en 8 kerne, kies dan wat jy wil hê. Alle webbedieners is baie soortgelyk in hierdie toetsing. Ons sal hieronder praat oor watter webbediener om vir elke gasheer te kies.
As dit kom by 'n effens meer realistiese situasie, gaan alle webbedieners kop aan kop.
deurset:
Grafiek van vertragings teenoor die aantal gelyktydige verbindings. Gladder en laer is beter. Die laaste 2% is van die kaarte verwyder omdat dit hulle onleesbaar sou maak.
Kom ons kyk nou na die opsie waar die bediener op virtuele hosting gehuisves word. Kom ons neem 4 kerns by 2.2 GHz en een kern by 1.8 GHz.
Hoe om te skaal
As jy al ooit gesien het hoe die stroomspanningseienskappe van vakuumtriodes, pentodes, ensovoorts lyk, sal hierdie grafieke aan jou bekend wees. Dit is wat ons probeer vang - versadiging. Die limiet is wanneer, ongeag hoeveel kerne jy gooi, die prestasieverhoging nie merkbaar sal wees nie.
Voorheen was die hele uitdaging om 98% van versoeke te verwerk met die laagste vertraging vir alle versoeke, om die kromme so plat as moontlik te hou. Nou, deur 'n ander kromme te bou, sal ons die optimale bedryfspunt vir elk van die bedieners vind.
Om dit te doen, kom ons neem die Versoeke per sekonde (RPR) aanwyser. Horisontaal is die frekwensie, vertikaal is die aantal versoeke wat per sekonde verwerk word, lyne is die aantal kerns.
Toon 'n korrelasie van hoe goed Nginx versoeke een na die ander verwerk. 8 kerne presteer beter in hierdie toets.
Hierdie grafiek wys duidelik hoeveel beter (nie veel nie) Nginx op 'n enkele kern werk. As u Nginx het, moet u dit oorweeg om die aantal kerns tot een te verminder as u slegs statiese kerne aanbied.
IIS, hoewel dit volgens DevTools in Chrome die laagste TTFB het, slaag daarin om teen beide Nginx en Apache te verloor in 'n ernstige stryd met die strestoets van die Apache Foundation.
Al die kromming van die grafieke word ysterbekleed weergegee.
Een of ander gevolgtrekking:
Ja, Apache werk slegter op 1 en 8 kern, maar werk 'n bietjie beter op 4.
Ja, Nginx op 8 kerne prosesse versoek beter een na die ander, op 1 en 4 cores, en werk slegter as daar baie verbindings is.
Ja, IIS verkies 4 kerns vir multi-threaded werkladings en verkies 8 cores vir enkel-threaded workloads. Uiteindelik was IIS effens vinniger as almal anders op 8 kerne onder hoë las, hoewel alle bedieners op gelyke voet was.
Dit is nie 'n meetfout nie, die fout hier is nie meer as +-1ms nie. in vertragings en nie meer as +- 2-3 versoeke per sekonde vir RPR nie.
Die resultate waar 8 kerns swakker presteer is glad nie verbasend nie, baie kerns en SBS/Hyperthreading verswak prestasie aansienlik as ons 'n tydraamwerk het waarin ons die hele pyplyn moet voltooi.
Bron: will.com