基本的に、Juval Lowy が提唱した「WCF マスター クラス」から学ぶと、呼び出しごとのアクティブ化は、スケーリングが必要なサービス、つまり多数の同時要求を処理する必要があるサービスに適しています。
なんで?
呼び出しごとに、各着信要求 (構成可能な制限まで) は、要求を処理するために、サービス クラスの独自の新しい分離されたインスタンスを取得します。サービス クラス (単純な古い .NET クラス) のインスタンス化は大きなオーバーヘッドではありません。WCF ランタイムは、10、20、50 の同時実行サービス インスタンスを簡単に管理できます (サーバー ハードウェアが処理できる場合)。各リクエストは独自のサービス インスタンスを取得するため、そのインスタンスは一度に 1 つのスレッドを処理するだけです。また、プログラムと保守が非常に簡単で、面倒なロックやスレッドセーフにするための必要はありません。
シングルトン サービス ( InstanceContextMode=Single
) を使用することは、ひどいボトルネック (ある場合ConcurrencyMode=Single
- 各要求がシリアル化され、次々に処理される) か、適切なパフォーマンスが必要な場合は が必要ですがConcurrencyMode=Multiple
、それはサービス クラス処理のインスタンスが 1 つあることを意味します。複数の同時スレッド - その場合、そのサービス クラスのプログラマーは、すべてのコード、変数などへのすべてのアクセスが 100% スレッド セーフであることを 100% 確認する必要があります。この黒魔術を本当にマスターするプログラマーはごくわずかです。
私の意見では、呼び出しごとのシナリオでサービス クラス インスタンスを作成するオーバーヘッドは、マルチスレッド シングルトン WCF サービス クラスの完全にスレッド セーフな実装を作成する要件に比べれば大したことはありません。
したがって、中央キューを使用した具体的な例では、次のようになります。
クライアントから呼び出され、メッセージをキューに入れるだけの単純な WCF 呼び出しごとのサービスを作成します (たとえば、受信データなどを変換するなど、適切な方法で)。これは迅速なタスクであり、大したことではなく、いかなる種類の重い処理もありません。したがって、サービス クラスは非常に簡単で、非常に単純であり、これらのクラス インスタンスを作成するための大きなオーバーヘッドはまったくありません。
次に、キューを読み取って処理を行うワーカー サービス (Windows NT サービスなど) を作成します。これは基本的に、WCF コードから完全に独立しています。これは、キューから取り出して処理するだけです。
つまり、私が言いたいのは、サービス呼び出し (データを配信する) を、キューを作成して大規模で処理集約的な計算を行う必要から切り離すことです。責任を分割してください。WCF サービスはデータのみを受信し、それをキューまたはデータベースに入れてから、それを処理します-そして、2番目の別のプロセスが処理/重労働を行う必要があります。これにより、WCF サービスが無駄のないものになります