このトピックでは、リソースの消費を制御し、パフォーマンス メトリックに影響を与える Windows Communication Foundation (WCF) アーキテクチャのさまざまな領域のさまざまなプロパティについて説明します。
WCF でリソースの消費を制限するプロパティ
Windows Communication Foundation (WCF) は、セキュリティまたはパフォーマンス上の目的で、特定の種類のプロセスに制約を適用します。 これらの制約は、クォータとスロットルの 2 つの主要な形式で提供されます。 クォータ は、システム内のある時点で、到達または超過した場合に即時例外をトリガーする制限です。 スロットルは、即座に例外を引き起こすことのない制限です。 代わりに、スロットル制限に達すると、処理は続行されますが、そのスロットル値によって設定された制限内になります。 この制限された処理によって、他の場所で例外がトリガーされる可能性がありますが、これはアプリケーションによって異なります。
クォータとスロットルの区別に加えて、一部の制約プロパティはシリアル化レベル、一部はトランスポート レベル、一部はアプリケーション レベルにあります。 たとえば、システムが提供するすべてのトランスポート バインド要素によって実装されるクォータ TransportBindingElement.MaxReceivedMessageSizeは、既定で 65,536 バイトに設定され、悪意のあるクライアントが過剰なメモリ消費を引き起こすことによってサービス拒否攻撃に関与するのを妨げることになります。 (通常、この値を小さくすることでパフォーマンスを向上させることができます)。
シリアル化クォータの例として、 DataContractSerializer.MaxItemsInObjectGraph プロパティがあります。このプロパティは、シリアライザーが 1 つの ReadObject メソッド呼び出しでシリアル化または逆シリアル化するオブジェクトの最大数を指定します。 アプリケーション レベルのスロットルの例として、 ServiceThrottle.MaxConcurrentSessions プロパティがあります。既定では、同時セッションフル チャネル接続の数が 10 に制限されます。 (クォータとは異なり、このスロットル値に達した場合、アプリケーションは処理を続行しますが、新しいセッションフル チャネルは受け入れません。つまり、他のセッションフル チャネルのいずれかが終了するまで、新しいクライアントは接続できません)。
これらのコントロールは、特定の種類の攻撃に対してすぐに使用できる軽減策を提供したり、メモリフットプリント、起動時間などのパフォーマンス メトリックを向上させたりするように設計されています。 ただし、アプリケーションによっては、これらの制御によってサービス アプリケーションのパフォーマンスが低下したり、アプリケーションがまったく動作しなくなる可能性があります。 たとえば、ビデオをストリーミングするように設計されたアプリケーションは、既定の TransportBindingElement.MaxReceivedMessageSize プロパティを簡単に超えることができます。 このトピックでは、WCF のすべてのレベルのアプリケーションに適用されるさまざまなコントロールの概要、設定がアプリケーションを妨げているかどうかに関する詳細情報を取得するさまざまな方法、およびさまざまな問題を修正する方法について説明します。 ほとんどのスロットルと一部のクォータは、基本プロパティがシリアル化またはトランスポートの制約である場合でも、アプリケーション レベルで使用できます。 たとえば、サービス クラスの DataContractSerializer.MaxItemsInObjectGraph プロパティを使用して、ServiceBehaviorAttribute.MaxItemsInObjectGraph プロパティを設定できます。
注
特定の問題がある場合は、まず WCF トラブルシューティング のクイック スタート を読んで、問題 (および解決策) が一覧表示されているかどうかを確認する必要があります。
シリアル化プロセスを制限するプロパティについては、「 データのセキュリティに関する考慮事項」を参照してください。 トランスポートに関連するリソースの消費を制限するプロパティは、 トランスポート クォータに一覧表示されます。 アプリケーション 層でのリソースの消費を制限するプロパティは、 ServiceThrottle クラスのメンバーです。
クォータ設定に関連するアプリケーションとパフォーマンスの問題の検出
上記の値の既定値は、一般的なセキュリティの問題に対する基本的な保護を提供しながら、さまざまな種類のアプリケーションで基本的なアプリケーション機能を有効にするために選択されています。 ただし、アプリケーションの設計が 1 つ以上のスロットル設定を超える場合がありますが、それ以外の場合はセキュリティで保護され、設計どおりに動作します。 このような場合は、どのスロットル値をどのレベルで超えているかを特定し、アプリケーションのスループットを向上させるために適切な措置を決定する必要があります。
通常、アプリケーションを記述してデバッグするときは、 ServiceDebugBehavior.IncludeExceptionDetailInFaults プロパティを構成ファイルまたはプログラムで true するように設定します。 これにより、サービス例外スタック トレースを表示するためにクライアント アプリケーションに返すように WCF に指示されます。 この機能は、問題が発生した場合に関係する可能性のあるクォータ設定を表示するなどの方法で、ほとんどのアプリケーション レベルの例外を報告します。
一部の例外は、実行時にアプリケーション レイヤーの可視性を下回り、このメカニズムを使用して返されず、カスタムの System.ServiceModel.Dispatcher.IErrorHandler 実装では処理されない場合があります。 Microsoft Visual Studio などの開発環境にいる場合、これらの例外のほとんどは自動的に表示されます。 ただし、一部の例外は、 Just My Code Visual Studio などの開発環境の設定によってマスクされる場合があります。
開発環境の機能に関係なく、WCF トレースとメッセージ ログの機能を使用して、すべての例外をデバッグし、アプリケーションのパフォーマンスを調整できます。 詳細については、「 トレースを使用したアプリケーションのトラブルシューティング」を参照してください。
XmlSerializer とパフォーマンスの問題
XmlSerializerを使用してシリアル化可能なデータ型を使用するサービスおよびクライアント アプリケーションは、実行時にそれらのデータ型のシリアル化コードを生成およびコンパイルします。そのため、起動パフォーマンスが低下する可能性があります。
注
事前に生成されたシリアル化コードは、サービスではなく、クライアント アプリケーションでのみ使用できます。
ServiceModel メタデータ ユーティリティ ツール (Svcutil.exe) は、アプリケーションのコンパイル済みアセンブリから必要なシリアル化コードを生成することで、これらのアプリケーションの起動パフォーマンスを向上させることができます。 詳細については、「 方法: XmlSerializer を使用して WCF クライアント アプリケーションの起動時間を短縮する」を参照してください。
ASP.NET で WCF サービスをホストするときのパフォーマンスの問題
WCF サービスが IIS と ASP.NET でホストされている場合、IIS と ASP.NET の構成設定は、WCF サービスのスループットとメモリ占有領域に影響する可能性があります。 ASP.NET パフォーマンスの詳細については、「ASP.NET パフォーマンスの向上」を参照してください。 意図しない結果を招く可能性がある設定の 1 つは、 MinWorkerThreadsです。これは、 ProcessModelSectionのプロパティです。 アプリケーションに固定または少数のクライアントがある場合、 MinWorkerThreads を 2 に設定すると、CPU 使用率が 100%に近いマルチプロセッサ コンピューターでスループットが向上する可能性があります。 このパフォーマンスの向上にはコストが伴います。また、メモリ使用量が増加し、スケーラビリティが低下する可能性があります。