37

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

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

上記の2つの戦略のどちらがより適切にスケーリングされ、その理由は何ですか？

4

5 に答える 5

32

上記の 2 つの戦略のどちらがより適切にスケーリングされますか?またその理由は?

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

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

HTTP 接続に必要なリソースは、スレッド スタックよりも大幅に少なくなります。

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

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

そうは言っても、各リクエストの処理中に長い一時停止がある場合、リクエストごとのスレッドモデルは理想的ではありません。(また、応答ストリームを長時間開いたままにしておくことを含むコメットアプローチをサービスが使用する場合は、特に理想的ではありません。) これをサポートするために、Servlet 3.0 仕様では、サーブレットのリクエスト メソッドが現在のリクエスト スレッドとの関連付けを一時停止します。これにより、スレッドが解放され、別の要求を処理できるようになります。

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

ファローアップ

1000 個の画像を含む 1 つの Web ページを想定してみましょう。これにより、1001 の HTTP 要求が発生します。さらに、HTTP 永続接続が使用されていると仮定しましょう。TPR 戦略では、これにより 1001 スレッド プール管理操作 (TPMO) が発生します。TPC 戦略では、これにより 1 つの TPMO が発生します... 単一の TPMO の実際のコストに応じて、TPC が TPR よりも優れた拡張性を持つシナリオを想像できます。

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

  • ページを完成させるために取得する多数の URL に直面する Web ブラウザーは、複数の接続を開く可能性があります。

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

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

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

これらの要因は、各接続に専用の 1 つのスレッドを使用することによる TPMO の節約よりも重要であると私は感じています。

于 2013-03-05T11:52:11.747 に答える
7

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

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

于 2013-03-05T07:01:37.793 に答える
2

Thread per connection（keep-aliveHTTP Connection ）から同じものを再利用するという概念です。multiple requests

Thread per requesteach requestはからのスレッドを作成します。サーバーはごとclientにいくつでも作成できます。threadsrequest

于 2013-03-05T10:20:55.733 に答える
1

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

接続ごとのスレッドは、複数のリクエスト (キープアライブ) から同じ H​​TTP 接続を再利用します。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

例

于 2013-03-05T10:49:13.373 に答える
0

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

于 2013-03-05T10:42:57.663 に答える