Kami bercakap tentang metodologi dalam artikel, dalam satu ini kami menguji HTTPS, tetapi dalam senario yang lebih realistik. Untuk ujian, kami memperoleh sijil Let's Encrypt dan mendayakan pemampatan Brotli kepada 11.
Kali ini kami akan cuba menghasilkan semula senario menggunakan pelayan pada VDS atau sebagai mesin maya pada hos dengan pemproses standard. Untuk tujuan ini, had telah ditetapkan pada:
- 25% - Yang bersamaan dengan frekuensi ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Bilangan sambungan sekali telah dikurangkan daripada 500 kepada 1, 3, 5, 7 dan 9,
Keputusan:
Kelewatan:
TTFB telah disertakan secara khusus sebagai ujian berasingan, kerana Alat HTTPD mencipta pengguna baharu untuk setiap permintaan individu. Ujian ini masih agak terpisah daripada realiti, kerana pengguna masih akan mengklik beberapa halaman, dan sebenarnya TTFP akan memainkan peranan utama.
Yang pertama, secara amnya permintaan pertama selepas permulaan pertama mesin maya IIS mengambil purata 120 ms.
Semua permintaan seterusnya menunjukkan TTFP sebanyak 1.5 ms. Apache dan Nginx ketinggalan dalam hal ini. Secara peribadi, penulis menganggap ujian ini paling mendedahkan dan akan memilih pemenang hanya berdasarkannya.
Hasilnya tidak mengejutkan kerana IIS cache telah memampatkan kandungan statik dan tidak memampatkannya setiap kali ia diakses.
Masa yang diluangkan untuk setiap pelanggan
Untuk menilai prestasi, ujian dengan 1 sambungan tunggal adalah mencukupi.
Sebagai contoh, IIS menyelesaikan ujian 5000 pengguna dalam 40 saat, iaitu 123 permintaan sesaat.
Graf di bawah menunjukkan masa sehingga kandungan tapak dipindahkan sepenuhnya. Ini ialah nisbah permintaan yang diselesaikan dalam masa tertentu. Dalam kes kami, 80% daripada semua permintaan telah diproses dalam 8ms pada IIS dan dalam 4.5ms pada Apache dan Nginx, dan 8% daripada semua permintaan pada Apache dan Nginx telah diselesaikan dalam selang masa sehingga 98 milisaat.
Masa di mana 5000 permintaan diproses:
Masa di mana 5000 permintaan diproses:
Jika anda mempunyai mesin maya dengan CPU 3.5GHz dan 8 teras, kemudian pilih perkara yang anda mahukan. Semua pelayan web sangat serupa dalam ujian ini. Kami akan bercakap tentang pelayan web yang hendak dipilih untuk setiap hos di bawah.
Apabila ia datang kepada situasi yang lebih realistik, semua pelayan web pergi ke hadapan.
Keluaran:
Graf kelewatan berbanding bilangan sambungan serentak. Lebih licin dan lebih rendah adalah lebih baik. 2% terakhir telah dialih keluar daripada carta kerana ia akan menjadikannya tidak boleh dibaca.
Sekarang mari kita pertimbangkan pilihan di mana pelayan dihoskan pada pengehosan maya. Mari kita ambil 4 teras pada 2.2 GHz dan satu teras pada 1.8 GHz.
Bagaimana untuk membuat skala
Jika anda pernah melihat ciri-ciri voltan semasa triod vakum, pentod dan sebagainya, graf ini akan anda kenali. Inilah yang kita cuba tangkap - ketepuan. Hadnya ialah apabila tidak kira berapa banyak teras yang anda lemparkan, peningkatan prestasi tidak akan ketara.
Sebelum ini, keseluruhan cabaran adalah untuk memproses 98% permintaan dengan kependaman terendah untuk semua permintaan, mengekalkan keluk serata mungkin. Sekarang, dengan membina lengkung lain, kami akan mencari titik operasi optimum untuk setiap pelayan.
Untuk melakukan ini, mari ambil penunjuk Permintaan sesaat (RPR). Mendatar ialah kekerapan, menegak ialah bilangan permintaan yang diproses sesaat, baris ialah bilangan teras.
Menunjukkan korelasi sejauh mana Nginx memproses permintaan satu demi satu. 8 teras berprestasi lebih baik dalam ujian ini.
Graf ini jelas menunjukkan betapa lebih baik (tidak banyak) Nginx berfungsi pada satu teras. Jika anda mempunyai Nginx, anda harus mempertimbangkan untuk mengurangkan bilangan teras kepada satu jika anda hanya mengehos teras statik.
IIS, walaupun ia mempunyai TTFB terendah mengikut DevTools dalam Chrome, berjaya kalah kepada kedua-dua Nginx dan Apache dalam pertarungan serius dengan ujian tekanan daripada Yayasan Apache.
Semua kelengkungan graf dihasilkan semula bersalut besi.
Beberapa jenis kesimpulan:
Ya, Apache berfungsi lebih teruk pada 1 dan 8 teras, tetapi berfungsi lebih baik sedikit pada 4.
Ya, Nginx pada 8 teras memproses permintaan yang lebih baik satu demi satu, pada 1 dan 4 teras, dan berfungsi lebih teruk apabila terdapat banyak sambungan.
Ya, IIS lebih suka 4 teras untuk beban kerja berbilang benang dan lebih suka 8 teras untuk beban kerja berbenang tunggal. Akhirnya, IIS adalah lebih pantas sedikit daripada orang lain pada 8 teras di bawah beban tinggi, walaupun semua pelayan adalah setanding.
Ini bukan ralat pengukuran, ralat di sini adalah tidak lebih daripada +-1ms. dalam kelewatan dan tidak lebih daripada +- 2-3 permintaan sesaat untuk RPR.
Keputusan di mana 8 teras berprestasi lebih teruk sama sekali tidak mengejutkan, banyak teras dan SMT/Hyperthreading sangat merendahkan prestasi jika kita mempunyai jangka masa yang mana kita perlu melengkapkan keseluruhan saluran paip.
Sumber: www.habr.com