nginx - Adakah bilangan permintaan sesaat dan konkurensi adalah konsep yang sama?

Question

Windows menguji pelayan dengan ab apache

ab -c 100 -n 1000 http://www.xxxxx.com

Saya mendapati bahawa bilangan permintaan yang diproses sesaat hanya 20, dan selebihnya sedang menunggu. Bukankah ini bermakna keselarasan lalai nginx adalah sangat tinggi?

Namun, bilangan permintaan yang diproses sesaat dan konkurensi bukanlah konsep yang sama.

Proses sesaat, konkurensi, ujian tekanan, tolong bantu. . .

Answer 1

Hanya bercakap tentang situasi satu pelayan.
Bilangan concurrency merujuk kepada bilangan permintaan yang tiba pada masa yang sama, iaitu dari perspektif pelanggan keupayaan pemprosesan serentak pelayan merujuk kepada berapa banyak permintaan yang boleh dikendalikan oleh pelayan pada masa yang sama (tanpa penukaran proses); concurrency Kuasa pemprosesan adalah sama dengan bilangan teras CPU.
Berdasarkan apa yang dinyatakan di atas, jika terdapat 8 teras dan tugasan yang diminta semuanya adalah tugasan pengkomputeran tulen tanpa IO, maka setiap teras jelas boleh memproses lebih daripada satu permintaan sesaat. Andaikan ia boleh mengendalikan 10,000 (tugas pengkomputeran mudah) setiap kedua. Jika nombor ini benar-benar mungkin), maka pelayan ini boleh mengendalikan 80,000 permintaan sesaat.
Sekarang tambah IO, jika CPU terpaksa menunggu semasa IO dan tidak boleh melakukan perkara lain, maka jelas bilangan permintaan yang boleh dikendalikan oleh CPU sesaat akan berkurangan dengan banyak, mungkin daripada 10,000 kepada ratusan malah berpuluh-puluh atau beberapa.
Seterusnya, anda boleh menambah pelbagai faktor seperti penukaran proses dan kecekapan algoritma Selepas menambah faktor ini satu demi satu, anda boleh mendapatkan pelayan yang kompleks tetapi nyata.

Answer 2

Ia bukan konsep yang sama, tetapi ia berkaitan:
Andaikan purata masa tindak balas ialah t (unit ialah milisaat), konkurensi ialah c, dan bilangan permintaan yang diproses sesaat ialah q, maka:
q = (1000/t) * c
Ini ialah perhubungan;
Fikirkan Untuk meningkatkan q, hanya ada dua cara: 1) Turunkan t 2) Tingkatkan c
Untuk '1', ia hanya boleh dicapai dengan mengoptimumkan kod anda hanya boleh mencuba yang terbaik, dan penambahbaikan adalah selalunya terhad;
Untuk '2', biasanya c Ia berkaitan dengan model pemprosesan permintaan program pelayan anda Jika program pelayan anda berada dalam mod "satu utas sepadan dengan satu permintaan", maka nilai maksimum c adalah terhad dengan berapa banyak utas yang anda boleh sokong; jika ia adalah mod "satu proses sepadan dengan satu permintaan", maka nilai maksimum c adalah tertakluk kepada bilangan proses maksimum

Dalam proses meningkatkan c, satu perkara yang mesti diambil perhatian ialah lebih banyak benang/proses yang ada, lebih banyak penukaran konteks dan overhed penjadualan thread/proses akan meningkat dengan ketara dan secara tidak langsung akan meningkatkan nilai t dan menghalang q . Apabila nilai c meningkat secara berkadar, peningkatan secara membuta tuli biasanya tidak akan menghasilkan keputusan yang baik Nilai c yang paling sesuai harus diperolehi berdasarkan eksperimen eksperimen

Selain itu, terdapat situasi istimewa: jika perniagaan menentukan bahawa perkhidmatan yang disediakan oleh pelayan mempunyai ciri-ciri "volume data kecil dan masa pulangan yang panjang", iaitu, ini adalah jenis perniagaan yang tidak sibuk tetapi sangat lambat , maka NIO boleh digunakan Mod menyediakan perkhidmatan, contohnya, nginx menggunakan mod nio secara lalai
Dalam mod ini, nilai c tidak lagi berkaitan dengan bilangan benang/proses, tetapi hanya kepada "bilangan sambungan soket"; . Biasanya "bilangan sambungan soket" boleh menjadi sangat besar, Pada pelayan Linux yang dikonfigurasikan khas, berjuta-juta sambungan soket boleh disokong pada masa yang sama, c boleh mencapai 1 juta
Di bawah nilai c yang tinggi , tidak kira betapa besarnya t, ia masih boleh menyokong q Sangat tinggi Pada masa yang sama, bilangan benang/proses sebenar hanya boleh dibuka untuk konsisten dengan bilangan teras cpu untuk memaksimumkan penggunaan cpu; Sudah tentu, premis semua ini ialah perniagaan mempunyai "jumlah data yang kecil dan masa pulangan yang panjang" "Ciri-ciri

Answer 3

Kami menganggap bahawa tapak web anda adalah tapak statik dan semua permintaan melalui nginx Kemudian anda perlu mengesahkan bahawa komunikasi rangkaian antara mesin ujian dan pelayan adalah lancar. Alat seperti ab tidak begitu meyakinkan untuk ujian tekanan Kami mengesyorkan jmeter atau loadrunner. Semasa ujian tekanan, adalah perlu untuk memastikan bahawa keluk masa tindak balas ujian adalah stabil untuk tempoh masa tertentu sebelum ia dianggap sebagai prestasi sebenar pelayan yang diuji Ini kerana masa pemanasan tertentu diperlukan pada permulaan ujian Secara amnya, lengkung akan stabil selepas tempoh masa tertentu , kemudian menilai masa tindak balas semasa.

Answer 4

Permintaan sesaat = jumlah bilangan permintaan yang diselesaikan dalam tempoh masa / masa

Jumlah konkurensi ialah bilangan sambungan yang dikekalkan pada masa ini. Lihat semua sambungan melalui netstat -net.

Contohnya:

netstat -ntp |grep -i "80" | wc -l