Kami berbicara tentang teknik di artikel ini, dalam artikel ini kami menguji HTTPS, tetapi dalam skenario yang lebih realistis. Untuk pengujian, kami memperoleh sertifikat Let's Encrypt dan mengaktifkan kompresi Brotli ke 11.
Kali ini kami akan mencoba mereproduksi skenario penggelaran server pada VDS atau sebagai mesin virtual pada host dengan prosesor standar. Untuk tujuan ini, batas ditetapkan pada:
- 25% - Yang setara dengan frekuensi ~1350 MHz
- 35% -1890MHz
- 41% - 2214MHz
- 65% - 3510MHz
Jumlah koneksi satu kali telah dikurangi dari 500 menjadi 1, 3, 5, 7 dan 9,
Hasil:
Penundaan:
TTFB secara khusus disertakan sebagai pengujian terpisah, karena Alat HTTPD membuat pengguna baru untuk setiap permintaan individual. Tes ini masih jauh dari kenyataan, karena pengguna masih akan mengklik beberapa halaman, dan pada kenyataannya TTFP akan memainkan peran utama.
Yang pertama, biasanya permintaan pertama setelah permulaan pertama mesin virtual IIS memakan waktu rata-rata 120 ms.
Semua permintaan berikutnya menunjukkan TTFP 1.5 ms. Apache dan Nginx tertinggal dalam hal ini. Secara pribadi, penulis menganggap tes ini paling terbuka dan akan memilih pemenang hanya berdasarkan tes ini.
Hasilnya tidak mengejutkan karena cache IIS sudah mengompresi konten statis dan tidak mengompresnya setiap kali diakses.
Waktu yang dihabiskan per klien
Untuk mengevaluasi kinerja, pengujian dengan 1 koneksi tunggal sudah cukup.
Misalnya, IIS menyelesaikan pengujian terhadap 5000 pengguna dalam 40 detik, yaitu 123 permintaan per detik.
Grafik di bawah menunjukkan waktu hingga konten situs ditransfer sepenuhnya. Ini adalah proporsi permintaan yang diselesaikan dalam waktu tertentu. Dalam kasus kami, 80% dari semua permintaan diproses dalam 8 md di IIS dan 4.5 md di Apache dan Nginx, dan 8% dari semua permintaan di Apache dan Nginx diselesaikan dalam interval hingga 98 milidetik.
Waktu selama 5000 permintaan diproses:
Waktu selama 5000 permintaan diproses:
Jika Anda memiliki mesin virtual dengan CPU 3.5GHz dan 8 core, pilih yang Anda inginkan. Semua server web sangat mirip dalam pengujian ini. Kami akan membicarakan server web mana yang harus dipilih untuk setiap host di bawah ini.
Dalam situasi yang sedikit lebih realistis, semua server web saling berhadapan.
Throughput:
Grafik penundaan versus jumlah koneksi simultan. Lebih halus dan lebih rendah lebih baik. 2% terakhir telah dihapus dari grafik karena akan membuatnya tidak dapat dibaca.
Sekarang mari kita pertimbangkan opsi di mana server dihosting di hosting virtual. Mari kita ambil 4 core pada 2.2 GHz dan satu core pada 1.8 GHz.
Bagaimana menskalakannya
Jika Anda pernah melihat seperti apa karakteristik tegangan arus dari trioda vakum, pentoda, dan sebagainya, grafik berikut pasti sudah tidak asing lagi bagi Anda. Inilah yang kami coba tangkap - saturasi. Batasannya adalah berapa pun jumlah core yang Anda lempar, peningkatan performa tidak akan terlihat.
Sebelumnya, seluruh tantangannya adalah memproses 98% permintaan dengan latensi terendah dari semua permintaan, menjaga kurvanya sedatar mungkin. Sekarang, dengan membuat kurva lain, kita akan menemukan titik operasi optimal untuk masing-masing server.
Untuk melakukan hal ini, mari kita ambil indikator Permintaan per detik (RPR). Horisontal adalah frekuensinya, vertikal adalah jumlah permintaan yang diproses per detik, garis adalah jumlah inti.
Menunjukkan korelasi seberapa baik Nginx memproses permintaan satu demi satu. 8 core berkinerja lebih baik dalam pengujian ini.
Grafik ini dengan jelas menunjukkan seberapa baik (tidak banyak) Nginx bekerja pada satu inti. Jika Anda memiliki Nginx, Anda harus mempertimbangkan untuk mengurangi jumlah inti menjadi satu jika Anda hanya menghosting inti statis.
IIS, meskipun memiliki TTFB terendah menurut DevTools di Chrome, berhasil kalah dari Nginx dan Apache dalam pertarungan serius dengan stress test dari Apache Foundation.
Semua kelengkungan grafik direproduksi dengan lapisan besi.
Beberapa jenis kesimpulan:
Ya, Apache bekerja lebih buruk pada core 1 dan 8, tetapi bekerja sedikit lebih baik pada core 4.
Ya, Nginx pada 8 core memproses permintaan lebih baik satu demi satu, pada 1 dan 4 core, dan bekerja lebih buruk ketika ada banyak koneksi.
Ya, IIS lebih memilih 4 core untuk beban kerja multi-thread dan lebih memilih 8 core untuk beban kerja single-thread. Pada akhirnya, IIS sedikit lebih cepat daripada yang lainnya dengan 8 core di bawah beban tinggi, meskipun semua server setara.
Ini bukan kesalahan pengukuran, kesalahan di sini tidak lebih dari +-1ms. dalam penundaan dan tidak lebih dari +- 2-3 permintaan per detik untuk RPR.
Hasil dimana kinerja 8 core lebih buruk sama sekali tidak mengejutkan, banyak core dan SMT/Hyperthreading sangat menurunkan kinerja jika kita memiliki jangka waktu di mana kita harus menyelesaikan keseluruhan pipeline.
Sumber: www.habr.com