Willy memberi saya jawaban melalui email. Saya pikir saya akan membagikannya. Jawabannya dicetak tebal.
Saya memiliki pertanyaan tentang konfigurasi haproxy saya:
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
log 127.0.0.1 syslog emerg
maxconn 4000
quiet
user haproxy
group haproxy
daemon
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
mode http
log global
option abortonclose
option dontlognull
option httpclose
option httplog
option forwardfor
option redispatch
timeout connect 10000 # default 10 second time out if a backend is not found
timeout client 300000 # 5 min timeout for client
timeout server 300000 # 5 min timeout for server
stats enable
listen http_proxy localhost:81
balance roundrobin
option httpchk GET /empty.html
server server1 myip:80 maxconn 15 check inter 10000
server server2 myip:80 maxconn 15 check inter 10000
Seperti yang Anda lihat, ini sangat mudah, tetapi saya agak bingung tentang cara kerja properti maxconn.
Ada yang global dan maxconn di server, di blok mendengarkan.
Dan ada juga satu lagi di blok mendengarkan yang defaultnya seperti 2000.
Pemikiran saya adalah ini: global satu mengelola jumlah total koneksi yang haproxy, sebagai layanan, akan mengantri atau memproses pada satu waktu.
Benar. Ini adalah jumlah maksimum koneksi bersamaan per proses.
Jika angkanya melebihi itu, itu akan mematikan koneksi, atau mengumpulkan di beberapa soket linux?
Nanti, itu hanya berhenti menerima koneksi baru dan mereka tetap dalam antrian soket di kernel. Jumlah soket antrian ditentukan oleh min (net.core.somaxconn, net.ipv4.tcp_max_syn_backlog, dan maxconn blok mendengarkan).
Saya tidak tahu apa yang terjadi jika angkanya lebih tinggi dari 4000.
Kelebihan koneksi menunggu koneksi lain selesai sebelum diterima. Namun, selama antrian kernel tidak jenuh, klien bahkan tidak memperhatikan ini, karena koneksi diterima di tingkat TCP tetapi tidak diproses. Jadi klien hanya memperhatikan beberapa penundaan untuk memproses permintaan. Namun dalam praktiknya, maxconn blok pendengar jauh lebih penting, karena secara default lebih kecil dari yang global. Maxconn pendengar membatasi jumlah koneksi per pendengar. Secara umum, bijaksana untuk mengkonfigurasinya untuk jumlah koneksi yang Anda inginkan untuk layanan, dan untuk mengkonfigurasi maxconn global ke jumlah koneksi maksimum yang Anda biarkan proses haproxy menanganinya. Jika Anda hanya memiliki satu layanan, keduanya dapat disetel ke nilai yang sama. Tapi bila Anda memiliki banyak layanan,
Kemudian Anda memiliki properti server maxconn yang disetel pada 15. Pertama, saya menetapkannya pada 15 karena php-fpm saya, ini diteruskan ke server terpisah, hanya memiliki begitu banyak proses anak yang dapat digunakan, jadi saya pastikan saya melakukannya mengumpulkan permintaan di sini, bukan di php-fpm. Yang menurut saya lebih cepat.
Ya, tidak hanya harus lebih cepat, tetapi juga memungkinkan haproxy untuk menemukan server lain yang tersedia kapan pun memungkinkan, dan juga memungkinkannya untuk menghentikan permintaan dalam antrian jika klien menekan "berhenti" sebelum koneksi diteruskan ke server.
Tapi kembali ke pokok bahasan, teori saya tentang nomor ini adalah setiap server di blok ini hanya akan mengirimkan 15 koneksi dalam satu waktu. Dan kemudian koneksi akan menunggu server terbuka. Jika saya mengaktifkan cookie, koneksi akan menunggu server terbuka yang BENAR. Tapi saya tidak.
Itulah prinsipnya. Ada antrian per-proxy dan antrian per-server. Koneksi dengan cookie persistensi pergi ke antrian server dan koneksi lainnya pergi ke antrian proxy. Namun karena dalam kasus Anda tidak ada cookie yang dikonfigurasi, semua koneksi masuk ke antrian proxy. Anda dapat melihat diagram doc / antrian.fig di sumber haproxy jika Anda mau, ini menjelaskan bagaimana / di mana keputusan diambil.
Jadi pertanyaannya adalah:
Apa yang terjadi jika koneksi global melebihi 4000? Apakah mereka mati? Atau pool di Linux entah bagaimana?
Mereka mengantri di linux. Setelah Anda membanjiri antrean kernel, antrean tersebut akan ditempatkan di kernel.
Apakah koneksi global terkait dengan koneksi server, selain fakta bahwa Anda tidak dapat memiliki jumlah koneksi server yang lebih besar dari global?
Tidak, pengaturan koneksi global dan server independen.
Saat mencari tahu koneksi global, bukankah seharusnya jumlah koneksi ditambahkan di bagian server, ditambah persentase tertentu untuk penggabungan? Dan jelas Anda memiliki batasan lain pada koneksi, tetapi sebenarnya berapa banyak yang ingin Anda kirim ke proxy?
Anda benar. Jika waktu respons server Anda pendek, tidak ada salahnya mengantri ribuan koneksi untuk melayani hanya beberapa dalam satu waktu, karena hal itu secara substansial mengurangi waktu pemrosesan permintaan. Praktis, membuat koneksi saat ini membutuhkan waktu sekitar 5 mikrodetik pada LAN gigabit. Jadi sangat masuk akal untuk membiarkan haproxy mendistribusikan koneksi secepat mungkin dari antriannya ke server dengan maxconn yang sangat kecil. Saya ingat satu situs game mengantri lebih dari 30000 koneksi bersamaan dan berjalan dengan antrian 30 per server! Itu adalah server apache, dan apache jauh lebih cepat dengan jumlah koneksi yang kecil dibandingkan dengan jumlah yang besar. Tetapi untuk ini Anda benar-benar membutuhkan server yang cepat, karena Anda tidak t ingin semua klien Anda mengantri menunggu slot koneksi karena server sedang menunggu database misalnya. Juga sesuatu yang bekerja sangat baik adalah mendedikasikan server. Jika situs Anda memiliki banyak statika, Anda dapat mengarahkan permintaan statis ke kumpulan server (atau cache) sehingga Anda tidak memasukkan permintaan statis ke antrean dan permintaan statis tersebut tidak memakan slot koneksi yang mahal. Berharap ini bisa membantu, Willy
