HAプロキシを構成するとき、タイムアウトに割り当てる値をどのように決定しますか？私はさまざまなブログで半ダースのサンプルを読みましたが、誰もが異なるタイムアウトを使用しており、誰もその理由について議論していません。

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'.

この点に関しては、ドキュメントは役に立たない：「3秒の倍数をわずかに超える」ことを示唆しているが、1対100または42の倍数を選択する理由は示唆していない。

私が使用しているRPM（Amazon Linuxリポジトリ）はこれらのデフォルトを設定します：

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

そのうちの2つは3秒の正確な倍数であり、私が見た唯一の公式アドバイスに違反しています。

特定のチューニングのアドバイスがない場合は、おそらく簡単な質問があります：本当に短いまたは本当に長いタイムアウトで何がうまくいかないのでしょうか？

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）負荷分散に常に受け入れられるMOSTアグレッシブタイムアウトです。これらよりも低い場合は、ロードバランサーを再構成します。

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

タイムアウトクライアント：

非アクティブタイムアウトは、クライアントがデータを確認または送信すると予想される場合に適用されます。HTTPモードでは、このタイムアウトは、クライアントが要求を送信する最初のフェーズ、およびサーバーから送信されたデータを読み取っている間の応答中に考慮することが特に重要です。

読み取り：これは、クライアントからHTTP要求ヘッダーを受信する最大時間です。

3G / 4G / 56k /サテライトは時々遅くなる可能性があります。それでも、30秒ではなく、数秒でHTTPヘッダーを送信できるはずです。

誰かの接続が非常に悪く、ページをリクエストするのに30秒以上必要な場合（10個の埋め込み画像/ CSS / JSをリクエストするのに10 * 30秒以上）、彼を拒否することは受け入れられると思います。

タイムアウトサーバー：

非アクティブタイムアウトは、サーバーがデータを確認または送信すると予想される場合に適用されます。HTTPモードでは、このタイムアウトは、サーバーの要求の処理時間を直接表すため、サーバーの応答の最初のフェーズでヘッダーを送信する必要があるときに考慮することが特に重要です。そこに置く値を見つけるには、許容できない応答時間と考えられるものから始めてから、ログを確認して応答時間の分布を観察し、それに応じて値を調整することをお勧めします。

読み取り：これは、サーバーからHTTP応答ヘッダーを受信する最大時間です（完全なクライアント要求を受信した後）。基本的に、これはサーバーが応答の送信を開始するまでの処理時間です。

サーバーの応答速度が非常に遅いため、回答を開始するのに30秒以上かかる場合は、サーバーが停止していると見なしてもかまいません。

特別な場合：非常に重い処理を行う一部のRAREサービスでは、回答を得るのに1分以上かかる場合があります。この特定の使用法では、このタイムアウトを大幅に増やす必要がある場合があります。（注：これは、設計が不適切な場合、非同期スタイルの通信を使用するか、HTTPをまったく使用しない可能性があります。）

タイムアウト接続：

サーバーへの接続試行が成功するまで待機する最大時間を設定します。

読み取り：サーバーがTCP接続を受け入れる必要がある最大時間。

サーバーはHAProxyと同じLANにあるため、高速になります。予想外の事態（再送信するTCPパケットの損失、サーバーが新しい要求を受け取るために新しいプロセスをフォークする、トラフィックが急増する）が発生するまでにかかる可能性があるため、少なくとも5秒を与えます。

特殊なケース：サーバーが異なるLANまたは信頼性の低いリンク上にある場合。このタイムアウトを大幅に増やす必要がある場合があります。（注：これは、悪いアーキテクチャのケースである可能性があります。）

タイムアウトチェック：

追加のチェックタイムアウトを設定しますが、これは接続が既に確立された後でのみです。

追加のチェックタイムアウトを設定しますが、接続が既に設定されている場合のみ、haproxyはチェックの接続タイムアウトとしてmin（ "timeout connect"、 "inter"）を使用し、追加の読み取りタイムアウトとして "timeout check"を使用します。「min」は、非常に長い「タイムアウト接続」で実行している人々（キューやターピットのためにこれを必要とした人々）がチェックを遅くしないように使用されます。（また、「タイムアウトキュー」と「タイムアウトターピット」は常にそれを回避するために使用できるため、このような長い接続タイムアウトを持つ正当な理由はないことに注意してください）。

読み取り：ヘルスチェックを実行する場合、サーバーはtimeout connect接続を受け入れてからtimeout check応答する必要があります。

すべてのサーバーにHTTP（S）ヘルスチェックを設定する必要があります。ロードバランサーがサーバーが利用可能かどうかを知る唯一の方法です。ヘルスチェックは、/isalive常に応答するシンプルなページですOK。

予期せぬ事態（再送信するTCPパケットの損失、サーバーが新しい要求を受け取るために新しいプロセスをフォークする、トラフィックが急増する）が発生するまでにかかる時間が5秒以上であるため、このタイムアウトを与えます。

War Story：多くの人々は、サーバーがこの単純なページに常に3ミリ秒で応答できると誤って信じています。アグレッシブフェールオーバー（2回のチェック失敗=サーバーが停止）でアグレッシブタイムアウト（<2000ms）を設定します。そのため、ウェブサイト全体がダウンするのを見てきました。通常、トラフィックにわずかなスパイクがあり、バックエンドサーバーが遅くなり、ヘルスチェックが遅延します。突然すべてが一緒にタイムアウトになるまで、HAProxyはすべてのサーバーが同時に停止し、サイト全体がダウンしたと判断します。