Kami berbicara tentang teknik di bagian
pertama artikel, dalam hal ini kami menguji HTTPS, tetapi dalam skenario yang lebih realistis. Untuk pengujian, sertifikat Let's Encrypt diterima, kompresi Brotli oleh 11 diaktifkan.
Kali ini kami akan mencoba mereproduksi skenario penyebaran server di VDS atau sebagai mesin virtual di host dengan prosesor khas. Untuk melakukan ini, atur batas ke:
- 25% - Yang dalam hal frekuensi ~ 1350MHz
- 35% -1890MHz
- 41% - 2214MHz
- 65% - 3510MHz
Jumlah koneksi satu kali menurun dari 500 menjadi 1, 3, 5, 7, dan 9,
Hasil:
Penundaan:
TTFB secara khusus dibuat sebagai pengujian terpisah, karena HTTPD Tools membuat pengguna baru untuk setiap permintaan individu. Tes ini masih cukup terpisah dari kenyataan, karena pengguna tetap mengklik beberapa halaman, dan pada kenyataannya TTFP akan memainkan peran utama.
Permintaan pertama, umumnya permintaan pertama, setelah awal pertama dari mesin virtual, proses IIS rata-rata 120 ms.
Semua permintaan berikutnya menunjukkan TTFP 1,5 ms. Apache dan Nginx tertinggal. Secara pribadi, penulis menganggap tes ini paling mengungkapkan dan akan memilih pemenang hanya di atasnya.
Hasilnya tidak mengejutkan, karena cache IIS sudah mengkompresi konten statis dan tidak mencubitnya setiap kali diakses.
Waktu dihabiskan untuk satu klien
Untuk mengevaluasi kinerja, tes dengan 1 koneksi satu kali sudah cukup.
Misalnya, IIS menyelesaikan pengujian dengan panjang 5.000 pengguna dalam 40 detik, yaitu 123 permintaan per detik.
Grafik di bawah ini menunjukkan waktu hingga transfer konten situs lengkap. Ini adalah persentase permintaan yang diselesaikan pada waktu tertentu. Dalam kasus kami, 80% dari semua permintaan diproses dalam 8ms pada IIS dan 4,5ms pada Apache dan Nginx, dan 98% dari semua permintaan pada Apache dan Nginx dieksekusi dalam interval 8 milidetik.
Waktu yang dibutuhkan untuk 5000 permintaan untuk diproses:
Waktu yang dibutuhkan untuk 5000 permintaan untuk diproses:
Jika Anda memiliki mesin virtual dengan CPU 3,5 GHz dan 8 core, maka pilih yang Anda inginkan. Semua server web sangat mirip dalam tes ini. Kami akan berbicara tentang server web mana yang harus dipilih untuk setiap host di bawah ini.
Ketika datang ke situasi yang sedikit lebih nyata, semua server web bertatap muka.
Throughput:
Jadwal keterlambatan jumlah koneksi simultan. Lebih halus dan lebih rendah lebih baik. 2% terakhir dikeluarkan dari grafik karena akan membuatnya tidak dapat dibaca.
Sekarang pertimbangkan opsi di mana server dihosting di hosting bersama. Ambil 4 core di 2.2 GHz dan satu core di 1.8 GHz.
Bagaimana skala
Jika Anda pernah melihat bagaimana karakteristik I - V dari trioda elektro-vakum, pentoda, dll., Grafik ini akan familier bagi Anda. Itulah yang kami coba tangkap - kenyang. Batasnya adalah, ketika Anda tidak membuang berapa banyak inti, pertumbuhan produktivitas tidak akan terlihat.
Sebelumnya, seluruh tantangan adalah untuk memproses 98% permintaan dengan penundaan paling sedikit pada semua permintaan, untuk menjaga kurva semaksimal mungkin. Sekarang, menggunakan konstruksi kurva lain, kami menemukan titik operasi optimal untuk masing-masing server.
Untuk melakukan ini, ambil metrik Requests per second (RPR). Frekuensi horisontal, vertikal - jumlah permintaan yang diproses per detik, garis - jumlah inti.
Sebuah korelasi ditunjukkan dari seberapa baik Nginx menangani permintaan satu per satu. 8 core dalam pengujian tersebut menunjukkan diri mereka lebih baik.
Grafik ini dengan jelas menunjukkan seberapa jauh lebih baik (tidak banyak) Nginx berjalan pada satu inti. Jika Anda memiliki Nginx, Anda harus mempertimbangkan mengurangi jumlah core menjadi satu jika Anda hanya meng-host statika.
IIS, meskipun memiliki TTFB terendah menurut DevTools di Chrome, berhasil kehilangan Nginx dan Apache dalam pertarungan serius melawan stress test dari Apache Foundation.
Seluruh kelengkungan grafik direproduksi dengan kereta api.
Semacam kesimpulan:
Ya, Apache bekerja lebih buruk pada kernel 1 dan 8, dan pada 4 itu bekerja sedikit lebih baik.
Ya, Nginx pada 8 core menangani permintaan yang lebih baik satu demi satu, pada core 1 dan 4, dan bekerja lebih buruk ketika ada banyak koneksi.
Ya, IIS lebih suka 4 core untuk beban multi-threaded dan lebih suka 8 core untuk single-threaded. Pada akhirnya, IIS sedikit lebih cepat dari pada semua 8 core di bawah beban tinggi, meskipun semua server flush.
Ini bukan kesalahan pengukuran, kesalahan di sini tidak lebih dari + -1ms. dalam penundaan dan tidak lebih dari + - 2-3 permintaan per detik untuk RPR.
Hasilnya, ketika 8 core lebih buruk, sama sekali tidak mengejutkan, banyak core dan SMT / Hyperthreading sangat menurunkan kinerja jika kita memiliki kerangka waktu di mana kita harus menyelesaikan seluruh pipa.
Kami menawarkan tarif UltraDSite
Windows VDS yang diperbarui untuk 99 rubel dengan Windows Server 2019 Core yang diinstal.
