信頼できるセッションのベスト プラクティス

  • [アーティクル]

このトピックでは、信頼できるセッションに関するベスト プラクティスをいくつか紹介します。

MaxTransferWindowSize の設定

Windows Communication Foundation (WCF) の信頼できるセッションでは、転送ウィンドウを使用して、クライアント側およびサービス側のメッセージを保持しています。 MaxTransferWindowSize プロパティは、この転送ウィンドウに保持できるメッセージの最大数を表します。

送信側については、送信後に受信確認の到着を待機しているメッセージ、受信側についてはサービスの処理待ちメッセージを、それぞれいくつまで保持しておけるかを表します。

適切なサイズを選択することが、ネットワークの効率性や、サービスの容量の最適化に影響します。 以下では、このプロパティの値を決める上で検討する事項と、その値が与える影響について解説します。

転送ウィンドウ サイズの既定メッセージ数は 8 です。

ネットワークの利用効率

ここでいうネットワークとは、クライアント (送信側) とサービス (受信側) で通信基盤として使用されるものすべてを指します。 したがって、伝送路だけでなく、その間に介在する SOAP ルーターや HTTP プロキシ/ファイアウォールなども含まれます。

ネットワーク効率が高いとは、その伝送容量を最大限に活用できるということです。 1 秒間に伝送できるデータ量 (データ レート)、送信側から受信側にデータが届くまでにかかる時間 (遅延) のどちらもが、ネットワーク効率に関係します。

送信側については、転送ウィンドウに保持できる受信確認の到着を待機しているメッセージの数が MaxTransferWindowSize プロパティによって表されます。 遅延が大きいネットワークほど、応答性を高めてネットワーク利用効率を上げるために、転送ウィンドウ サイズを増やす必要があります。

送信側で高いデータ レートを維持していても、受信側に到達するまでにいくつもの中継装置 (ルーターなど) が介在していたり、データ消失が発生したりすると、データが通過する中継装置やネットワークの遅延は大きくなります。 したがって、送出したメッセージは、受信確認が届くまで長い時間転送ウィンドウに保持しておかなければならず、これが上限に達すると次のメッセージを送出できません。 このように、遅延が大きいのに転送ウィンドウ サイズが小さいと、ネットワーク効率が損なわれてしまいます。 一方、これが大き過ぎると、クライアントによって送信されるデータを高速に処理しなければならなくなるため、サービスの処理効率に悪影響を与える可能性があります。

サービスの可用性向上

ネットワーク効率が最適であれば、サービスも処理能力を最大限に活用して稼働させるのが理想的です。 受信側の転送ウィンドウ サイズは、処理待ちのメッセージをいくつまで保持しておけるかを表します。 メッセージをこのようにバッファーに保持することは、ネットワークのフロー制御だけでなく、処理能力を最大限に活用したサービス稼働にも役立ちます。 たとえば、バッファーに保持できるメッセージ数が 1 だとすると、サービスが処理できる以上の頻度でメッセージが届く場合、メッセージがネットワークによって廃棄されるほか、処理能力が無駄に消費され、十分に活用されないおそれがあります。

バッファーを使用すると、同時に複数のメッセージを受信し、前のメッセージが処理中であればそのまま保持しておくことができるので、サービスの可用性が向上します。

MaxTransferWindowSize の値は、送信側と受信側で同じにしておくことをお勧めします。

フロー制御の有効化

フロー制御とは、送信側と受信側とが歩調を揃えるための機構です。このしくみにより、メッセージが生成される速度で、メッセージの受け入れと処理が行われます。 クライアントとサービスの転送ウィンドウ サイズは、送信側と受信側が妥当な許容範囲内で同期できるように設定しなければなりません。

WCF クライアントと WCF サービスの間で信頼できるセッションを使用する場合、FlowControlEnabled プロパティを true に設定することを強くお勧めします。

MaxPendingChannels の設定

通信セッションを開く相手 (クライアント) が可変であるように設計されたサービスは、同時にいくつものクライアントと信頼できるセッションを確立することができます。 このとき、サービスの応答性は、MaxPendingChannels プロパティによって決まります。

信頼できるセッション チャネルが送信側によって作成されると、両者のハンドシェイクによって信頼できるセッションが確立します。 これが終わるとチャネルは保留チャネル キューに入り、サービス側からの応答を待機する状態になります。 MaxPendingChannels プロパティは、この状態にできるチャネルの数を表します。

次々にセッションを確立していくと、サービス側は、これ以上新しいチャネルを使用してセッションを確立することができない状態になります。 キューがいっぱいになると、信頼できるセッションを確立しようとしても拒否されるので、クライアント側はしばらく待って再試行するしかありません。

また、いったんキューに入った保留チャネルは、そのまま長期間留まる可能性があります。 そうしているうちに、信頼できるセッションが稼働していないとしてタイムアウトとなり、チャネルは "失敗" という状態に遷移します。

複数のクライアントに対して同時にサービスを提供するサービスの設計においては、この値を適切に決めることが重要です。 MaxPendingChannels プロパティの値が大き過ぎるとワーキング セットにも悪影響が現れます。

MaxPendingChannels の既定値は 4 チャネルです。

信頼できるセッションとホスティング

信頼できるセッションを使用するサービスを Web ホスティングする場合は、次のことを念頭に置く必要があります。

  • 信頼できるセッションはステートフルであり、状態は AppDomain で管理されます。 したがって、信頼できるセッションでやりとりするメッセージはすべて、同じ AppDomain で処理する必要があります。 Web ファームや Web ガーデンで、ファームやガーデンのサイズが 1 ノードより大きいと、この制約が保証されません。

  • 信頼できるセッションで双方向 HTTP チャネル (WsDualHttpBinding など) が使用される場合、クライアントあたりの HTTP 接続数が、既定値である 2 では足りなくなる可能性があります。 双方向の信頼できるセッションでは、アプリケーション メッセージとプロトコル メッセージが同時に双方向で伝送されることがあり、その場合、一方向につき最大 2 つの接続が必要になるからです。 したがって、特定の条件下で、サービスのメッセージ交換パターンによっては、双方向 HTTP と信頼できるセッションを使用した Web ホスト サービスが、デッドロックを起こす可能性があります。 クライアントあたりの利用可能な HTTP 接続数を増やすには、適切な構成ファイル (当該サービスの web.config など) に、次のような記述を追加してください。

    <configuration>
  <system.net>
    <connectionManagement>
      <add name="*" maxconnection="4" />
    </connectionManagement>
  </system.net>
</configuration>

    maxconnection 属性の値は、必要な接続数です。 この場合、接続数の最小値は 4 になります。