haproxy: mempertahankan sesi yang ada di bawah beban tinggi, melayani '503' untuk pendatang baru

Mencoba melakukan apa yang tertulis dalam judul: pertahankan sesi yang ada di bawah beban tinggi, dan sajikan 503 pesan kepada pengunjung yang baru tiba.

Masalah: itu berhasil, tetapi sesi tidak bertahan lebih dari sekitar 90 detik.

Hasil saat ini membuat saya bertanya-tanya apakah ada pengaturan waktu habis yang saya lewatkan.

Tujuan

Saya mencoba membuat haproxy ke:

• kirim permintaan untuk sesi baru ke backend-001 ketika jumlah total sesi di frontend berada di bawah batas tertentu.
• melayani kesalahan 503 untuk sesi baru ketika jumlah total sesi di frontend berada di atas ambang batas itu
• memungkinkan permintaan untuk sesi yang ada bahkan jika jumlah sesi melebihi ambang batas

Dengan cara ini, pengunjung yang tengah mengisi formulir multi-langkah tidak akan dikejutkan oleh kesalahan 503, dan pengunjung baru dapat diminta untuk "silakan kembali lagi nanti karena kami benar-benar sibuk sekarang".

Mempersiapkan

Setup adalah sebagai berikut:

            {visitors}
                ↓ 
            [haproxy]
                ↓ 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

pendekatan saat ini

Untuk mencapai hal di atas, saya menggunakan konfigurasi di bawah ini.

Yang ini untuk pengujian, dengan batas yang sangat rendah (10 koneksi di front-end (fe_conn gt 10)), untuk membuat pengujian lebih mudah.

Untuk menempatkan server di bawah beberapa beban, saya menggunakan httperf sebagai berikut:

httperf --hog --server staging.machine.tld --uri / do_some_things --wsess = 500,10,30 --rate 2

global
    daemon
    maxconn 10000

defaults
    mode        http
    timeout connect 6s
    timeout client  60s
    timeout server  60s
    balance roundrobin
    option http-server-close

frontend http-in
    bind [PUBLIC_IP]:80

    default_backend backend-001

    acl too_many fe_conn gt 10
    use_backend b_too_many if too_many

backend backend-001
    fullconn 10
    appsession _session_id len 128 timeout 7200s

    cookie SERVERID insert maxidle 7200s
    server Server1 127.0.10.1:80 cookie backend-001 check

backend b_too_many
    errorfile 503 /var/www/50x.html

masalah

Seperti disebutkan di atas, masalahnya adalah: hampir berhasil, tetapi sesi tidak bertahan lebih dari sekitar 90 detik.

Jika Anda terus mengklik, Anda bisa menjaga sesi Anda bahkan ketika ada 10 sesi sibuk.

Mencoba membuka halaman di server dengan contoh browser yang berbeda membuat Anda mendapatkan kesalahan-503.

Jadi, sepertinya saya hampir sampai. Adakah yang tahu apa yang menyebabkan waktu sesi singkat?

Dan khususnya bagaimana saya bisa memperbaikinya :)

(sunting: dihapus 'weight 1 maxconn 10' dari 'server'-line, tidak relevan dan mungkin membingungkan) (edit ke-2: koreksi '10 sesi di front-end' ke '10 koneksi di front-end ')

Sayangnya, koneksi Anda tampaknya benar-benar membingungkan dengan sesi tingkat aplikasi. Seorang pengguna yang mengunjungi situs tersebut mungkin memiliki cookie yang membuat Anda berpikir dia memiliki koneksi sementara itu belum tentu demikian. Dia mungkin membuka banyak koneksi yang diperlukan untuk mengambil objek dan menavigasi halaman.

90 detik yang Anda amati tentu saja merupakan batas waktu browser yang tetap hidup untuk koneksi idle.

Dimungkinkan untuk mencapai apa yang Anda inginkan tetapi itu sedikit lebih kompleks dari itu, karena Anda juga harus mempertimbangkan keberadaan cookie kegigihan dalam permintaan untuk mengetahui apakah pengunjung itu baru atau tidak.

Juga secara umum lebih efisien untuk mengandalkan jumlah koneksi rata-rata per-server daripada pada jumlah koneksi frontend. Alasannya adalah bahwa ketika server mati, Anda harus menyesuaikan kembali nomor ini. Cara paling efisien untuk melakukannya adalah dengan mengatur nilai maxconn server untuk mengaktifkan antrian, dan menggunakan avg_queue sehingga batas berlaku untuk jumlah rata-rata permintaan antrian di server. Ini memungkinkan Anda untuk menangani pengunjung yang dikenal dengan benar sambil memindahkan pengguna baru dengan lembut ke backend lain ketika beban meningkat karena pengunjung yang ada.