Rreth metodikës ne treguam në të artikullit, në këtë testojmë HTTPS, por në skenar më realistik. Për testimin u mor një certifikatë Let’s Encrypt, u aktivizua kompressimi Brotli në 11.
Këtë herë do të përpiqemi të riprodhojmë skenarin e vendosjes së serverit në VDS ose si një makinë virtuale në një host me një procesor standard. Për këtë vendosëm limitin në:
- 25% — Çfarë në rregullim të frekuencës ~ 1350MHz
- 35% - 1890MHz
- 41% — 2214MHz
- 65% — 3510MHz
Numri i lidhjeve të njëkohshme u reduktua nga 500 në 1, 3, 5, 7 dhe 9,
Rezultatet:
Vonesa:
TTFB u nxor në një test të veçantë, sepse HTTPD Tools për çdo kërkesë të veçantë krijon për një përdorues të ri. Ky test ende është mjaft i shkëputur nga realiteti, sepse përdoruesi do të klikojë disa faqe, dhe në realitet, rolin kryesor do ta ketë TTFP.
Kërkesa e parë, gjithashtu kërkesa e parë pas nisjes së parë të makinës virtuale IIS, në mesatare e përfundon brenda 120 ms.
Të gjitha kërkesat e mëpasshme tregojnë TTFP në 1.5 ms. Apache dhe Nginx janë më të ngadalshëm në këtë aspekt. Personalish autori e konsideron këtë test si më indikativ dhe do të zgjidhte fituesin vetëm mbi këtë bazë.
Rezultati nuk është befasues, pasi IIS ruan përmbajtjen statike të kompresuar dhe nuk e kompreson përsëri çdo herë që i kërkohet.
Koha e shpenzuar për një klient
Për të vlerësuar performancën, testi me 1 lidhje të njëkohshme është mjaftueshëm.
Për shembull, IIS e përfundoi testimin e gjatë me 5000 përdorues në 40 sekonda, që është 123 kërkesa në sekondë.
Në grafikët më poshtë është paraqitur koha deri në transferimin e plotë të përmbajtjes së faqes. Kjo është pjesa e kërkesave të kryera brenda një kohë të caktuar. Në rastin tonë, 80% e të gjitha kërkesave u përpunuan brenda 8ms në IIS dhe 4.5ms në Apache dhe Nginx, ndërsa intervali deri në 8 milisekonda u përfundua nga 98% e të gjitha kërkesave në Apache dhe Nginx.
Koha për të përpunuar 5000 kërkesa:
Koha për të përpunuar 5000 kërkesa:
Nëse keni një makinë virtuale me 3.5GHz CPU dhe 8 bërthama, atëherë zgjidhni atë që dëshironi. Të gjitha serverat web janë shumë të ngjashëm në këtë testim. Nëse bisedojmë për se cilin server web të zgjidhni për çdo host, do të flasim më poshtë.
Kur flitet për një situatë pak më reale, të gjithë serverat web janë nën presion.
Kapaciteti:
Grafiku i vonesave në varësi të numrit të lidhjeve njëkohëshe. Më i rregullt dhe më i ulët – më mirë. 2% e fundit u përjashtuan nga grafiku sepse do ta bënin atë të palëvizshëm.
Tani le të shqyrtojmë variantin ku serveri vendoset në hosting virtual. Të marrim 4 bërthama me 2.2 GHz dhe një bërthamë me 1.8 GHz.
Si shkallëzohen
Nëse keni parë ndonjëherë se si duken karakteristikat e triodëve elektrovakuum, pentodëve dhe të tjerë, këto grafika do t'ju duken të njohura. Ajo që po përpiqemi të kapim – ngopja. Kufiri, kur sa më shumë bërthama të hedhim, rritja e performancës nuk do të jetë e dukshme.
Më parë, sfida e gjithë kësaj ishte të përpunoheshin 98% e kërkesave duke pasur vonesën më të vogël për të gjitha kërkesat, si mundësisht e rregullt të mbahej kurba. Tani, duke ndihmuar në ndërtimin e një kurbe tjetër, do të gjejmë pikën optimale të punës për secilin nga serverat.
Për këtë do të marrim treguesin Requests per second (RPR). Në horizont është frekuenca, në vertikal – numri i kërkesave të përpunuara për sekondë, linjat – numri i bërthamave.
Tregohet korrelacioni sa mirë Nginx përpunon kërkesat një pas një. 8 bërthamat në këtë testim tregojnë rezultate më të mira.
Në këtë grafik dallohet qartë se sa më mirë (jo shumë) punon Nginx në një bërthamë. Nëse keni Nginx, ia vlen të mendoni për uljen e numrit të bërthamave deri në një, nëse hostoni vetëm statik.
IIS, edhe pse ka TTFB më të ulët sipas DevTools në Chrome, arrin të humbasë ndaj Nginx dhe Apache në një garë serioze me testin e stresit nga Fondacioni Apache.
E gjithë lakorja e grafikëve përfaqësohet saktësisht.
Një lloj përfundimi:
Po, Apache funksionon me siguri më keq në 1 dhe 8 bërthama, ndërsa në 4 punon pak më mirë.
Po, Nginx në 8 bërthama përpunon më mirë kërkesat një pas një, në 1 dhe 4 bërthama punon më keq kur ka shumë lidhje.
Po, IIS preferon 4 bërthama për ngarkesën shumëpërdoruese dhe preferon 8 bërthama për ngarkesën njëpërdoruese. Në fund, IIS doli pak më i shpejtë se të gjithë në 8 bërthama nën ngarkesë të lartë, megjithëse të gjithë serverat ishin në nivel.
Kjo nuk është një gabim matës, gabimi këtu është jo më shumë se +-1ms. në vonesa dhe jo më shumë se +- 2-3 kërkesa për sekondë për RPR.
Rezultatet, kur 8 bërthama tregojnë rezultate më të ulta, nuk janë aspak befasuese, shumë bërthama dhe SMT/Hyperthreading e përkeqësojnë ndjeshëm performancën, nëse kemi afate kohore brenda të cilave duhet të përfundojmë tërë pipeline-in.
Burimi: habr.com
