Við ræddum um aðferðafræðina í grein, í þessari prófum við HTTPS, en í raunhæfari aðstæðum. Til að prófa fengum við Let's Encrypt vottorð og kveiktum á Brotli þjöppun í 11.
Að þessu sinni ætlum við að reyna að endurskapa atburðarásina að setja netþjón á VDS eða sem sýndarvél á hýsil með venjulegum örgjörva. Í þessu skyni voru mörk sett við:
- 25% - Sem jafngildir tíðni upp á ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Einskiptistengingum hefur fækkað úr 500 í 1, 3, 5, 7 og 9,
Úrslit:
Tafir:
TTFB var sérstaklega innifalið sem sérstakt próf, vegna þess að HTTPD Tools býr til nýjan notanda fyrir hverja einstaka beiðni. Þetta próf er enn frekar aðskilið frá raunveruleikanum, því notandinn mun samt smella á nokkrar síður og í raun mun TTFP gegna aðalhlutverkinu.
Fyrsta, yfirleitt allra fyrsta beiðnin eftir fyrstu ræsingu IIS sýndarvélarinnar tekur að meðaltali 120 ms.
Allar síðari beiðnir sýna TTFP upp á 1.5 ms. Apache og Nginx eru á eftir í þessum efnum. Persónulega telur höfundur þetta próf mest afhjúpandi og myndi velja sigurvegarann eingöngu út frá því.
Niðurstaðan kemur ekki á óvart þar sem IIS skyndiminni hefur þegar þjappað kyrrstætt efni og þjappar því ekki í hvert skipti sem það er opnað.
Tími sem varið er á hvern viðskiptavin
Til að meta árangur nægir próf með einni tengingu.
Til dæmis lauk IIS prófi með 5000 notendum á 40 sekúndum, sem er 123 beiðnir á sekúndu.
Gröfin hér að neðan sýna tímann þar til innihald vefsvæðisins er að fullu flutt. Þetta er hlutfall beiðna sem lokið er við á tilteknum tíma. Í okkar tilviki voru 80% allra beiðna afgreidd á 8 ms á IIS og á 4.5 ms á Apache og Nginx, og 8% allra beiðna um Apache og Nginx var afgreitt á allt að 98 millisekúndna millibili.
Tími sem 5000 beiðnir voru afgreiddar á:
Tími sem 5000 beiðnir voru afgreiddar á:
Ef þú ert með sýndarvél með 3.5GHz örgjörva og 8 kjarna, veldu þá það sem þú vilt. Allir vefþjónar eru mjög svipaðir í þessari prófun. Við munum tala um hvaða vefþjón á að velja fyrir hvern gestgjafa hér að neðan.
Þegar kemur að aðeins raunhæfari aðstæðum fara allir vefþjónar á hausinn.
Afköst:
Graf yfir tafir á móti fjölda samtímis tenginga. Mýkri og lægri er betra. Síðustu 2% voru fjarlægð af töflunum vegna þess að þau myndu gera þau ólæsileg.
Nú skulum við íhuga möguleikann þar sem þjónninn er hýstur á sýndarhýsingu. Tökum 4 kjarna á 2.2 GHz og einn kjarna á 1.8 GHz.
Hvernig á að skala
Ef þú hefur einhvern tíma séð hvernig straumspennueiginleikar tómarúmþríóða, pentóda og svo framvegis líta út, munu þessi línurit vera kunnugleg fyrir þig. Þetta er það sem við erum að reyna að ná - mettun. Takmörkin eru þegar það er sama hversu mörgum kjarna þú kastar, frammistöðuaukningin verður ekki áberandi.
Áður fyrr var öll áskorunin að vinna úr 98% beiðna með lægstu leynd fyrir allar beiðnir og halda ferlinum eins flötum og hægt er. Nú, með því að smíða annan feril, munum við finna ákjósanlegasta rekstrarpunktinn fyrir hvern og einn netþjóna.
Til að gera þetta skulum við taka vísbendingu um beiðnir á sekúndu (RPR). Lárétt er tíðnin, lóðrétt er fjöldi beiðna sem unnar eru á sekúndu, línur eru fjöldi kjarna.
Sýnir fylgni við hversu vel Nginx vinnur úr beiðnum hverja á eftir annarri. 8 kjarna standa sig betur í þessu prófi.
Þetta línurit sýnir greinilega hversu miklu betur (ekki mikið) Nginx virkar á einum kjarna. Ef þú ert með Nginx ættir þú að íhuga að fækka kjarna í einn ef þú ert að hýsa aðeins kyrrstæða.
IIS, þó að það hafi lægsta TTFB samkvæmt DevTools í Chrome, tekst að tapa fyrir bæði Nginx og Apache í alvarlegri baráttu við álagsprófið frá Apache Foundation.
Öll sveigjan á línuritunum er endurgerð járnklædd.
Einhvers konar niðurstaða:
Já, Apache virkar verr á 1 og 8 kjarna, en virkar aðeins betur á 4.
Já, Nginx á 8 kjarna vinnur betur eftir beiðnum, á 1 og 4 kjarna, og virkar verr þegar það eru margar tengingar.
Já, IIS kýs 4 kjarna fyrir margþráða vinnuálag og kýs 8 kjarna fyrir einn-þráða vinnuálag. Að lokum var IIS örlítið hraðari en allir aðrir á 8 kjarna undir miklu álagi, þó allir netþjónar væru á pari.
Þetta er ekki mælivilla, villa hér er ekki meira en +-1ms. í töfum og ekki meira en +- 2-3 beiðnir á sekúndu fyrir RPR.
Niðurstöðurnar þar sem 8 kjarna standa sig verr koma alls ekki á óvart, margir kjarna og SMT/Hyperthreading draga mjög úr frammistöðu ef við höfum tímaramma þar sem við þurfum að klára alla leiðsluna.
Heimild: www.habr.com