Teknikari buruz hitz egin dugu artikuluan, honetan HTTPS probatzen dugu, baina eszenatoki errealagoetan. Proba egiteko, Let's Encrypt ziurtagiria lortu zen, Brotli konpresioa gaitu zen 11n.
Oraingoan zerbitzari bat VDS batean edo prozesadore estandar batekin ostalari batean makina birtual gisa hedatzearen eszenatokia erreproduzitzen saiatuko gara. Horretarako, muga bat ezarri zen:
- 25% - ~ 1350 MHz-ko maiztasunaren baliokidea dena
- %35 -1890MHz
- % 41 - 2214 MHz
- % 65 - 3510 MHz
Behin-behineko konexioen kopurua 500etik 1, 3, 5, 7 eta 9ra murriztu da,
Emaitzak:
Atzerapenak:
TTFB proba bereizi gisa sartu zen bereziki, HTTPD Tresnak erabiltzaile berri bat sortzen duelako eskaera bakoitzerako. Proba hau errealitatetik nahiko aldenduta dago oraindik, erabiltzaileak orrialde pare bat klik egingo duelako, eta errealitatean TTFPk izango du protagonismoa.
Lehenengoak, oro har, IIS makina birtuala abiarazi ondoren lehenengo eskaerak 120 ms behar ditu batez beste.
Ondorengo eskaera guztiek 1.5 ms-ko TTFP erakusten dute. Apache eta Nginx atzean geratzen ari dira zentzu honetan. Pertsonalki, egileak proba hau adierazgarriena dela uste du eta horren arabera bakarrik aukeratuko luke irabazlea.
Emaitza ez da harritzekoa, IIS-ek dagoeneko konprimitutako eduki estatikoa gordetzen duelako eta ez duelako konprimitzen sartzen den bakoitzean.
Bezero bakoitzeko emandako denbora
Errendimendua ebaluatzeko, nahikoa da konexio bakar batekin proba bat egitea.
Esaterako, IISek 5000 erabiltzaileren proba bat burutu zuen 40 segundotan, hau da, 123 eskaera segundoko.
Beheko grafikoek guneko edukia guztiz transferitu arte dagoen denbora erakusten dute. Denbora jakin batean betetako eskaeren proportzioa da. Gure kasuan, eskaera guztien % 80 IIS-en 8 ms-tan eta Apache eta Nginx-en 4.5 ms-tan prozesatu dira, eta Apache eta Nginx-en eskaera guztien % 8 98 milisegundo arteko tartean bete dira.
5000 eskaera prozesatu ziren denbora:
5000 eskaera prozesatu ziren denbora:
3.5 GHz-ko CPU eta 8 nukleo dituen makina birtual bat baduzu, aukeratu nahi duzuna. Web zerbitzari guztiak oso antzekoak dira proba honetan. Ostalari bakoitzerako zein web zerbitzari aukeratuko den hitz egingo dugu jarraian.
Egoera apur bat errealistagoa denean, web zerbitzari guztiak buru-belarri joaten dira.
throughput:
Atzerapenen grafikoa aldibereko konexio kopuruaren aldean. Leunagoa eta baxuagoa hobea da. Azken %2a zerrendetatik kendu zuten, irakurgaitz bihurtuko liratekeelako.
Orain azter dezagun zerbitzaria ostalaritza birtualean dagoen aukera. Har ditzagun 4 nukleo 2.2 GHz eta nukleo bat 1.8 GHz.
Nola eskalatu
Inoiz ikusi baduzu hutseko triodoen, pentodoen eta abarren korronte-tentsioaren ezaugarriak nolakoak diren, grafiko hauek ezagunak izango zaizkizu. Hau da harrapatzen saiatzen ari garena: saturazioa. Muga da zenbat nukleo botatzen dituzunean, errendimenduaren igoera nabaria izango ez denean.
Aurretik, erronka osoa eskaera guztien %98 latentzia txikienarekin prozesatzea zen, kurba ahalik eta lauena mantenduz. Orain, beste kurba bat eraikiz, zerbitzari bakoitzaren funtzionamendu-puntu optimoa aurkituko dugu.
Horretarako, har dezagun segundoko Eskaerak (RPR) adierazlea. Horizontala maiztasuna da, bertikala segundoko prozesatutako eskaera kopurua, lerroak nukleo kopurua.
Nginx-ek eskaerak bata bestearen atzetik nola prozesatzen dituenaren korrelazioa erakusten du. 8 nukleoek hobeto funtzionatzen dute proba honetan.
Grafiko honek argi erakusten du zenbat hobeto (ez asko) Nginx-ek nukleo bakarrean funtzionatzen duen. Nginx baduzu, nukleo kopurua batera murriztea kontuan hartu beharko zenuke estatikoak soilik ostatatzen badituzu.
IISek, DevTools-en Chrome-n TTFB baxuena duen arren, Nginx eta Apacheren aurka galtzea lortzen du Apache Fundazioaren estres-testarekin borroka larrian.
Grafikoen kurbadura guztia burdinez erreproduzitzen da.
Nolabaiteko ondorioa:
Bai, Apache-k okerrago funtzionatzen du 1 eta 8 nukleoetan, baina apur bat hobeto funtzionatzen du 4.
Bai, Nginx-ek 8 nukleoetan hobeto prozesatzen ditu eskaerak bata bestearen atzetik, 1 eta 4 nukleoetan, eta okerrago funtzionatzen du konexio asko daudenean.
Bai, IISek 4 nukleo nahiago ditu hari anitzeko lan-kargak egiteko eta 8 nukleo nahiago ditu hari bakarreko lan-kargak egiteko. Azken finean, IIS beste guztiak baino apur bat azkarragoa zen 8 nukleoetan karga handian, nahiz eta zerbitzari guztiak parean egon.
Hau ez da neurketa-errore bat, hemen errorea ez da +-1 ms baino gehiago. atzerapenetan eta gehienez +- 2-3 eskaera segundoko RPRrako.
8 nukleoen okerragoa den emaitzak ez dira batere harrigarriak, nukleo askok eta SMT/Hyperthreading-ek errendimendua asko degradatzen dute kanalizazio osoa osatu behar dugun denbora-tarte bat badugu.
Iturria: www.habr.com