HAプロキシ構成でタイムアウトを調整する基準は何ですか？
HAプロキシを構成するとき、タイムアウトに割り当てる値をどのように決定しますか？私はさまざまなブログで5ダースのサンプルを読んだことがあり、誰もが異なるタイムアウトを使用しており、誰もその理由について議論していません。
HAProxyは、クライアント、接続、およびサーバーを特に心配しているようです。HAPRoxyは、完全に未設定のままにした場合に警告をスローします。
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'.
documentation はこの点では役に立ちません。「3秒の倍数より少し上」が示唆されていますが、1の倍数と100または42の倍数を選択する理由はわかりません。
私が使用しているRPM（Amazon Linuxリポジトリ）は、これらのデフォルトを設定します。
timeout connect 10s
timeout client 1m
timeout server 1m
そのうち2つはexact3秒の倍数であり、私が見た唯一の公式アドバイスに違反しています。
特定のチューニングアドバイスがない場合は、おそらくもっと簡単な質問です。本当に短いまたは本当に長いタイムアウトで何がうまくいかないと思いますか？
TCP RTO（受信タイムアウト）は3秒で開始します。 （ RFC 1122 ）送信されたパケットに確認応答が返されなかった場合その間、それは失われて再送信されたと見なされます。これは、ほぼ間違いなく作成者が言及しているものです（RTOは さまざまなアルゴリズム によって動的に調整されることに注意してください。この質問。）
これは実際には、フロントエンドサーバーとクライアント（つまり、Webユーザー）間の接続にのみ適用されることに注意してください。通常のシナリオでは、HAProxyとバックエンドサーバー間の接続はLAN上にある必要があり、はるかに短いタイムアウトを使用して、誤動作しているバックエンドがより早くサービスから除外されるようにする必要があります。
Webユーザーに関しては、衛星などの非常に待ち時間の長い接続を使用している可能性があり、これが原因で通常よりも高い再送信が発生する可能性があります。衛星が使用されている接続のRTTは、すべてが正常であっても2000ミリ秒を超えることがあります。
これらすべてを念頭に置いて、通常、timeout connectには非常に短いタイムアウトを、timeout clientには非常に長いタイムアウトを必要とします。
timeout serverの場合、これはWebアプリケーションによって異なります。タイムアウトを設定するときは、提供されるWebアプリの複雑さと、最悪の場合に複雑なリクエストを処理するのにかかる時間を考慮してください。疑問がある場合は、値を上げてください。
序文
私はしばらくの間HAProxyを調整しており、その上で多くのパフォーマンステストを行ってきました。 100 HTTPリクエスト/秒から50 000 HTTPリクエスト/秒。
最初のアドバイスはHAProxyの統計ページを有効にするです。あなたは監視が必要です、例外はありません。 10,000リクエスト/秒を超える場合は、微調整も必要です。
タイムアウトは、可能な値の範囲が非常に広いため、混乱を招く可能性があります。ほとんどの場合、観察可能な違いはありません。数値が5％低い、または5％多いため、何かが失敗することはまだありません。 10000対11000ミリ秒、誰が気にしますか？おそらくあなたのシステムではありません。
構成
私は良心的に、「誰にとっても最高のタイムアウト」としていくつかの数字を与えることはできません。
代わりに私が言えることは、HTTP（S）負荷分散で常に許容できる最も積極的なタイムアウトです。これらよりも低い場合は、ロードバランサーを再構成します。
timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000
タイムアウトクライアント：
非アクティブタイムアウトは、クライアントがデータを確認または送信すると予想される場合に適用されます。 HTTPモードでは、クライアントが要求を送信する最初のフェーズ中、およびサーバーが送信したデータを読み取っている間の応答中に、このタイムアウトを考慮することが特に重要です。
Read：これは、クライアントからHTTPリクエストheadersを受信する最大時間です。
3G/4G/56k /衛星は時々遅くなることがあります。それでも、30秒ではなく、数秒でHTTPヘッダーを送信できるはずです。
接続が非常に悪いため、ページをリクエストするのに30秒以上（その後、10 * 30s以上で10の埋め込み画像/ CSS/JSをリクエスト）する必要がある場合は、拒否しても問題ないと思います。
タイムアウトサーバー：
非アクティブタイムアウトは、サーバーがデータを確認または送信すると予想される場合に適用されます。 HTTPモードでは、このタイムアウトは、サーバーのリクエストの処理時間を直接表すため、ヘッダーを送信する必要があるサーバーの応答の最初のフェーズで考慮することが特に重要です。そこにどの値を設定するかを見つけるには、許容できない応答時間と見なされるものから始めて、ログを確認して応答時間の分布を観察し、それに応じて値を調整するとよいでしょう。
Read：これはHTTP応答を受信する最大時間ですheadersサーバーから（完全なクライアント要求を受信した後）。基本的に、これは、サーバーが応答の送信を開始する前の、サーバーからの処理時間です。
サーバーの速度が非常に遅く、回答を開始するのに30秒以上かかる場合は、サーバーが停止していると見なしても問題ありません。
特殊なケース：非常に重い処理を実行する一部のRAREサービスは、回答を得るのに1分以上かかる場合があります。この特定の使用法では、このタイムアウトを大幅に増やす必要がある場合があります。 （注：これは設計の不良の可能性があります。非同期スタイルの通信を使用するか、HTTPをまったく使用しないでください。）
タイムアウト接続：
サーバーへの接続試行が成功するまで待機する最大時間を設定します。
読み取り：サーバーがTCP接続を受け入れるまでの最大時間。
サーバーはHAProxyと同じLANにあるため、高速である必要があります。予期しない事態が発生した場合にかかる時間であるため、少なくとも5秒かかります（失われたTCP再送信するパケット、サーバーが新しいプロセスをフォークして新しい要求を受け取る、トラフィックが急増する） 。
特殊なケース：サーバーが別のLANにある場合、または信頼できないリンク上にある場合。このタイムアウトは、大幅に増やす必要がある場合があります。 （注：これは、アーキテクチャーが悪い場合である可能性があります。）
タイムアウトチェック：
追加のチェックタイムアウトを設定しますが、接続がすでに確立されている場合のみです。
追加のチェックタイムアウトを設定しますが、接続が既に確立されている場合のみ設定されている場合、haproxyはチェックの接続タイムアウトとしてmin（ "timeout connect"、 "inter"）を使用し、追加の読み取りタイムアウトとして "timeout check"を使用します。 「min」は、very長い「タイムアウト接続」で実行している人々（たとえば、キューまたはターピットのためにこれを必要とした人々）が実行できるように使用されます。チェックを遅くしないでください。 （また、「タイムアウトキュー」と「タイムアウトターピット」は常にそれを回避するために使用できるため、そのような長い接続タイムアウトを設定する正当な理由がないことに注意してください）。
読み取り：ヘルスチェックを実行すると、サーバーにはtimeout connect接続を受け入れる場合はtimeout check応答を提供します。
すべてのサーバーにHTTP（S）ヘルスチェックが設定されている必要があります。これが、サーバーが利用可能かどうかをロードバランサーが知る唯一の方法です。 healthcheckはシンプルです/isaliveページは常にOKと応答します。
予期しない事態が発生した場合にかかる時間です（TCP再送信するパケット、サーバーが新しいリクエストを処理するために新しいプロセスをフォークし、トラフィックが急増するため） ）。
ウォーストーリー：多くの人間違ってサーバーがこの単純なページに常に3ミリ秒で応答できると信じています。彼らは、積極的なフェイルオーバー（2つの失敗したチェック=サーバーの停止）で積極的なタイムアウト（<2000ms）を設定しました。そのため、ウェブサイト全体がダウンするのを見てきました。通常、トラフィックにわずかなスパイクがあり、バックエンドサーバーが遅くなり、ヘルスチェックが遅延します...突然すべてがタイムアウトするまで、HAProxyはすべてのサーバーが一度に停止し、サイト全体がダウンしたと見なします。