2008-08-14 29 views
9

別個のWindowsサービス(RemotingServiceに呼びましょう)で動作するリモートシングルトンサーバーがあります。 RemotingServiceのクライアントはASP.NETインスタンスです(多くは多数)。非同期リモート呼び出し

現在、リモート処理中のクライアントはRemotingServiceを呼び出し、RemotingService呼び出しが処理されている間はブロックします。ただし、remotingサービスは、(RPC呼び出しと複雑なアルゴリズムを使用して)asp.netワーカースレッドが非常に長い時間(4-5秒)ブロックされるほど複雑になっています。

this msdn articleによれば、リモートRPCごとにasp.netワーカースレッドがブロックされているため、これを行うことは適切ではありません。 asp.netワーカースレッドを解放するために非同期ハンドラに切り替えることを勧告しています。

非同期ハンドラ の目的は、ハンドラが 元の要求を処理している間に追加の要求に にサービスを提供するためにASP.NETスレッドプール スレッドを解放することです。

リモート呼び出しがスレッドプールからスレッドを引き継ぐことを除いて、これは問題はありません。 これはasp.netワーカースレッドと同じスレッドプールですか?

リモートシングルトンサーバーをasync.netワーカースレッドを解放するような非同期システムに変更する方法を教えてください。

重要な情報が不足している可能性があります。質問に答えるために必要な情報があれば、教えてください。

答えて

0

ThreadPoolの使用の背景にあるのは、同期スレッドの量を制御できるということです。それらが多すぎると、スレッドプールは自動的に新しいスレッドの待機を管理します。

Asp.Netワーキングスレッド(AFAIK)はスレッドプールから取得されたものではなく、リモート処理サービスの呼び出しによって影響を受けるべきではありません(これは非常に遅いプロセッサで、リモーティング機能は非常にCPUこの場合、コンピュータのすべてが影響を受けます)。

いつもリモートサービスを別の物理サーバーでホストすることができます。その場合、asp.netワーカースレッドは、リモート呼び出しとは完全に独立しています(リモート呼び出しが別のスレッドで呼び出されている場合)。

+0

質問にリンクされている記事に記載されているように、asp.netワーカースレッドは実際にはランタイムスレッドプールからのものです。 – CVertex

関連する問題