Saat mengonfigurasi HA Proxy, bagaimana Anda memutuskan nilai apa yang akan ditetapkan untuk timeout? Saya telah membaca setengah lusin sampel di berbagai blog, dan semua orang menggunakan batas waktu berbeda dan tidak ada yang membahas mengapa.

HAProxy secara khusus khawatir tentang klien, koneksi, dan server, yang HAPRoxy berikan peringatan jika Anda benar-benar tidak disetel:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

The dokumentasi tidak membantu dalam hal ini: itu menunjukkan "kelipatan sedikit di atas dari 3 detik" tapi tidak mengapa Anda akan memilih beberapa dari 1 vs 100 atau 42.

RPM yang saya gunakan (repositori Amazon Linux) menetapkan default ini:

timeout connect         10s
timeout client          1m
timeout server          1m

Dua di antaranya adalah kelipatan tepat 3 detik, melanggar satu-satunya saran resmi yang pernah saya lihat.

Jika Anda tidak memiliki saran penyetelan tertentu, mungkin pertanyaan yang lebih mudah adalah: apa yang harus saya perkirakan salah dengan timeout yang sangat pendek atau sangat lama?

TCP RTO (menerima batas waktu) dimulai pada tiga detik. ( RFC 1122 ) Jika paket yang ditransmisikan tidak memiliki pengakuan yang dikembalikan pada waktu itu, maka itu dianggap hilang dan dikirim kembali. Ini hampir pasti apa yang penulis maksudkan. (Perhatikan bahwa RTO disetel ke atas atau ke bawah secara dinamis oleh berbagai algoritme , di luar cakupan pertanyaan ini.)

Perlu diingat bahwa ini hanya berlaku untuk koneksi antara server frontend Anda dan klien (yaitu pengguna web). Dalam skenario normal, koneksi antara HAProxy dan server backend Anda harus pada LAN dan Anda harus menggunakan timeout yang jauh lebih pendek, sehingga backend yang tidak berfungsi dapat dihilangkan dari layanan lebih cepat.

Adapun pengguna web Anda, beberapa dari mereka mungkin berada pada koneksi latensi yang sangat tinggi, seperti satelit, dan mungkin mengalami transmisi ulang yang lebih tinggi dari normal karena hal ini. RTT pada koneksi yang menggunakan satelit dapat melebihi 2000 ms bahkan jika semuanya baik-baik saja.

Dengan semua ini dalam pikiran, Anda biasanya ingin waktu tunggu yang sangat singkat timeout connectdan lama timeout client.

Sebab timeout server, ini tergantung pada aplikasi web Anda. Saat mengatur batas waktu, pertimbangkan kerumitan aplikasi web yang dilayani, dan berapa lama waktu yang dibutuhkan untuk memproses permintaan yang kompleks. Jika ragu, naikkan nilainya.

Kata pengantar

Saya telah menyetel HAProxy sebentar dan melakukan banyak pengujian kinerja di atasnya. Dari 100 permintaan HTTP hingga 50.000 permintaan HTTP.

Saran pertama adalah mengaktifkan halaman statistik di HAProxy . Anda MEMBUTUHKAN pemantauan, tidak terkecuali. Anda juga akan membutuhkan penyetelan yang bagus jika Anda bermaksud melampaui 10.000 permintaan.

Timeout adalah binatang yang membingungkan karena mereka memiliki sejumlah besar nilai yang mungkin, kebanyakan dari mereka tidak memiliki perbedaan yang dapat diamati. Saya belum melihat sesuatu yang gagal karena angka 5% lebih rendah atau 5% lebih tinggi. 10000 vs 11000 milidetik, siapa yang peduli? Mungkin bukan sistem Anda.

Konfigurasi

Dalam hati nurani yang baik, saya tidak bisa memberikan beberapa angka sebagai 'batas waktu terbaik untuk semua orang'.

Yang bisa saya katakan adalah timeout paling agresif yang selalu dapat diterima untuk penyeimbangan beban HTTP (S). Jika Anda menemukan lebih rendah dari ini, saatnya untuk mengkonfigurasi ulang penyeimbang beban Anda.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

klien timeout:

Batas waktu tidak aktif berlaku ketika klien diharapkan untuk mengakui atau mengirim data. Dalam mode HTTP, batas waktu ini sangat penting untuk dipertimbangkan selama fase pertama, ketika klien mengirim permintaan, dan selama respons saat sedang membaca data yang dikirim oleh server.

Baca : Ini adalah waktu maksimum untuk menerima tajuk permintaan HTTP dari klien.

3G / 4G / 56k / satelit terkadang lambat. Namun, mereka harus dapat mengirim tajuk HTTP dalam beberapa detik, BUKAN 30.

