web-dev-qa-db-ja.com

なぜMaxKeepAliveRequestsを無制限以外に設定するのですか?

Apacheの KeepAliveTimeout は、一定の時間内に新しいリクエストが発行されない場合にキープアライブ接続を閉じるために存在します。ユーザーがブラウザ/タブを閉じない場合、このタイムアウト(通常は5〜15秒)が最終的にほとんどのキープアライブ接続を閉じ、接続を無期限に保持することでサーバーリソースの浪費を防ぎます。

MaxKeepAliveRequests ディレクティブは、単一のTCP接続のために開くHTTPリクエストの数に制限を課します(- KeepAlive )が配信されます。これを0に設定すると、無制限の数のリクエストが許可されます。

なぜこれを「無制限」以外に設定するのでしょうか?クライアントがまだアクティブにリクエストを行っている場合、それらを発生させるにはどのような害がありますか?同じキープアライブ接続?制限に達した後も、新しい接続でのみリクエストが送信されます。

私の見方では、これを制限しても意味がありません。何が欠けていますか?

11

基本的に、Apacheはそのために構築されていないためです。問題はサーバーのメモリ使用量です。多くの構成では、コンテンツ生成はコンテンツ配信と同じプロセスで行われるため、各プロセスは処理する最大のもののサイズに成長します。重いPHPスクリプトのために64MBに拡張するプロセスを想像してください。それから、肥大化したプロセスが静的ファイルを配置して提供します。これに100を掛けます。また、メモリリークがどこかにある場合、プロセスは無制限に大きくなります。

キープアライブ設定は、コンテンツのタイプとトラフィックに基づいてバランスを取る必要があります。一般に、最適な構成では、MaxKeepAliveRequestsを高く(100〜500)、KeepAliveTimeoutを低く(2〜5)して、すばやく解放します。

4
Dirigible

私はこれが古い質問であることを知っていますが、デバッグを行っており、MaxKeepAliveRequestsKeepAliveTimeoutとは独立して機能しているように見えます(これはApacheだけに当てはまるわけではありません)。

つまり、タイムアウトディレクティブは、アイドル状態の永続的な接続に対してのみカウントされます(読み取りまたは書き込みではありません)。タイムアウト未満でリクエストを続けると、同じ接続で事実上無制限の量のリクエストを実行できます。

これは、長時間実行されるTCP接続がランダムに強制終了されるなど、いくつかの理由で適切でない場合がありますか?いずれの場合でも、httpクライアントはそれほど愚かではなく、「低い」MaxKeepAliveRequests設定をかなりうまく処理できます。プログラミング言語では、TCP接続がサーバーによって閉じられているかどうかを検出するのが比較的簡単なので、サーバーに再接続します。さらに、ほとんどのhttpクライアントは独自に制限を設けます(たとえば、ブラウザーは300秒程度でキープアライブ接続を閉じます)。

1
lifeofguenter

1つの理由は、負荷分散のためです。キープアライブまたはhttp 1.1の永続的な接続が確立されると、ロードバランサーは閉じるまで新しいホストに移動しません。 1つのクライアントが1つの接続を介して大量のリクエストを行っている場合、サーバー間で適切なバランスが取れないことがあります。

1
dtauzell

部分的には、1人のユーザーがすべての接続スロットを占有しないようにするためです。制限がなければ、悪意のあるクライアントまたは不適切に作成されたクライアントが、利用可能なすべての接続を乗っ取り、永久にそれらを保持する可能性があります。ただし、これは、IPごとの接続制限のようなものと比較して、そのための大きな緩和策ではありません。

主にロードバランシングですが、特にメンテナンスに関してです。サーバーをオフラインにしたい場合は、サーバーを0接続にドロップしますが、既存の接続を一定時間終了させます。キープアライブ要求の数に制限を設けることは、最終的にユーザーが新しい接続を適切に作成し、新しいバックエンドサーバーに移動することを意味します。おそらく、ドレインプロセス中にキープアライブの受け入れを完全に停止する必要があることをサーバーに通知する何らかの方法がさらに良いでしょうが、私が知る限り、そのような機能は存在しません。

0
Elliott