Ne kemi folur pĂ«r metodologjinĂ« nĂ« artikuj, nĂ« kĂ«tĂ« ne testojmĂ« HTTPS, por nĂ« skenarĂ« mĂ« realistikĂ«. PĂ«r testimin u mor njĂ« certifikatĂ« Letâs Encrypt, u pĂ«rfshinĂ« kompresimin Brotli me 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 CPU tipik. Për këtë vendosëm një kufi në:
- 25% â ĂfarĂ« pĂ«rkthehet nĂ« frekuencĂ« ~ 1350MHz
- 35% -1890MHz
- 41% â 2214MHz
- 65% â 3510MHz
Numri i lidhjeve të njëkohshme u ul nga 500 në 1, 3, 5, 7 dhe 9,
Rezultatet:
Vonesa:
TTFB është trajtuar si një test të veçantë, sepse HTTPD Tools krijon një përdorues të ri për çdo kërkesë të veçantë. Ky test është ende mjaft i shkëputur nga realiteti, sepse përdoruesi do të klikojë disa faqe, dhe në realitet rolin kryesor do ta luajë TTFP.
Kërkesa e parë, në tërësi kërkesa e parë pas nisjes së parë të makinës virtuale IIS, kalon mesatarisht për 120 ms.
Të gjitha kërkesat e tjera tregojnë TTFP në 1.5 ms. Apache dhe Nginx mbesin pas në këtë.
Rezultati nuk është befasues, pasi IIS ndihmon në memorizimin e përmbajtjes statike të kompresuar dhe nuk e kompreson atë çdo herë që i qaset.
Koha e kaluar për një klient
Për të vlerësuar performancën, testi me 1 lidhje të njëkohshme është i mjaftueshëm.
Për shembull, IIS e përfundoi testimin e 5000 përdoruesve për 40 sekonda, që do të thotë 123 kërkesa në sekondë.
Në grafiket më poshtë është treguar koha për transmetimin e plotë të përmbajtjes së faqes. Kjo është pjesa e kërkesave të realizuara në një kohë të caktuar. Në rastin tonë, 80% e të gjitha kërkesave u përpunuan për 8ms në IIS dhe 4.5ms në Apache dhe Nginx, ndërsa intervali deri në 8 milisekondë përmbushi 98% të 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 serverët web janë shumë të ngjashëm në këtë testim. Për atë se cili server web të zgjidhni për secilën host do të flasim më poshtë.
Kur flitet për një situatë pak më reale, të gjithë serverët web përballen në mënyrë të barabartë.
Kapaciteti:
Grafiku i vonesave nga numri i lidhjeve tĂ« njĂ«kohshme. Sa mĂ« tĂ« qetĂ« dhe mĂ« tĂ« ulĂ«t â aq mĂ« mirĂ«. 2% e fundit u hoqĂ«n nga grafikĂ«t sepse do tĂ« bĂ«jnĂ« ata tĂ« palexueshĂ«m.
Tani le të shqyrtojmë variantin ku serveri vendoset në hostimin virtual. Të marrim 4 bërthama me 2.2GHz dhe një bërthamë me 1.8GHz.
Si shkallëzohen
Nëse keni parë ndonjëherë si duken karakteristikat e triodeve të elektrovakuumit, pentodeve dhe të tjerëve, këto grafe do të jenë të njohura për ju. Pikërisht atë që po përpiqemi të kapim - ngopja. Kufiri, kur sa më shumë bërthama të hedhësh, rritja e produktivitetit nuk do të jetë e dukshme.
Më parë sfida ishte të përpunojmë 98% e kërkesave duke mbajtur vonesën sa më të ulët të mundshme për të gjitha kërkesat, duke mbajtur sa më të qetë kurbën. Tani me ndihmën e ndërtimit të një kurbe tjetër, do të gjejmë pikën optimale të punës për secilin nga serverët.
PĂ«r kĂ«tĂ« do tĂ« marrim treguesin KĂ«rkesa pĂ«r sekondĂ« (RPR). NĂ« horizont frekuenca, nĂ« vertikalen â numri i kĂ«rkesave tĂ« pĂ«rpunuara pĂ«r sekondĂ«, linjat â numri i bĂ«rthamave.
Tregohet korrelacioni se sa mirë e proceson Nginx kërkesat një pas një. 8 bërthama në një testim të tillë tregojnë rezultate më të mira.
Në këtë grafik është e qartë se sa më mirë (jo shumë) Nginx punon në një bërthamë. Nëse keni Nginx, duhet të mendoni për uljen e numrit të bërthamave në një, nëse keni vetëm statikë për të hostuar.
IIS, ndonëse ka TTFB më të ulët sipas DevTools në Chrome, duket se humbet ndaj Nginx dhe Apache në një garë serioze me testin e stresit nga Fondacioni Apache.
E gjithë përkatësia e grafikëve është e sigurt.
Njëfarë përfundimi:
Po, Apache punon me siguri më keq në 1 dhe 8 bërthama, ndërsa në 4 punon disi më mirë.
Po, Nginx në 8 bërthama proceson më mirë kërkesat një pas një, ndërsa në 1 dhe 4 bërthama punon më keq kur ka shumë lidhje.
Po, IIS preferon 4 bërthama për ngarkesat me shumë fije dhe preferon 8 bërthama për ngarkesat me një fije. Në fund, IIS doli disi më i shpejtë se të gjithë në 8 bërthama nën ngarkesë të lartë, megjithëse të gjithë serverët ishin në një nivel.
Këto rezultate, kur 8 bërthamat duken më keq, nuk janë aspak befasuese, sepse shumë bërthama dhe SMT/Hyperthreading ndjeshëm përkeqësojnë performancën, nëse kemi një afat kohor ku duhet të përfundojmë të gjithë pipeline-in.
Rezultatet, kur 8 bërthama shfaqin performancë më të dobët, nuk janë aspak të habitshme, 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ë gjithë pipeline-in.
Burimi: habr.com
