Pada artikel ini kita akan mencoba melakukan rekayasa balik, bisa dikatakan. Kami akan menangani setiap server web, mengeksploitasinya dengan cara yang tidak akan pernah dieksploitasi oleh siapa pun.
Tes ini adalah pengukuran kuda berbentuk bola dalam ruang hampa, tidak lebih dari data yang diperoleh, dan sekarang kita tidak tahu apa yang harus dilakukan dengannya.
Metodologi
Sistem operasi untuk Nginx dan Apache adalah Ubuntu 18.04 LTS, untuk IIS Windows Server Core 2019. Sebelum pengujian, semua sistem operasi menerima pembaruan terkini per 04.12.2019 Desember XNUMX.
Pengujian dilakukan secara eksklusif melalui HTTP. Setiap server web menjalankan halaman yang sama, template Jekyll gratis dari Codrops. . Setiap server web menonaktifkan kompresi gzip.
Tes throughput dilakukan dengan Httpd-tools dengan argumen:
ab -n 50000 -c 500 http://192.168.76.204:80/Server dibatasi pada 10, 5, dan 1 persen inti pada 8, 4, dan satu inti. Meja pengujiannya adalah komputer dengan 9900K@5400MHz, yang berarti server yang menerima batas 10% menerima sekitar 540MHz per inti.
Pengujian TTFB dilakukan saat server pertama kali booting dan diukur menggunakan DevTools; setelah menerima hasilnya, server dimatikan dan dikembalikan ke checkpoint sebelumnya untuk menghilangkan munculnya segala jenis cache.
Penguji dan server web berada di host yang sama dan pada saklar virtual yang sama.
Untuk segera mengevaluasi subsistem disk, hasil benchmark ATTO dan CrystalDIskMark untuk mengetahui kemacetannya.
Data diambil dari mesin virtual:
Hasil:
TTFB:
TTFB rata-rata untuk IIS adalah yang terkecil, 0,5 md, dibandingkan 1,4 md untuk Apache dan 4 md untuk Nginx.
Throughput:
Pertama, mari kita lihat seberapa baik skala setiap server berdasarkan jumlah inti.
Grafik menunjukkan jumlah panggilan penguji ke server web dan latensi. Grafik menunjukkan bahwa NGINX memproses 98% dari seluruh permintaan, mengirimkan situs dalam waktu 20 md atau kurang. IIS, seperti Apache, menyelesaikan 5% terakhir dari semua panggilan masing-masing dalam 76 md dan 14 md.
Grafik menunjukkan waktu pemrosesan rata-rata untuk satu permintaan selama stress test.
Seperti yang dapat Anda lihat dari grafik, IIS mengalahkan Apache dan Nginx, sehingga melambat secara signifikan pada beban tinggi.
IIS jelas lebih menyukai 4 inti daripada XNUMX, menunjukkan latensi lebih rendah pada XNUMX inti, tetapi juga tidak terlalu menyukai satu inti.
NGINX memiliki skala yang baik di seluruh 8 core, dan untuk Apache, skenario single-core tampaknya menjadi pilihan terbaik.
Skalabilitas:
Nginx:
Sekarang mari kita lihat skalabilitas dalam hal frekuensi dan jumlah inti.
Nginx tidak lulus pengujian dengan batas 1% untuk 4 dan 1 inti; ketika melebihi 2000 permintaan, Nginx memutuskan koneksi dengan penguji.
Apache:
Apache, seperti Nginx, setelah memproses 2500 permintaan, menyerah dan menutup koneksi. Apache gagal dalam pengujian pada 8, 4 dan 1 core dengan batasan 1%, namun selain itu, Apache juga gagal dalam pengujian dengan batasan 5% pada satu core, yang lebih buruk dari Nginx
IIS:
Selama pengujian, IIS mengumpulkan antrian permintaan yang sangat besar tetapi memprosesnya masing-masing. Rupanya, tidak ada batas waktu yang ditetapkan untuk pemrosesan permintaan.
Bagan menunjukkan waktu yang dibutuhkan untuk menyelesaikan tes. Konfigurasi pengujian yang benar-benar tidak masuk akal telah dibuang. Diagram menunjukkan betapa menuntutnya IIS dalam hal perangkat keras, dan betapa hebatnya NGINX.
Skalabilitas dari disk:
Nginx:
Sekarang mari kita lihat skalabilitas dalam hal frekuensi dan jumlah core serta kecepatan disk.
Kali ini Nginx gagal dalam 4 pengujian, bukan dua.
Apache:
Apache gagal dalam jumlah pengujian yang sama seperti terakhir kali.
IIS:
IIS menunjukkan grafik yang hampir sama, seolah-olah tidak ada batasan disk. Secara umum, grafik semua server tidak banyak berubah, yang berarti masing-masing server menyimpan data statis dalam RAM dan menyajikannya dari sana. Di sini kita melihat hambatan utama - server web itu sendiri.
Masih terlalu dini untuk menarik kesimpulan berdasarkan pengujian ini; kami belum menguji HTTPS, kompresi, dan HTTP/2 dengan sertifikat langsung dari Let's Encrypt. Kami akan membicarakan hal ini di artikel berikutnya.
Sumber: www.habr.com