web-dev-qa-db-ja.com

TCP_DEFER_ACCEPTの実際の使用?

私は Apache httpd manual online を熟読していて、これを有効にするためのディレクティブに出くわしました。 tcpのmanページに説明が見つかりました:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

その後、私は この記事 を見つけましたが、これがどのようなワークロードに役立つかはまだわかりません。 httpdにこのための特別なオプションがある場合、それはWebサーバーと何らかの関連があるはずだと思います。また、これはオプションであり、httpdがネットワーク接続を行う方法だけではなく、必要な場合とそうでない場合があると想定しています。

記事を読んだ後でも、3方向ハンドシェイクが完了するのを待つことの利点が何であるかはわかりません。接続が形成された後に遅延が発生する可能性がある代わりに、ハンドシェイクがまだ行われている間に、関連するhttpdインスタンスをスワップインする必要がないことを確認することは有利に思われます。

この記事については、TCP_DEFER_ACCEPTソケットのステータスであり、4つのパケットが必要になります(ハンドシェイクとその後のデータ)。どのようにしてカウントを3に減らすのか、またそれがどのようにして意味のある強化を提供するのかわかりません。

だから私の質問は基本的に:これは古い時代遅れのオプションですか、それともこのオプションの実際の使用例がありますか?

15
Bratchley

(OPに関する私のコメントを要約するため)

彼らが参照している3ウェイハンドシェイクはTCP接続確立の一部であり、問​​題のオプションはこれに特に関連していません。また、データ交換は3つの一部ではないことに注意してください。ハンドシェイクの方法で、これは単にオープン/確立された状態でTCP接続を作成します。

このオプションの存在に関しては、これはソケットの従来の動作ではありません。通常、接続が受け入れられると(3方向のハンドシェイクが完了した後も)ソケットハンドラーのスレッドが起動し、一部のプロトコルアクティビティがここで開始されます(たとえば、SMTPサーバーは220グリーティング行を送信します)が、HTTPの場合、会話の最初のメッセージはGET/POST/etc行を送信するWebブラウザーであり、これが発生するまで、HTTPサーバーは接続に関与しません(タイミング以外)したがって、ソケットの受け入れが完了したときにHTTPプロセスをウェイクアップすることは、プロセスがすぐに再びスリープ状態になり、必要なデータを待機するため、無駄なアクティビティになります。

アイドルプロセスをウェイクアップするとプロセスを「準備」できるという議論は確かにあります(特に、非常に古いマシンでログイン端末をウェイクアップし、スワップから切り離すことを覚えています)が、スワップアウトされたプロセスはすでにそのリソースに要求を出しており、さらに不必要な要求を行うと、全体的にシステムパフォーマンスが低下する可能性があります-個々のスレッドの見かけのパフォーマンスが向上したとしても(非常にビジーなマシンはディスクにボトルネックがあるIOスワップインすると他の処理が遅くなり、そのビジー状態の場合、すぐにスリープ状態になるとすぐにスワップバックされる可能性があります。)ギャンブルのようであり、最終的に「貪欲」なギャンブルはビジー状態のマシンでは必ずしも成果が得られず、すでにプロセスがスワップインされているマシンで余分な不要な作業が確実に発生します。大部分が寮であるプロセスの大容量メモリセットを持つマシンに対してアプローチが最適化されます蟻、そしてある休眠状態を別の休眠状態に交換することは大したことではありませんが、アクティブなプロセスの大きなメモリセットを持つマシンは余分なIOに苦しみ、メモリが制限されていないすべてのマシンは苦しみ、CPUにバインドされたマシンは悪化します。

そのレベルのパフォーマンスチューニングに関する私の一般的なアドバイスは、とにかく何が最善かについてプログラムによる決定を下すのではなく、システム管理者とオペレーティングシステムが連携してリソース管理の問題に対処できるようにすることです-それは彼らの仕事であり、それらは非常に重要ですシステム全体およびそれ以降のワークロードを理解するのにより適しています。オプションと構成の選択肢を提供します。

質問に具体的に答えるために、このオプションは、HTTPトラフィックの極端な負荷がかかった場合を除いて、これまでに気付かれるレベルではなく、すべての構成で有益ですが、理論的にはこれが「正しい」方法です。すべてのUnix(Linuxではない)フレーバーがその機能を備えているわけではないため、これはオプションです。したがって、移植性のために、含まれないように構成できます。

14
iain