Par metodoloÄ£iju mÄs stÄstÄ«jÄm rakstÄ, Å”ajÄ mÄs testÄjam HTTPS, bet reÄlistiskÄkos scenÄrijos. TestÄÅ”anai tika iegÅ«ts Letās Encrypt sertifikÄts, ieslÄgta Brotli saspieÅ”ana ar 11.
Å oreiz mÄÄ£inÄsim reproducÄt scenÄriju servera izvietoÅ”anai VDS vai kÄ virtuÄlas maŔīnas uz hosta ar standarta procesoru. Lai to izdarÄ«tu, tika uzstÄdÄ«ts limits:
- 25% ā kas atbilst frekvencei ~ 1350MHz
- 35% - 1890MHz
- 41% ā 2214MHz
- 65% ā 3510MHz
VienlaicÄ«go savienojumu skaits samazinÄjÄs no 500 lÄ«dz 1, 3, 5, 7 un 9,
RezultÄti:
Aiztures:
TTFB tika izdalÄ«ts kÄ atseviŔķs tests, jo HTTPD rÄ«ki katram atseviŔķam pieprasÄ«jumam rada it kÄ jaunu lietotÄju. Å is tests joprojÄm ir pietiekami atrauts no realitÄtes, jo lietotÄjs tomÄr noklikŔķinÄs uz vairÄkÄm lapÄm, un reÄlajÄ dzÄ«vÄ galveno lomu spÄlÄs TTFP.
Pirmais, vispÄr pirmais pieprasÄ«jums pÄc virtuÄlÄs maŔīnas IIS pirmÄs palaiÅ”anas vidÄji tiek izpildÄ«ts 120 ms.
Visi sekojoÅ”ie pieprasÄ«jumi rÄda TTFP 1.5 ms. Apache un Nginx Å”ajÄ atpaliek. Persona, kas raksta, uzskata Å”o testu par vispÄrÄjo rÄdÄ«tÄju un izvÄlÄtos uzvarÄtÄju tikai pÄc tÄ.
RezultÄts nav pÄrsteidzoÅ”s, jo IIS keÅ”atmiÅÄ saglabÄ jau saspiestu statisko saturu un to katru reizi nepÄrsaspiež, kad pie tÄ griežas.
Laiks, kas pavadīts pie viena klienta
Lai novÄrtÄtu veiktspÄju, pietiek ar testa ar 1 vienlaicÄ«gu savienojumu.
PiemÄram, IIS noslÄdza testa ar 5000 lietotÄjiem 40 sekundÄs, tas ir 123 pieprasÄ«jumi sekundÄ.
Grafikos zemÄk ir norÄdÄ«ts laiks, lÄ«dz pilnÄ«gai satura nodoÅ”anai vietnei. Tas ir pieprasÄ«jumu Ä«patsvars, kas tika izpildÄ«ts noteiktÄ laikÄ. MÅ«su gadÄ«jumÄ 80% visu pieprasÄ«jumu tika apstrÄdÄti 8ms uz IIS un 4.5ms uz Apache un Nginx, bet intervÄls lÄ«dz 8 milisekundÄm tika izpildÄ«ts 98% visu pieprasÄ«jumu uz Apache un Nginx.
Laiks, kurÄ 5000 pieprasÄ«jumu tika apstrÄdÄti:
Laiks, kurÄ 5000 pieprasÄ«jumu tika apstrÄdÄti:
Ja jums ir virtuÄla maŔīna ar 3.5GHz CPU un 8 kodoliem, tad izvÄlieties to, ko vÄlaties. Visi tÄ«mekļa serveri Å”ajÄ testÄÅ”anÄ ir ļoti lÄ«dzÄ«gi. Par to, kuru tÄ«mekļa serveri izvÄlÄties katram hostam, runÄsim zemÄk.
Kad runa ir par nedaudz reÄlistiskÄku situÄciju, visi tÄ«mekļa serveri ir vienÄ lÄ«menÄ«.
Ieguvums:
Aiztures grafiks no vienlaicÄ«go savienojumu skaita. Jo gludÄks un zemÄks ā jo labÄk. PÄdÄjie 2% tika izslÄgti no grafikiem, jo tie padarÄ«tu tos nesalasÄmus.
Tagad aplÅ«kosim variantu, kur serveris atrodas virtuÄlajÄ hostinga pakalpojuma. Å
emsim 4 kodolus pa 2.2GHz un vienu kodolu ar 1.8GHz.
KÄ scale
Ja jÅ«s jebkad esat redzÄjis, kÄ izskatÄs elektrovakuuma triodi, pentodi un tÄ tÄlÄk, Å”ie grafiki bÅ«s jums pazÄ«stami. TieÅ”i to mÄs cenÅ”amies noÄ·ert ā piesÄtinÄjumu. Robeža, kad cik daudz kodolu jÅ«s pievienojat, veiktspÄjas pieaugums nav pamanÄms.
IepriekÅ” visu izaicinÄjumu veidoja apstrÄdÄt 98% pieprasÄ«jumu ar viszemÄko aizturi visiem pieprasÄ«jumiem, cik vien iespÄjams vienmÄrÄ«gi turÄt lÄ«kni. Tagad, izmantojot citas lÄ«kÅu veidoÅ”anas metodes, atradÄ«sim optimÄlo darba punktu katram serverim.
Å im mÄrÄ·im mÄs Åemsim Requests per second (RPR) rÄdÄ«tÄju. HorizontÄli ir biežums, vertikÄli ā pieprasÄ«jumu skaits, kas apstrÄdÄts sekundÄ, lÄ«nijas ā kodolu skaits.
RÄdÄ«ta korelÄcija, cik labi Nginx apstrÄdÄ pieprasÄ«jumus viens pÄc otra. 8 kodolu Å”ÄdÄ testÄÅ”anÄ rÄdÄ«s labÄkus rezultÄtus.
Uz Ŕī grafika ir skaidri redzams, cik daudz labÄk (ne tik daudz) Nginx strÄdÄ uz viena kodola. Ja jums ir Nginx, vÄrts apsvÄrt samazinÄt kodolu skaitu lÄ«dz vienam, ja vienÄ«gais, ko hostÄjat, ir statika.
IIS, kaut arÄ« tam ir zemÄkais TTFB saskaÅÄ ar DevTools Chrome, tomÄr nespÄj pÄrspÄt ne Nginx, ne Apache nopietnÄ stress testÄ no Apache Foundation.
Visa grafiku izliekums tiek nodroÅ”inÄts uz dzelzs.
KÄds secinÄjums:
JÄ, Apache dzelzs stipri strÄdÄ vÄjÄk uz 1 un 8 kodoliem, bet uz 4 kodoliem nedaudz labÄk.
JÄ, Nginx uz 8 kodoliem apstrÄdÄ labÄk pieprasÄ«jumus viens pÄc otra, bet uz 1 un 4 kodoliem darbojÄs sliktÄk, ja ir daudz savienojumu.
JÄ, IIS dod priekÅ”roku 4 kodoliem daudzkodolu slodzei un dod priekÅ”roku 8 kodoliem vienkodolu slodzei. Galu galÄ IIS bija nedaudz ÄtrÄks par visiem uz 8 kodoliem ar augstu noslodzi, lai gan visi serveri gÄja vienÄ lÄ«nijÄ.
Tas nav mÄrÄ«Å”anas kļūda, kļūdas robeža Å”eit nav lielÄka par Ā±1ms aiztÅ«rÄ un ne vairÄk kÄ Ā±2-3 pieprasÄ«jumiem sekundÄ par RPR.
RezultÄti, kad 8 kodoli izrÄdÄs vÄjÄki, nemazina pÄrsteigumu, jo daudz kodolu un SMT/Hyperthreading ievÄrojami samazina veiktspÄju, ja mums ir laika ierobežojums, ko mÄs jÄbeidz visam pipeline.
Avots: habr.com
