web-dev-qa-db-ja.com

接続あたりのスレッドとリクエストあたりのスレッドの違いは何ですか？

さまざまなサーブレット実装に実装されている2つの方法論について説明してください。

  1. 接続ごとのスレッド
  2. リクエストごとのスレッド

上記の2つの戦略のどちらがより適切にスケールし、なぜですか？

javamultithreadinghttpservlets
30
Geek

上記の2つの戦略のどちらがより適切にスケーリングし、なぜですか？

リクエストごとのスレッドは、接続ごとのスレッドよりも適切にスケーリングされます。

Javaスレッドはかなり高価で、アクティブかアイドルかに関係なく、通常それぞれ1Mbのメモリセグメントを使用します。各接続に独自のスレッドを割り当てると、通常、そのスレッドは接続での連続する要求の間にアイドル状態になります。最終的に、フレームワークは新しい接続の受け入れを停止するか（これ以上スレッドを作成できないため）、古い接続の切断を開始する必要があります（これにより、ユーザーがウェイクアップしたときに、接続がチャーンされます）。

HTTP接続はスレッドスタックよりも必要なリソースが大幅に少なくなりますが、TCP/IPの動作方法により、IPアドレスごとに64Kのオープン接続の制限があります。

対照的に、要求ごとのスレッドモデルでは、要求が処理されている間のみスレッドが関連付けられます。これは通常、同じ数のユーザーを処理するのに必要なスレッドの数が少ないことを意味します。スレッドは大量のリソースを使用するため、サービスのスケーラビリティが向上します。

（そして、リクエストごとのスレッドは、フレームワークがTCP HTTPリクエスト間の接続を閉じる必要があることを意味するわけではないことに注意してください...）

そうは言っても、各要求の処理中に長い休止がある場合、要求ごとのスレッドモデルは理想的ではありません。 （そして、サービスが comet アプローチを使用する場合、特に理想的ではありません。これは、応答ストリームを長時間開いたままにすることを含みます。）これをサポートするために、サーブレット3.0仕様は「非同期サーブレット」メカニズムを提供しますこれにより、サーブレットのリクエストメソッドは、現在のリクエストスレッドとの関連付けを一時停止できます。これにより、スレッドが解放され、別の要求が処理されます。

「非同期」メカニズムを使用するようにWebアプリケーションを設計できる場合、リクエストごとのスレッドまたは接続ごとのスレッドのどちらよりもスケーラブルになる可能性があります。

[〜＃〜]フォローアップ[〜＃〜]

1000枚の画像がある単一のWebページを想定します。これにより、1001 HTTPリクエストが発生します。さらに、HTTP持続接続が使用されていると仮定します。 TPR戦略では、これにより1001のスレッドプール管理操作（TPMO）が発生します。 TPC戦略では、これにより1つのTPMOが得られます... 1つのTPMOの実際のコストに応じて、TPCがTPRよりも適切にスケーリングできるシナリオを想像できます。

あなたが考慮していないいくつかのことがあると思います：

  • ページを完了するためにフェッチする多くのURLに直面したWebブラウザーは、複数の接続を開く可能性があります。

  • TPCおよび永続的な接続では、スレッドはクライアントが応答を受信して​​次の要求を送信するのを待つ必要があります。ネットワーク待機時間が長い場合、この待機時間はかなり長くなる可能性があります。

  • サーバーは、指定された（永続的な）接続をいつ閉じることができるかを知る方法がありません。ブラウザーが閉じない場合は、サーバーが接続をタイムアウトするまでTPCスレッドを拘束して「長引く」可能性があります。

  • TPMOのオーバーヘッドはそれほど大きくありません。特に、プールのオーバーヘッドをコンテキストスイッチのオーバーヘッドから分離する場合はそうです。 （TPCは永続的な接続でコンテキストスイッチを発生させるため、これを行う必要があります。上記を参照してください。）

私の考えでは、これらの要因は、各接続に1つのスレッドを割り当てることによるTPMOの節約を上回る可能性があります。

26
Stephen C

HTTP 1.1-永続的な接続をサポートしています。つまり、同じHTTP接続を使用して、複数の要求/応答を受信/送信できます。そのため、同じ接続を使用して受信したリクエストを並行して実行するために、リクエストごとに新しいThreadが作成されます。

HTTP 1.0-このバージョンでは、接続を使用して1つの要求のみが受信され、応答の送信後に接続が閉じられました。したがって、1つの接続に対して1つのスレッドのみが作成されました。

6
Narendra Pathai

Thread per connectionは、HTTP Connection（ keep-alive ）の同じmultiple requestsを再利用する概念です。

Thread per requestはclientからeach requestのスレッドを作成します。サーバーはthreadsに従ってrequestの数を作成できます。

3
Suresh Atta

リクエストごとのスレッドは、サーバーが受信する各HTTPリクエストに対してスレッドを作成します。

接続ごとのスレッドは、複数のリクエストから同じHTTP接続を再利用します（キープアライブ）.AKA HTTP永続的接続 ただし注意してくださいこれはHTTP 1.1からのみサポートされていること

リクエストごとのスレッドは、ほとんどのWebコンテナーがスレッドプーリングを使用するため、より高速です。

サーバーのコアの数に設定する必要がある最大並列接続の数。より多くのコア=>より多くの並列スレッド。

設定方法はこちらをご覧ください... Tomcat 6： http://Tomcat.Apache.org/Tomcat-6.0-doc/config/executor.html

Tomcat 7： http://Tomcat.Apache.org/Tomcat-7.0-doc/config/executor.html

例

1
Sudhakar

リクエストごとのスレッドは、一部のクライアントがアイドル状態のときにスレッドを再利用するため、より優れているはずです。多数の同時ユーザーがいる場合、少ない数のスレッドでサービスを提供でき、同じ数のスレッドを使用する方がコストが高くなります。また、もう1つ考慮すべき点があります。ユーザーがまだアプリケーションを操作しているかどうかはわからないため、スレッドを破棄するタイミングがわかりません。リクエストメカニズムごとのスレッドでは、スレッドプールを使用します。

0
Mikhail