Kita ngomong babagan teknik ing artikel, ing siji iki kita nyoba HTTPS, nanging ing skenario luwih nyata. Kanggo nguji, sertifikat Ayo Encrypt dijupuk, kompresi Brotli diaktifake ing 11.
Wektu iki kita bakal nyoba kanggo ngasilake skenario nyebarake server ing VDS utawa minangka mesin virtual ing host kanthi prosesor standar. Kanggo tujuan iki, watesan disetel ing:
- 25% - Sing padha karo frekuensi ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Jumlah sambungan siji-wektu wis suda saka 500 dadi 1, 3, 5, 7 lan 9,
Asile:
telat:
TTFB khusus kalebu minangka tes sing kapisah, amarga Alat HTTPD nggawe pangguna anyar kanggo saben panyuwunan individu. Tes iki isih cukup adoh saka kasunyatan, amarga pangguna isih bakal ngeklik sawetara kaca, lan nyatane TTFP bakal dadi peran utama.
Pisanan, umume panjalukan pisanan sawise wiwitan mesin virtual IIS njupuk rata-rata 120 ms.
Kabeh panjalukan sakteruse nuduhake TTFP 1.5 ms. Apache lan Nginx ketinggalan ing babagan iki. Secara pribadi, penulis nganggep tes iki paling jelas lan bakal milih pemenang mung adhedhasar.
Asil kasebut ora nggumunake amarga cache IIS wis ngompres konten statis lan ora ngompres saben diakses.
Wektu sing ditindakake saben klien
Kanggo ngevaluasi kinerja, tes kanthi 1 sambungan tunggal cukup.
Contone, IIS ngrampungake tes 5000 pangguna sajrone 40 detik, yaiku 123 panjaluk per detik.
Grafik ing ngisor iki nuduhake wektu nganti isi situs rampung ditransfer. Iki minangka proporsi panjalukan sing rampung ing wektu tartamtu. Ing kasus kita, 80% kabeh panjalukan diproses ing 8ms ing IIS lan ing 4.5ms ing Apache lan Nginx, lan 8% saka kabeh panjalukan ing Apache lan Nginx rampung ing interval nganti 98 milidetik.
Wektu nalika 5000 panjalukan diproses:
Wektu nalika 5000 panjalukan diproses:
Yen sampeyan duwe mesin virtual kanthi CPU 3.5GHz lan 8 intine, banjur pilih sing dikarepake. Kabeh server web meh padha ing tes iki. Kita bakal ngomong babagan server web sing kudu dipilih kanggo saben host ing ngisor iki.
Nalika nerangake kahanan sing rada realistis, kabeh server web maju.
Hasil:
Grafik telat versus nomer sambungan simultan. Luwih alus lan luwih murah. 2% pungkasan dibusak saka grafik amarga bakal ora bisa diwaca.
Saiki ayo nimbang pilihan ing ngendi server di-host ing hosting virtual. Ayo njupuk 4 intine ing 2.2 GHz lan siji inti ing 1.8 GHz.
Carane skala
Yen sampeyan wis tau weruh kaya apa karakteristik voltase saiki triode vakum, pentodes, lan liya-liyane, grafik iki bakal sampeyan kenal. Iki sing kita nyoba nyekel - jenuh. Watesan nalika ora ketompo carane akeh intine sampeyan mbuwang, mundhak kinerja ora bakal katon.
Sadurunge, kabeh tantangan yaiku ngolah 98% panjalukan kanthi latensi paling murah kanggo kabeh panjaluk, supaya kurva tetep rata. Saiki, kanthi mbangun kurva liyane, kita bakal nemokake titik operasi sing optimal kanggo saben server.
Kanggo nindakake iki, ayo njupuk indikator Requests per second (RPR). Horizontal minangka frekuensi, vertikal minangka jumlah panjaluk sing diproses saben detik, garis minangka jumlah inti.
Nuduhake korΓ©lasi babagan carane Nginx ngolah panjaluk siji-sijine. 8 intine nindakake luwih apik ing tes iki.
Grafik iki kanthi jelas nuduhake carane Nginx luwih apik (ora akeh) ing inti siji. Yen sampeyan duwe Nginx, sampeyan kudu nimbang nyuda jumlah inti dadi siji yen sampeyan mung hosting sing statis.
IIS, sanajan nduweni TTFB paling murah miturut DevTools ing Chrome, bisa kalah karo Nginx lan Apache sajrone perang serius karo tes stres saka Apache Foundation.
Kabeh lengkungan grafik kasebut digawe nganggo wesi.
Sawetara jinis kesimpulan:
Ya, Apache dianggo luwih elek ing 1 lan 8 intine, nanging luwih apik ing 4.
Ya, Nginx ing 8 inti proses njaluk luwih apik siji-sijine, ing 1 lan 4 intine, lan kerjane luwih elek nalika ana akeh sambungan.
Ya, IIS luwih milih 4 intine kanggo beban kerja multi-Utas lan luwih milih 8 intine kanggo beban kerja sing nganggo benang tunggal. Wekasanipun, IIS rada luwih cepet tinimbang wong liya ing 8 intine kanthi beban dhuwur, sanajan kabeh server padha.
Iki dudu kesalahan pangukuran, kesalahan ing kene ora luwih saka +-1ms. ing telat lan ora luwih saka +- 2-3 panjalukan per detik kanggo RPR.
Asil ing ngendi 8 intine nindakake luwih elek ora nggumunake, akeh intine lan SMT / Hyperthreading ngrusak kinerja yen kita duwe pigura wektu sing kudu ngrampungake kabeh pipa.
Source: www.habr.com