Apakah itu segmentasi Soket dalam pelayan Nginx

Keluaran 1.9.1 nginx memperkenalkan ciri baharu: membenarkan penggunaan pilihan soket so_reuseport, yang tersedia dalam versi baharu banyak sistem pengendalian, termasuk dragonfly bsd dan linux (kernel versi 3.9 dan lebih baru ). Pilihan soket ini membolehkan berbilang soket mendengar pada gabungan IP dan port yang sama. Kernel dapat memuatkan baki sambungan masuk merentasi soket ini. (Untuk pelanggan nginx plus, ciri ini akan muncul dalam versi 7, yang akan dikeluarkan menjelang akhir tahun)

Pilihan so_reuseport mempunyai banyak aplikasi dunia sebenar yang berpotensi. Perkhidmatan lain juga boleh menggunakannya untuk hanya melaksanakan naik taraf rolling semasa pelaksanaan (nginx sudah menyokong naik taraf rolling). Untuk nginx, mendayakan pilihan ini boleh mengurangkan pertikaian kunci dalam senario tertentu dan meningkatkan prestasi.

Seperti yang diterangkan dalam rajah di bawah, apabila pilihan so_reuseport sah, soket pendengaran yang berasingan memberitahu proses pekerja sambungan yang diakses dan setiap urutan pekerja cuba mendapatkan sambungan.

Apabila pilihan so_reuseport didayakan, terdapat berbilang pendengar soket untuk setiap alamat IP dan sambungan terikat port, dan setiap proses pekerja boleh diberikan satu . Kernel sistem menentukan pendengar soket yang sah (dan secara tersirat, untuk proses pekerja yang mana) mendapat sambungan. Ini boleh mengurangkan persaingan kunci antara proses pekerja apabila mendapatkan sambungan baharu (Nota Penterjemah: Persaingan antara proses pekerja yang meminta untuk mendapatkan kunci sumber yang saling eksklusif), dan boleh meningkatkan prestasi pada sistem berbilang teras. Walau bagaimanapun, ini juga bermakna apabila proses pekerja jatuh ke dalam operasi penyekatan, penyekatan itu bukan sahaja menjejaskan proses pekerja yang telah menerima sambungan, tetapi juga menyebabkan proses pekerja yang dijadualkan diperuntukkan oleh kernel untuk menghantar permintaan sambungan dan oleh itu. menjadi tersekat.

Tetapkan soket kongsi

Untuk pilihan soket so_reuseport berfungsi, ia mestilah http atau tcp (mod penstriman ) Item dengar dalam pilihan komunikasi secara langsung memperkenalkan parameter penggunaan semula terkini, seperti dalam contoh berikut:

Salin kod Kod adalah seperti berikut:

http {
pelayan { listen 80 reuseport;
server_name localhost;
}
}
}
...
}
}

Selepas merujuk parameter reuseport, parameter accept_mutex akan menjadi tidak sah untuk soket yang dirujuk, kerana mutex (mutex) adalah berlebihan untuk digunakan semula. Untuk port yang tidak menggunakan reuseport, tetap bernilai untuk menetapkan accept_mutex.

Ujian prestasi penanda aras Reuseport

Saya menjalankan alat penanda aras pada tika AWS 36 teras untuk menguji 4 proses pekerja nginx Untuk mengurangkan kesan rangkaian, kedua-dua pelanggan dan nginx sedang berjalan secara local , dan biarkan nginx mengembalikan rentetan ok dan bukannya fail. Saya membandingkan tiga konfigurasi nginx: lalai (bersamaan dengan accept_mutex on), accept_mutex off, dan reuseport. Seperti yang ditunjukkan dalam rajah, permintaan sesaat penggunaan semula adalah dua hingga tiga kali ganda daripada yang lain, manakala kependaman dan sisihan piawai kependaman juga dikurangkan.

Saya menjalankan satu lagi ujian prestasi yang berkaitan - klien dan nginx berada pada mesin yang berbeza dan nginx mengembalikan fail html. Seperti yang ditunjukkan dalam jadual di bawah, pengurangan kependaman menggunakan penggunaan semula adalah serupa dengan ujian prestasi sebelumnya, dengan pengurangan sisihan piawai dalam kependaman adalah lebih ketara (hampir satu persepuluh). Keputusan lain (tidak ditunjukkan dalam jadual) adalah sama menggalakkan. Menggunakan reuseport, beban diagihkan sama rata antara proses pekerja. Di bawah keadaan lalai (bersamaan dengan accept_mutex on), sesetengah pekerja menerima peratusan beban yang lebih tinggi, manakala dengan off accept_mutex semua pekerja menerima beban yang lebih tinggi.

Salin kod Kod adalah seperti berikut:

latency stdev (ms) beban cpu

lalai 15.65 26.59 0.3

accept_mutex off 15.59 26.48 10.3.59 26.48 10.3.59 26.48 10. 🎜>

Dalam ujian prestasi ini, kelajuan permintaan sambungan adalah sangat tinggi, tetapi permintaan itu tidak memerlukan banyak pemprosesan. Ujian asas lain harus menunjukkan bahawa penggunaan semula juga boleh meningkatkan prestasi dengan ketara apabila trafik aplikasi sesuai dengan senario ini. (Parameter penggunaan semula tidak boleh digunakan dalam arahan dengar dalam konteks mel, seperti e-mel, kerana trafik e-mel pasti tidak sepadan dengan senario ini.) Kami menggalakkan anda untuk menguji terlebih dahulu daripada menggunakannya secara langsung pada skala besar.

Atas ialah kandungan terperinci Apakah itu segmentasi Soket dalam pelayan Nginx. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!