Ne folëm për teknikën në artikull, në këtë ne testojmë HTTPS, por në skenarë më realistë. Për testim, ne morëm një certifikatë Let's Encrypt dhe aktivizuam kompresimin e Brotli në 11.
Këtë herë do të përpiqemi të riprodhojmë skenarin e vendosjes së një serveri në një VDS ose si një makinë virtuale në një host me një procesor standard. Për këtë qëllim, u vendos një kufi në:
- 25% - e cila është e barabartë me një frekuencë prej ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Numri i lidhjeve një herë është ulur nga 500 në 1, 3, 5, 7 dhe 9,
Rezultatet:
Vonesat:
TTFB u përfshi në mënyrë specifike si një test i veçantë, sepse Mjetet HTTPD krijojnë një përdorues të ri për çdo kërkesë individuale. Ky test është ende mjaft i shkëputur nga realiteti, sepse përdoruesi do të klikojë ende disa faqe, dhe në realitet TTFP do të luajë rolin kryesor.
Kërkesa e parë, përgjithësisht e parë pas fillimit të parë të makinës virtuale IIS zgjat mesatarisht 120 ms.
Të gjitha kërkesat pasuese tregojnë një TTFP prej 1.5 ms. Apache dhe Nginx kanë mbetur prapa në këtë drejtim. Personalisht, autori e konsideron këtë test si më zbuluesin dhe do të zgjidhte fituesin vetëm në bazë të tij.
Rezultati nuk është befasues pasi IIS ruan përmbajtjen statike tashmë të ngjeshur dhe nuk e kompreson atë sa herë që aksesohet.
Koha e shpenzuar për klient
Për të vlerësuar performancën, mjafton një test me 1 lidhje të vetme.
Për shembull, IIS përfundoi një test të 5000 përdoruesve në 40 sekonda, që është 123 kërkesa për sekondë.
Grafikët e mëposhtëm tregojnë kohën derisa përmbajtja e faqes të transferohet plotësisht. Ky është përqindja e kërkesave të përfunduara në një kohë të caktuar. Në rastin tonë, 80% e të gjitha kërkesave u përpunuan në 8ms në IIS dhe në 4.5ms në Apache dhe Nginx, dhe 8% e të gjitha kërkesave në Apache dhe Nginx u përfunduan brenda një intervali deri në 98 milisekonda.
Koha gjatë së cilës janë përpunuar 5000 kërkesa:
Koha gjatë së cilës janë përpunuar 5000 kërkesa:
Nëse keni një makinë virtuale me një CPU 3.5 GHz dhe 8 bërthama, atëherë zgjidhni atë që dëshironi. Të gjithë serverët në internet janë shumë të ngjashëm në këtë testim. Ne do të flasim për cilin server në internet të zgjedhim për secilin host më poshtë.
Kur bëhet fjalë për një situatë pak më realiste, të gjithë serverët në internet shkojnë kokë më kokë.
Xhiroja:
Grafiku i vonesave kundrejt numrit të lidhjeve të njëkohshme. Më e qetë dhe më e ulët është më mirë. 2% e fundit u hoqën nga grafikët sepse do t'i bënin ato të palexueshme.
Tani le të shqyrtojmë opsionin ku serveri është pritur në pritje virtuale. Le të marrim 4 bërthama në 2.2 GHz dhe një bërthamë në 1.8 GHz.
Si të shkallëzohet
Nëse keni parë ndonjëherë se si duken karakteristikat e tensionit aktual të triodave vakum, pentodave, etj., këta grafikë do të jenë të njohur për ju. Kjo është ajo që ne po përpiqemi të kapim - ngopja. Kufiri është kur pavarësisht sa bërthama hidhni, rritja e performancës nuk do të jetë e dukshme.
Më parë, e gjithë sfida ishte përpunimi i 98% të kërkesave me vonesën më të ulët për të gjitha kërkesat, duke e mbajtur kurbën sa më të sheshtë. Tani, duke ndërtuar një kurbë tjetër, do të gjejmë pikën optimale të funksionimit për secilin nga serverët.
Për ta bërë këtë, le të marrim treguesin Kërkesat për sekondë (RPR). Horizontale është frekuenca, vertikale është numri i kërkesave të përpunuara për sekondë, linjat janë numri i bërthamave.
Tregon një lidhje se sa mirë i përpunon Nginx kërkesat njëra pas tjetrës. 8 bërthama performojnë më mirë në këtë test.
Ky grafik tregon qartë se sa më mirë (jo shumë) funksionon Nginx në një bërthamë të vetme. Nëse keni Nginx, duhet të konsideroni zvogëlimin e numrit të bërthamave në një nëse jeni duke pritur vetëm ato statike.
IIS, megjithëse ka TTFB-në më të ulët sipas DevTools në Chrome, arrin të humbasë ndaj Nginx dhe Apache në një luftë serioze me testin e stresit nga Apache Foundation.
E gjithë lakimi i grafikëve është riprodhuar i veshur me hekur.
Një lloj përfundimi:
Po, Apache funksionon më keq në 1 dhe 8 bërthama, por funksionon pak më mirë në 4.
Po, Nginx me 8 bërthama përpunon kërkesat më mirë njëra pas tjetrës, në 1 dhe 4 bërthama dhe funksionon më keq kur ka shumë lidhje.
Po, IIS preferon 4 bërthama për ngarkesat e punës me shumë fije dhe preferon 8 bërthama për ngarkesat e punës me një fije. Në fund të fundit, IIS ishte pak më i shpejtë se të gjithë të tjerët në 8 bërthama nën ngarkesë të lartë, megjithëse të gjithë serverët ishin të barabartë.
Ky nuk është një gabim matjeje, gabimi këtu nuk është më shumë se +-1ms. në vonesa dhe jo më shumë se +- 2-3 kërkesa në sekondë për RPR.
Rezultatet ku 8 bërthama performojnë më keq nuk janë aspak befasuese, shumë bërthama dhe SMT/Hyperthreading degradojnë shumë performancën nëse kemi një kornizë kohore në të cilën duhet të përfundojmë të gjithë tubacionin.
Burimi: www.habr.com