2009-09-09 17 views

答えて

23

Webアプリケーションは、ほぼ確実に既にホスティング環境(IISなど)によってマルチスレッド化されています。ページがCPUにバインドされていて(複数のコアを使用したい場合)、おそらく複数のスレッドが悪い考えです。

時間はかもしれません。あなたはIOバインドされています。たとえば、3つの外部Webサービスと対話し、データベースと対話し、ファイルを作成する必要があるWebページがあります(すべて無関係です)。ローカルCPUを過度に(ここでは実際の遅延はネットワーク上にある)影響を与えずに、全体の処理時間を短縮するために、異なるスレッドで並行して実行することができます(完全なポート使用を最大限にするために組み込みの非同期操作を使用するのが理想です)。

もちろん、このような場合は、Webアプリケーションで作業をキューに入れ、別のサービスをデキューして処理するだけですが、呼び出し元にすぐに応答することはできません完了などを確認するために後で確認する必要があります)。

+1

良い答え、特にinbuilt非同期操作を使用することをお勧めします。 – RichardOD

1

マルチスレッドの恩恵を受けるには、アプリケーションを並行して実行する必要があります。これが当てはまらない場合は、マルチスレッドのオーバーヘッドによってメリットが非常に高くなる可能性があります。

私の経験では、ほとんどのWebアプリケーションは短い実行方法で構成されています。そのため、ホスティング環境で既に提供されている並列処理とは別に、Webアプリケーションの個々の部分でのマルチスレッド化のメリットは稀です。たぶんそれは利点を提供する例がありますが、私の推測ではあまり一般的ではないということです。

3

IMHOウェブベースのアプリケーションでマルチスレッドを使用しないでください。

多分マルチスレッドのアプリケーションは、標準的なアプリケーション(適切なデザイン)でパフォーマンスを向上させるかもしれませんが、Webアプリケーションではスピードではなく高いスループットを保つことができます。

しかし、あなたは、いくつかの同時接続を持っている場合、多分あなたは

1

ASP.NETが、単純な要求処理のためになるよう、すでに並行して複数の要求を処理するために、いくつかのスレッドを生成することのできるグローバルなパフォーマンスを低下させることなく、並列スレッドを使用することができます別のスレッドを手動で生成する必要がある場合はほとんどありません。しかし、私は別のスレッドの作成を保証され渡って来ているいくつかの珍しいシナリオがあります:

  • しばらく時間がかかるかもしれませんし、ページの残りの処理と並行して実行することができ、いくつかの操作があった場合には、そこにセカンダリスレッドを生成するかもしれません。たとえば、リクエストの結果としてポーリングしなければならないWebサービスがある場合、Page_Initに別のスレッドを生成し、Page_reRenderで結果を確認することができます(必要に応じて待機します)。これがパフォーマンス上のメリットかどうかは依然として疑問ですが、スレッドの作成は安価ではなく、典型的なPage_InitとPage_Prerenderの間の時間はミリ秒単位で測定されます。このためにスレッドプールを保持する方が効率が良いかもしれません。また、ASP.NETには、このニーズにさらに適した「非同期ページ」というものがあります。
  • 定期的にクリーンアップするリソースプールがある場合。たとえば、限られた.NETバインディングに付属する奇妙なDBMSを使用しているとしますが、プーリングのサポートはありません(これは私のケースでした)。その場合は、DB接続プールを自分で実装したいと思うかもしれません。これは、1分に1回目を覚まし、長い間使用されていない接続があるかどうかを確認する「クリーナースレッド」を必要としますしたがって、閉鎖することができる)。

ASP.NETで独自のスレッドを実装するときに気を付けなければならないもう1つのことは、ASP.NETがしばらくの間非アクティブになっていた場合、プロセスを強制終了することです。したがって、永遠に生き続けるあなたのスレッドに頼るべきではありません。それはいつでも解雇されるかもしれないし、あなたはそれのために準備ができている方がよい。

2

マルチスレッドは、1つのプロセスに処理時間を増やしてより高速に実行できるようにする技術です。スレッド数が増えるため、CPUサイクルが増えます。 (複数のCPUがある場合は、それがあります。)デスクトップアプリケーションの場合、これは意味があります。しかし、Webユーザーにさらに多くのCPUサイクルを与えることで、同時に要求を行っている99人の他のユーザーから同じサイクルが取り除かれます。技術的には、それは悪いことです。

ただし、Webアプリケーションでは、複数のスレッドを使用している他のサービスやプロセスを使用することがあります。たとえば、データベースは、接続するすべてのユーザーに対して個別のスレッドを作成しません。スレッドの数を数に制限し、接続プールに接続を追加することで、より高速に使用できます。接続が使用可能またはプールされている限り、ユーザーはデータベースにアクセスできます。データベースに接続がなくなると、ユーザーは待機する必要があります。

基本的に、特定の瞬間にアクティブユーザーの数を減らすために、複数のスレッドをWebアプリケーションに使用できます。これにより、システムは、リソースを過負荷にすることなく、複数のユーザーとリソースを共有できます。代わりに、ユーザーは自分の番になる前に一列に並ばなければなりません。

これは、Webアプリケーション自体ではマルチスレッドではなく、Webアプリケーションで消費されるサービスでのマルチスレッドです。この場合、少量のスレッドのみをアクティブにすることによって制限として使用されます。

関連する問題