7

IIS を使用する代わりに、WCF サービスを自己ホストすることを考えています。私にとって大きな疑問は、IIS のように複数のサービス ホストをインスタンス化する必要があるのか​​、それとも 1 つでも十分なのかということです。

複数のサービスホストは、分離に起因するセキュリティ上の理由を除いて、何か利点がありますか?

1 つのサービスホストは、1 つのエンドポイントで複数の接続を同時に処理できますか?

4

1 に答える 1

11

実際には、利点も選択肢もありません。1 つServiceHostの (そのクラスのインスタンス) が 1 つのサービスをホストでき、サービスごとに個別のサービス ホストが必要です。これは 1:1 のマッピングです - 常に、選択の余地はありません。

もちろん、Windows NT サービスまたはコンソール アプリでは、複数のServiceHostオブジェクトを同時にアクティブにすることができます。これは、論理的に一緒に属していて、実際には相互に存在しえない一連のサービスがある場合に便利です。サービスの 1 つが開始され、別のサービスが開始されていないというのは意味がありません。

はい、サービス ホストは複数のエンドポイントを公開するサービスをホストでき、複数のクライアントがそれらの個別のエンドポイントに同時に接続できます。問題ありません。WCF ランタイムは、多数のワーカー スレッドをスピンアップして、着信要求を処理します (ServiceThrottling 動作でそれらを制限できます)。

同時呼び出しと要求の数を設定および制御するには、サーバー側で ServiceThrottling の動作を確認する必要があります。

<behaviors>
    <serviceBehaviors>
        <behavior name="serviceThrottled">
            <serviceThrottling
                maxConcurrentCalls="16"
                maxConcurrentInstances="26"
                maxConcurrentSessions="10"/>
        </behavior>
    </serviceBehaviors>
</behaviors>

もちろん、サービス宣言でそのサービス動作構成を参照する必要があります。

<service name="YourService" behaviorConfiguration="serviceThrottled">
  .....
</service>

これらはデフォルト値です。説明は次のとおりです (Dan Rigsby のブログ投稿から抜粋、短縮):

  • MaxConcurrentCalls (デフォルト = 16) [メッセージごと] アクティブに処理できるメッセージの最大数。

  • MaxConcurrentInstances (デフォルト = 26) 一度に実行できるサービス内の InstanceContext オブジェクトの最大数。セッションごとのサービスの場合、これはセッションの最大数に等しく、呼び出しごとのサービスの場合は同時呼び出しの最大数であり、シングルトンの場合は無意味です。

  • MaxConcurrentSessions (デフォルト = 10) [チャネルごと] サービスが一度に受け入れることができるセッションの最大数。セッションベースのバインディング (wsHttp または netTcp) でのみ機能します。

このトピックに関するDan Rigsby の優れたブログ投稿も必ずチェックしてください。

于 2010-01-25T11:26:34.690 に答える