Dalam artikel ini kita akan mencuba tangan kita pada kejuruteraan terbalik, seseorang mungkin berkata. Kami akan meletakkan tangan kotor kami di bawah tudung setiap pelayan web, mengeksploitasi mereka dengan cara yang tidak akan dieksploitasi oleh sesiapa pun.
Ujian ini adalah ukuran kuda sfera dalam vakum, tidak lebih daripada data yang diperoleh, dan sekarang kita tidak tahu apa yang perlu dilakukan dengannya.
Metodologi
Sistem pengendalian untuk Nginx dan Apache ialah Ubuntu 18.04 LTS, untuk IIS Windows Server Core 2019. Sebelum ujian, semua sistem pengendalian menerima kemas kini terkini setakat 04.12.2019 Disember XNUMX.
Ujian telah dijalankan secara eksklusif melalui HTTP. Setiap pelayan web menjalankan halaman yang sama, templat Jekyll percuma daripada Codrops. . Setiap pelayan web telah dilumpuhkan pemampatan gzip.
Ujian throughput dilakukan dengan Httpd-tools dengan hujah:
ab -n 50000 -c 500 http://192.168.76.204:80/Pelayan dihadkan kepada 10, 5 dan 1 peratus daripada teras pada 8, 4 dan satu teras. Bangku ujian ialah komputer dengan 9900K@5400MHz, yang bermaksud pelayan yang menerima had 10% menerima kira-kira 540MHz setiap teras.
Ujian TTFB telah dijalankan apabila pelayan mula-mula but dan diukur menggunakan DevTools; selepas menerima keputusan, pelayan telah dimatikan dan dilancarkan semula ke pusat pemeriksaan sebelumnya untuk menghapuskan kemunculan sebarang jenis cache.
Penguji dan pelayan web berada pada hos yang sama dan pada suis maya yang sama.
Untuk menilai segera subsistem cakera, keputusan penanda aras ATTO dan CrystalDIskMark untuk mendapatkan idea tentang kesesakan.
Data yang diambil dari mesin maya:
Keputusan:
TTFB:
Purata TTFB untuk IIS ialah yang terkecil, 0,5ms, berbanding 1,4ms untuk Apache dan 4ms untuk Nginx.
Keluaran:
Mula-mula, mari kita lihat sejauh mana setiap pelayan berskala berdasarkan bilangan teras.
Graf menunjukkan bilangan panggilan penguji ke pelayan web dan kependaman. Graf menunjukkan bahawa NGINX memproses 98% daripada semua permintaan, menghantar tapak dalam 20ms atau kurang. IIS, seperti Apache, menyelesaikan 5% terakhir semua panggilan dalam 76ms dan 14ms, masing-masing.
Graf menunjukkan purata masa pemprosesan untuk satu permintaan semasa ujian tekanan.
Seperti yang anda boleh lihat daripada graf, IIS melemahkan kedua-dua Apache dan Nginx, perlahan dengan ketara di bawah beban yang tinggi.
IIS jelas mengutamakan 4 teras berbanding XNUMX, menunjukkan kependaman yang lebih rendah pada XNUMX, tetapi juga tidak memihak kepada satu teras.
Skala NGINX dengan baik merentas semua 8 teras, dan untuk Apache, senario teras tunggal nampaknya merupakan pilihan terbaik.
Kebolehskalaan:
Nginx:
Sekarang mari kita lihat kebolehskalaan dari segi kekerapan dan bilangan teras.
Nginx tidak lulus ujian dengan had 1% untuk 4 dan 1 teras; apabila melebihi 2000 permintaan, ia menamatkan sambungan dengan penguji.
Apache:
Apache, seperti Nginx, telah memproses 2500 permintaan, menyerah dan menutup sambungan. Apache gagal ujian pada 8, 4 dan 1 teras dengan had 1%, tetapi di samping itu ia juga gagal ujian dengan had 5% pada satu teras, yang lebih buruk daripada Nginx
IIS:
Semasa ujian, IIS mengumpul barisan besar permintaan tetapi memproses setiap permintaan. Nampaknya, di luar kotak tidak ada tamat masa yang ditetapkan untuk pemprosesan permintaan.
Carta menunjukkan masa yang diambil untuk menyelesaikan ujian. Konfigurasi ujian yang tidak masuk akal sepenuhnya telah dibuang. Rajah menunjukkan betapa menuntut IIS dalam hal perkakasan, dan betapa hebatnya NGINX.
Kebolehskalaan daripada cakera:
Nginx:
Sekarang mari kita lihat kebolehskalaan dari segi kekerapan dan bilangan teras dan kelajuan cakera.
Kali ini Nginx gagal 4 ujian dan bukannya dua.
Apache:
Apache gagal bilangan ujian yang sama seperti kali terakhir.
IIS:
IIS menunjukkan graf yang hampir sama, seolah-olah tiada sekatan cakera. Secara umum, grafik semua pelayan tidak banyak berubah, yang bermaksud bahawa setiap daripada mereka menyimpan data statik dalam RAM dan menyampaikannya dari sana. Di sini kita melihat kesesakan utama - pelayan web itu sendiri.
Masih terlalu awal untuk membuat kesimpulan berdasarkan ujian ini; kami belum lagi menguji HTTPS, mampatan dan HTTP/2 dengan sijil langsung daripada Let's Encrypt. Kami akan membincangkan perkara ini dalam artikel seterusnya.
Sumber: www.habr.com