Jika seseorang memiliki koneksi yang sangat buruk sehingga perlu lebih dari 30-an untuk meminta halaman (kemudian lebih dari 10 * 30-an untuk meminta 10 gambar yang disematkan / CSS / JS), saya yakin dapat diterima untuk menolaknya.

server batas waktu:

Batas waktu tidak aktif berlaku ketika server diharapkan untuk mengakui atau mengirim data. Dalam mode HTTP, batas waktu ini sangat penting untuk dipertimbangkan selama fase pertama dari respons server, ketika harus mengirim header, karena secara langsung mewakili waktu pemrosesan server untuk permintaan tersebut. Untuk mengetahui nilai apa yang diletakkan di sana, sering kali baik untuk memulai dengan apa yang dianggap sebagai waktu respons yang tidak dapat diterima, kemudian periksa log untuk mengamati distribusi waktu respons, dan sesuaikan nilainya.

Baca : Ini adalah waktu maksimum untuk menerima header respons HTTP dari server (setelah menerima permintaan klien lengkap). Pada dasarnya, ini adalah waktu pemrosesan dari server Anda, sebelum mulai mengirim respons.

Jika server Anda sangat lambat sehingga membutuhkan lebih dari 30-an untuk mulai memberikan jawaban, maka saya percaya itu dapat diterima untuk menganggapnya mati.

Kasus Khusus : Beberapa layanan RARE yang melakukan pemrosesan sangat berat mungkin membutuhkan satu menit penuh atau lebih untuk memberikan jawaban. Waktu tunggu ini mungkin perlu ditingkatkan banyak untuk penggunaan khusus ini. (Catatan: Ini mungkin merupakan kasus desain yang buruk, menggunakan komunikasi gaya async atau tidak menggunakan HTTP sama sekali.)

batas waktu koneksi:

Tetapkan waktu maksimum untuk menunggu upaya koneksi ke server berhasil.

Baca : Waktu maksimum server harus menerima koneksi TCP.

Server berada di LAN yang sama dengan HAProxy sehingga harus cepat. Berikan setidaknya 5 detik karena itulah berapa lama waktu yang dibutuhkan ketika sesuatu yang tidak terduga terjadi (paket TCP yang hilang untuk mentransmisikan kembali, server yang meminta proses baru untuk menerima permintaan baru, lonjakan lalu lintas).

Kasus Khusus : Ketika server berada dalam LAN yang berbeda atau melalui tautan yang tidak dapat diandalkan. Waktu tunggu ini mungkin perlu ditingkatkan banyak. (Catatan: Ini kemungkinan merupakan kasus arsitektur yang buruk.)

pemeriksaan batas waktu:

Tetapkan batas waktu pemeriksaan tambahan, tetapi hanya setelah koneksi dibuat.

Tetapkan batas waktu pemeriksaan tambahan, tetapi hanya setelah koneksi telah ditetapkan. Jika diatur, haproxy menggunakan min ("batas waktu koneksi", "antar") sebagai batas waktu koneksi untuk pemeriksaan dan "batas waktu pemeriksaan" sebagai batas waktu baca tambahan. "Min" digunakan sehingga orang yang menjalankan dengan "timeout connect" yang sangat lama (mis. Mereka yang membutuhkan ini karena antrian atau tarpit) tidak memperlambat pemeriksaan mereka. (Harap perhatikan juga bahwa tidak ada alasan yang sah untuk memiliki batas waktu koneksi yang panjang, karena "antrean batas waktu" dan "batas waktu tarpit" selalu dapat digunakan untuk menghindarinya).

Baca : Saat melakukan pemeriksaan kesehatan, server harus timeout connectmenerima koneksi lalu timeout checkmemberikan respons.

Semua server HARUS memiliki pemeriksaan kesehatan HTTP (S) yang dikonfigurasi. Itulah satu-satunya cara penyeimbang beban untuk mengetahui apakah server tersedia. Pemeriksaan kesehatan adalah /isalivehalaman sederhana yang selalu menjawab OK.

Berikan batas waktu ini setidaknya 5 detik karena itu berapa lama waktu yang diperlukan ketika sesuatu yang tidak terduga terjadi (paket TCP yang hilang untuk mengirim ulang, server yang meminta proses baru untuk menerima permintaan baru, lonjakan lalu lintas).

Kisah Perang : Banyak orang salah percaya bahwa server selalu dapat menjawab halaman sederhana ini dalam 3 ms. Mereka menetapkan batas waktu agresif (<2000 ms) dengan failover agresif (2 pemeriksaan gagal = server mati). Saya telah melihat seluruh situs web turun karena itu. Biasanya ada sedikit lonjakan lalu lintas, server backend menjadi lebih lambat, pemeriksaan kesehatan tertunda ... sampai tiba-tiba mereka semua timeout bersama, HAProxy berpikir SEMUA server mati sekaligus dan seluruh situs mati.