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
