Urang ngobrolkeun ngeunaan metodologi dina Dina tulisan ieu, urang nguji HTTPS, tapi dina skenario anu langkung realistis. Pikeun nguji, urang kéngingkeun sertipikat Let's Encrypt, kalayan komprési Brotli diaktipkeun dina vérsi 11.
Ayeuna, urang bakal nyobian ngulang skenario palaksanaan server dina VDS atanapi salaku mesin virtual dina host anu nganggo prosesor standar. Pikeun ngalakukeun ieu, urang nyetel wates ka:
- 25% - Anu, nalika dirobah jadi frékuénsi ~ 1350 MHz
- 35% -1890 MHz
- 41% — 2214 MHz
- 65% — 3510 MHz
Jumlah sambungan simultan parantos dikirangan tina 500 janten 1, 3, 5, 7 sareng 9,
Hasil:
Reureuh:
TTFB dipilih sacara khusus salaku tés anu misah sabab HTTPD Tools nyiptakeun pangguna énggal pikeun unggal pamundut individu. Tés ieu masih teu réalistis, sabab pangguna masih bakal ngaklik sababaraha halaman, sareng kanyataanna, TTFP bakal maénkeun peran utama.
Anu kahiji, kanyataanna pamundut anu paling munggaran saatos mesin virtual IIS diaktipkeun munggaran diprosés rata-rata dina 120 ms.
Sadaya pamundut salajengna nunjukkeun TTFP 1.5 ms. Apache sareng Nginx tinggaleun dina hal ieu. Panulis sacara pribadi nganggap tés ieu anu paling ngungkabkeun sareng bakal milih juara dumasar kana éta.
Hasilna teu anéh, sabab IIS nyimpen eusi statis anu parantos dikomprés dina cache sareng henteu ngompres deui unggal waktos diakses.
Waktos anu dianggo per klien
Pikeun meunteun kinerja, tés nganggo hiji sambungan sakaligus cekap.
Contona, IIS ngalengkepan tés 5000 pangguna dina 40 detik, nyaéta 123 pamundut per detik.
Grafik di handap ieu nunjukkeun waktos dugi ka eusi situs ditransfer sapinuhna. Ieu ngagambarkeun persentase pamundut anu réngsé dina waktos anu ditangtukeun. Dina kasus kami, 80% tina sadaya pamundut diprosés dina 8ms dina IIS sareng dina 4.5ms dina Apache sareng Nginx, sedengkeun 98% tina sadaya pamundut dina Apache sareng Nginx réngsé dina 8 milidetik.
Waktu anu diperyogikeun pikeun ngolah 5000 pamundut:
Waktu anu diperyogikeun pikeun ngolah 5000 pamundut:
Upami anjeun gaduh mesin virtual nganggo CPU 3.5 GHz sareng 8 inti, pilih naon waé anu anjeun pikaresep. Sadaya server wéb ngalaksanakeun tugas anu sami dina tés ieu. Urang bakal ngabahas server wéb mana anu kedah dipilih pikeun unggal host di handap.
Lamun datang ka kaayaan anu rada realistis, sadaya server wéb adu hareupan.
Hasilna:
Grafik latensi dumasar kana jumlah sambungan anu babarengan. Langkung datar sareng langkung handap langkung saé. 2% terakhir dileungitkeun tina grafik sabab bakal ngajantenkeun teu tiasa dibaca.
Ayeuna hayu urang tempo skénario dimana server di-host dina shared hosting. Hayu urang anggap opat inti 2.2 GHz sareng hiji inti 1.8 GHz.
Kumaha skala na?
Upami anjeun kantos ningali karakteristik I-V tina trioda tabung vakum, pentoda, sareng anu sanésna, grafik ieu pasti wawuh. Ieu anu urang badé rekam—saturasi. Wates dimana, sabaraha waé inti anu anjeun lebetkeun, teu aya paningkatan kinerja anu katingali.
Saméméhna, sakabéh tantanganana nyaéta ngolah 98% pamundut kalayan latency panghandapna di sakumna pamundut, ngajaga kurva sadatar mungkin. Ayeuna, ku cara ngawangun kurva anu sanés, urang bakal mendakan titik operasi anu optimal pikeun unggal server.
Pikeun ngalakukeun ieu, hayu urang nganggo métrik Pamundut per detik (RPR). Sumbu horizontal ngagambarkeun frékuénsi, sumbu vertikal ngagambarkeun jumlah pamundut anu diprosés per detik, sareng garis ngagambarkeun jumlah inti.
Aya korélasi antara kumaha alusna prosés Nginx menta hiji-hiji. Dalapan inti berkinerja langkung saé dina tés ieu.
Grafik ieu nunjukkeun sacara jelas sabaraha langkung saé (henteu jauh) kinerja Nginx dina hiji inti. Upami anjeun nganggo Nginx, anjeun panginten hoyong ngirangan jumlah inti janten hiji upami anjeun ngan ukur ngalayanan eusi statis.
Sanaos IIS gaduh TTFB panghandapna numutkeun Chrome DevTools, éta tetep éléh ku Nginx sareng Apache dina perang anu serius sareng tés setrés Apache Foundation.
Sadaya kelengkungan grafik dihasilkeun deui sacara akurat.
Hiji rupa kacindekan:
Muhun, Apache pasti jalanna langkung goréng dina inti 1 sareng 8, tapi jalanna rada langkung saé dina inti 4.
Muhun, Nginx dina prosés 8 inti nyuhunkeun hiji-hiji langkung saé tibatan dina inti 1 sareng 4, sareng kinerjana langkung goréng nalika aya seueur sambungan.
Muhun, IIS langkung milih 4 inti pikeun beban kerja multi-threaded sareng 8 inti pikeun beban kerja single-threaded. Pamustunganana, IIS rada langkung gancang tibatan sadaya server sanés dina 8 inti dina beban anu luhur, sanaos sadaya server sami-sami berkinerja saé.
Ieu sanés kasalahan pangukuran; kasalahan di dieu henteu langkung ti +/- 1 ms dina reureuh sareng henteu langkung ti +/- 2-3 pamundut per detik pikeun RPR.
Hasil dimana 8 inti berkinerja langkung goréng henteu anéh pisan, seueur inti sareng SMT/Hyperthreading nurunkeun kinerja sacara signifikan upami urang gaduh jangka waktu dimana urang kedah ngalengkepan sadaya pipeline.
sumber: www.habr.com
