次の方法で共有

Windows Communication Foundation (WCF) と既存の分散通信テクノロジのパフォーマンス比較

  • [アーティクル]

 

Saurabh Gupta
プログラム マネージャー
Microsoft Corporation

2007 年 2 月

概要： この記事では、Windows Communication Foundation (WCF) と既存の Microsoft .NET 分散通信テクノロジの高レベルのパフォーマンス比較について説明します。 (22ページ印刷)

内容

1.はじめに
2. 目標
3. 比較
   3.1 ASP .NET Web Services (ASMX)
      3.1.1 IIS でホストされる相互運用可能な基本プロファイル 1.0 Web サービス
      3.1.2 トランスポート セキュリティを使用した IIS ホスト型相互運用可能な基本プロファイル 1.0 Web サービス
   3.2 Web サービスの機能強化 (WSE)
      3.2.1 WS-Security を使用した IIS ホスト型相互運用可能 Web サービス
   3.3 .NET Enterprise Services (ES)
      3.3.1 Self-Hosted要求/応答 TCP アプリケーション
      3.3.2 セキュリティで保護された要求/応答 TCP アプリケーションのSelf-Hosted
      3.3.3 Secure Transacted Request/Reply TCP アプリケーション
   3.4 .NET リモート処理
      3.4.1 名前付きパイプ アプリケーションの要求/応答
4. 結論
5. 付録
   5.1 バインディングの説明
   5.2 パフォーマンステストマシンの構成
6. 参考資料
7. 著者について
8. 確認

1.はじめに

Windows Communication Foundation (WCF) は、.NET Framework 3.0 の一部として提供される分散通信テクノロジです。 この記事では、WCF のパフォーマンスと既存の .NET 分散通信テクノロジの比較に重点を置きます。 この記事の前提条件は、WCF について十分に理解している必要があります。 WCF のアーキテクチャの概要については、「Windows Communication Foundation アーキテクチャの概要」を参照してください。また、WCF 標準バインディングを使用してサービスを構築する方法については、 の「Windows Communication Foundation Services の構築の概要」 https://msdn.microsoft.com/en-us/library/を参照してください。

2. 目標

この記事の目的は、WCF と他の既存の .NET 分散通信テクノロジのパフォーマンス比較を提供することです。 これらのテクノロジは次のとおりです。

  • ASP.NET Web サービス (ASMX)
  • Web サービスの機能強化 (WSE)
  • .NET Enterprise Services (ES)
  • .NET リモート処理

この記事で説明するシナリオとデータは、さまざまなテクノロジの基になるコストを定量化します。 このデータは、これらのテクノロジ間の関係を理解するのに役立ち、テクノロジ間の移行を計画する場合に役立ちます。 ただし、この記事に記載されているデータから結論を導き出す場合には注意が必要です。 適切に設計されたサービス指向アーキテクチャ (SOA) ソリューションのパフォーマンス要因の制限は、基になる通信テクノロジのコストではなく、サービス実装自体である可能性が最も高くなります。 アプリケーションのパフォーマンス特性を確認するには、各アプリケーションを測定する必要があります。 この記事では、WCF を使用する場合のパフォーマンスのベスト プラクティスについては説明しません。 むしろ、既存の .NET 分散通信テクノロジを基礎として使用する場合に、十分な情報を提供して、情報に基づいたパフォーマンスの決定を行えるように努めています。

3. 比較

この記事で説明したすべてのデータは、同じハードウェア構成を使用して収集されました。Uni または Quad プロセッサとして構成されたサーバーを駆動するために 4 つの双方向クライアント システムが使用されました。 いずれのシナリオでもネットワークがボトルネックではないことを保証するために、2 GB のカードが 2 つ採用されました。 使用されるトポロジの詳細については、図 14 を参照してください。

クライアント システムで使用されるクライアント プロセスの数は、サーバー上の CPU が完全に飽和していることを確認するのに十分でした。 収集および提示されたデータは、複数のコンバージデント実行の平均を反映しており、すべてのデータが非常に反復可能で持続可能であることを確認するために注意が払われました。

記事のすべての比較はスループットの比較であり、達成された値が高いほど良くなります。 すべてのグラフで、バーが大きいほどパフォーマンスが向上します。

この記事では、.NET 分散通信テクノロジのサーバー スループットに焦点を当てています。 これは、これらのテクノロジが維持できる 1 秒ごとの操作の数として定義されます。 オペレーションとは、サービスによる処理が少ない要求と応答メッセージです。 概要で説明したように、ここで繰り返しますが、非常に重要であるため、適切に構築された SOA ソリューションでサービスのコストがビジネス ロジックによって支配されることが予想されます。 サービスでのビジネス ロジック処理を無視した場合、メッセージング インフラストラクチャのコストのみが測定されます。

使用されるメッセージ ペイロードは比較シナリオによって異なり、比較テクノロジごとに説明されます。

3.1 ASP .NET Web Services (ASMX)

このセクションでは、ASP.NET Web サービスのパフォーマンスを WCF のパフォーマンスと比較します。 シナリオは、クライアントとサービスの間の要求/応答です。 これは、両方のテクノロジの一般的なメッセージ交換パターンです。 このシナリオの要求メッセージは、整数を送信するために必要です。 応答メッセージは、1、10、または 100 個のオブジェクトの配列で構成され、各オブジェクトの長さは約 256 バイトです。 WCF オブジェクトは、厳密に型指定されたデータ コントラクトのインスタンスです。

サービスでメッセージ ペイロード (オブジェクト) を生成するために使用される関数のシグネチャを次に示します。

Order[] GetOrders(int NumOrders);
{
            Order[] orders = new Order[numOrders];
            for (int i = 0; i < numOrders; i++)
            {
                Order order = new Order();
                OrderLine[] lines = new OrderLine[2];
                lines[0] = new OrderLine();
                lines[0].ItemID = 1;
                lines[0].Quantity = 10;
                lines[1] = new OrderLine();
                lines[1].ItemID = 2;
                lines[1].Quantity = 5;
                order.orderItems = lines;
                order.CustomerID = 100;
                order.ShippingAddress1 = "012345678901234567890123456789";
                order.ShippingAddress2 = "012345678901234567890123456789";
                order.ShippingCity = "0123456789";
                order.ShippingState = "0123456789012345";
                order.ShippingZip = "12345-1234";
                order.ShippingCountry = "United States";
                order.ShipType = "Courier";
                order.CreditCardType = "XYZ";
                order.CreditCardNumber = "0123456789012345";
                order.CreditCardExpiration = DateTime.UtcNow;
                order.CreditCardName = "01234567890123456789";
                orders[i] = order;
            }
            return orders;
}

3.1.1 IIS でホストされる相互運用可能な基本プロファイル 1.0 Web サービス

このセクションでは、IIS 6.0 でホストされている ASMX と WCF のパフォーマンスを比較します。 どちらの場合も、セキュリティは使用されません。 使用される WCF バインディングは BasicHttpBinding です。 この標準バインディングでは、トランスポート プロトコルとして HTTP が使用されます。 基本プロファイルの仕様は、 にあります http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html。 .NET Framework 2.0 の一部である ASP.NET 2.0 には、基本プロファイルへの準拠を保証する CLR 属性が用意されています。 WCF の場合、 BasicHttpBinding は同じレベルの保証を提供します。

図 1 に示すように、WCF では ASMX よりもパフォーマンスが向上しています。 グラフには、3 つの異なる操作シグネチャ (ペイロード) が表示されます。 いずれの場合も、クライアントからサーバーに整数が渡され、オブジェクトの配列 (1、10、または 100) がクライアントに返されます。 WCF は、メッセージ内の 1、10、および 100 個のオブジェクトについて、それぞれ ASMX を 27%、31%、48% 上回ります。

図 2 のグラフは、図 1 と同じシナリオで、クワッド プロセッサで実行されている WCF と ASMX のスループット比較を示しています。 WCF のスループット パフォーマンスは、メッセージ内の 1、10、および 100 個のオブジェクトについて、それぞれ ASMX より 19%、21%、36% 優れています。 使用されるソフトウェアは 2 つの構成間で変更されておらず、1 つのサービスがサーバー上で公開されていることに注意してください。 前の 2 つのグラフのデータを比較すると、テクノロジ固有のスケーラビリティが確認できます。

図 1

図 2

3.1.2 トランスポート セキュリティを使用した IIS ホスト型相互運用可能な基本プロファイル 1.0 Web サービス

このセクションでは、WCF のパフォーマンスを、両方とも HTTPS 経由で動作する ASMX のパフォーマンスと比較します。 WCF では、このシナリオに BasicHttpBinding が使用されます。 図 3 は、トランスポート レベルのセキュリティを使用する場合の WCF のパフォーマンスが ASMX よりも優れていることを示しています。 WCF は、メッセージ内の 1、10、100 の各オブジェクトについて、ASMX を 16%、18%、26% 上回ります。

図 4 は、WCF のパフォーマンスが ASMX よりも 5%、12%、および 13% が 1、10、および 100 個のオブジェクトが 1 つのクワッド プロセッサ シナリオのメッセージに対してそれぞれ優れていることを示しています。

図 3

図 4

3.2 Web サービスの機能強化 (WSE)

このセクションでは、WCF のスループットと Web サービス拡張機能のスループットを比較します。 この場合の比較は WSE 2.0 ですが、WSE 2.0 と 3.0 のパフォーマンスは、このペイロードに対して似ています。 このシナリオで使用されるメソッドシグネチャとペイロードは、ASMX シナリオで使用されるのと同じです (セクション 3.1 を参照)。

3.2.1 WS-Security を使用した IIS ホスト型相互運用可能 Web サービス

このセクションでは、X. 509 証明書を使用したメッセージ レベルのセキュリティをセキュリティ資格情報として使用します。 WSHttpBinding は、WS-Security 1.1 仕様を実装する WCF で使用されます。 使用されるトランスポート プロトコルは HTTP であり、メッセージ交換パターンは要求/応答のままです。

図 5 は、WCF が WSE よりもはるかに効率的であることを示しています。 WCF のスループットは WSE の約 4 倍です。 そのメイン理由は、WSE がSystem.Xmlを使用しているということです。メッセージ レベルの解析を行う XmlDocument クラス。これにより、完全なメッセージが一度にメモリに読み込まれますが、WCF ではストリーミングSystem.Xmlが使用されます。パフォーマンスを大幅に向上させる XmlReader クラス。

図 6 は、クワッド プロセッサの WCF と WSE 2.0 のスループットを比較したものです。 これらの結果は、単一プロセッサ シナリオで WSE 経由で WCF によって実現されるパフォーマンス向上と似ています。 WCF は、完全なメッセージ セキュリティを備えた WSE の 4 倍近く高速です。

図 5

図 5 は、WCF のメッセージをセキュリティで保護するための別のメカニズムである、メッセージ資格情報を使用したトランスポート セキュリティのパフォーマンスも示しています。 この構成では、トランスポート レベルのセキュリティ (HTTPS) とメッセージ レベルの資格情報 (SOAP メッセージ内の資格情報など) が組み合わされます。 これを展開するために、WCF (メッセージ資格情報) ワークロードでは BasicHttpBinding を使用しています。 このグラフは、WCF (メッセージ資格情報) の単一プロセッサ シナリオのパフォーマンスが、それぞれ 1、10、10、100 のメッセージに対して 129%、166%、277% の WS Security を使用した WCF よりも優れていることを示しています。 WCF (メッセージ資格情報) のクワッド プロセッサ シナリオの対応する数値はさらに向上しており、単一プロセッサ シナリオの WCF (メッセージ資格情報) を使用して、それぞれ 1、10、100 のメッセージに対して 126%、156%、248% の改善を示しています。

グラフからわかるように、メッセージ資格情報を使用したトランスポート セキュリティは、リッチ メッセージ レベルの資格情報を引き続き許可しながら、パフォーマンスを向上させます。 メッセージ レベルの資格情報には、タイムスタンプ処理、正規化、署名処理が含まれます。 メッセージ保護 (署名、暗号化、再生検出、その他の保護メカニズム) は、個々のメッセージ境界の下のトランスポート バイト ストリーム レベルで引き続き実行されます。 WS-Security ヘッダーがありますが、タイムスタンプ、セキュリティ トークン、およびタイムスタンプ経由でそのセキュリティ トークンを使用する署名のみが含まれています。 一方、WCF が完全な WS-Security を使用する場合、メッセージ保護はメッセージ レベルの変換として行われ、署名と暗号化はヘッダーと本文の XML フラグメントに対して行われます。 また、WS-Security ヘッダーには、必要なすべてのセキュリティ メタデータが XML コンストラクトとして含まれています。 この追加の XML 対応のセキュリティ処理と、セキュリティ ヘッダーのサイズが大きいほど、パフォーマンスの違いが考慮されます。 この WCF 設定を使用する特定のアプリケーションで使用できるパフォーマンス機能とセキュリティ機能のトレードオフを考慮する必要があります。

図 6

3.3 .NET Enterprise Services (ES)

このセクションでは、2 つの異なるサービス操作シグネチャとペイロードを使用して、Enterprise Services (ES) のスループットを WCF と比較します。 これらは、 プリミティブ メッセージおよび 順序 メッセージと呼ばれます。 プリミティブ メッセージはプリミティブ型であり、これにより ES は高速シリアル化パスを実行できます。 注文メッセージは、オンラインで書籍の注文を模倣する一般的なシナリオであり、約 512 バイトです。 これらの比較には、要求/応答メッセージ交換パターンが使用されます。

プリミティブ ペイロードのシグネチャは次のとおりです。

string TransferFunds(int source, int destination, Decimal amount);

Here the service just returns a string "successful" or "failure". 

For the order message the following code service is used:

static public ProductInfo CreateProductInfo(int count)
{
            ProductInfo productInfo = new ProductInfo();

            productInfo.TotalResults = count.ToString();
            productInfo.TotalPages = "1";
            productInfo.ListName = "Books";
            productInfo.Details = new Details[count];
            for (int x = 0; x < count; x++)
            {
                productInfo.Details[x] = GetDetail();
            }
            return productInfo;
}

static Details GetDetail()
{
      Details details = new Details();
      details.Url = 
"http://www.abcd.com/exec/obidos/ASIN/043935806X/qid=1093918995/sr=k
a-1/ref=pd_ka_1/103-9470301-1623821";
      details.Asin = "043935806X";
      details.ProductName = "Any Book Available";
      details.Catalog = "Books";
      details.ReleaseDate = "07/01/2003";
      details.Manufacturer = "Scholastic";
      details.Distributor = "Scholastic";
      details.ImageUrlSmall = 
"http://images.abcd.com/images/P/043935806X.01._PE60_PI_SZZZZZZZ_.jpg";
      details.ImageUrlMedium = 
"http://images.abcd.com/images/P/043935806X.01._PE60_PI_MZZZZZZZ_.jpg";
      details.ImageUrlLarge = 
"http://images.abcd.com/images/P/043935806X.01._PE60_PI_LMZZZZZZZ_.jpg";
      details.ListPrice = "29.99";
      details.OurPrice = "12.00";
      details.UsedPrice = "3.95";
      details.Isbn = "043935806X";
      details.MpaaRating = "";
      details.EsrbRating = "";
      details.Availability = "Usually ships within 24 hours";
      return details;
}

これらのシナリオでは、WCF サービスはセルフホステッドであり、 NetTcpBinding を使用します。

メモ TCP サービスをホストするために Windows Vista に付属している IIS 7.0 を使用できます。 この場合、達成されるパフォーマンスはセルフホステッド ケースよりもわずかに少なくなります。

3.3.1 Self-Hosted 要求/応答 TCP アプリケーション

このセクションでは、セキュリティなしで前述した 2 つのペイロードについて WCF と ES を比較します。 図 7 は、ES の方が高速な場合もあれば、WCF の方が高速な場合もあることを示しています。 高速シリアライザーを使用できる (整数のような少数のプリミティブ型の場合もある) 場合、ES のパフォーマンスはプリミティブ メッセージ ペイロードに対して 21% 向上しますが、WCF は順序メッセージ ペイロードに対して 149% 上回ります。

図 8 は、クワッド プロセッサでの同じベンチマークとペイロードの比較を示しています。 WCF は ES よりもスケーリングが優れているため、ES が高速シリアル化パスを利用できる場合でも、WCF はプリミティブ メッセージの ES よりも 7% 高速です。 注文メッセージの場合、WCF は ES より 104% 高速です。

図 7

図 8

3.3.2 セキュリティで保護された要求/応答 TCP アプリケーションのSelf-Hosted

このセクションでは、セキュリティが有効になっている前のセクション (セクション 3.3.1) と同じメッセージ読み込みについて、WCF と ES のパフォーマンスを比較します。 具体的には、トランスポート レベルの SSL セキュリティが採用され、承認にロールの原則 ASP.NET 使用されます。 図 9 は、uni プロセッサでの ES のパフォーマンスが、プリミティブ メッセージの種類に対して WCF よりも 24% 高速であるのに対し、順序メッセージの種類の場合、WCF は ES より 69% 高速であることを示しています。

図 10 は、クワッド プロセッサの場合、プリミティブ メッセージの種類では ES が WCF よりも 16% 優れていること、および注文メッセージの種類 WCF の方が 37% 高速であることを示しています。

図 9

図 10

3.3.3 Secure Transacted Request/Reply TCP アプリケーション

前の 2 つのセクション (セクション 3.3.1 と 3.3.2) では、サービスによって行われた作業は、クライアントに返されたオブジェクトを作成する以外にほとんど行われませんでした。 このセクションでは、実装されているサービスがデータベース トランザクションを使用する場合、WCF のスループットを .NET ES と比較します。 使用されるトランザクションはフローされず、サービス内で作成および使用されることに注意してください。 このシナリオの目的は、実質的なサービスの実装が、インフラストラクチャのデプロイに使用されるテクノロジに依存せず、インフラストラクチャのコストを占めるかどうかを示することです。 したがって、比較は単一プロセス シナリオに対してのみ行われ、プリミティブ メッセージの種類に対してのみ行われます。

図 11 では、WCF のパフォーマンスは、プリミティブ メッセージ ペイロードの .NET Enterprise Service のパフォーマンスと比較されています。 予想どおり、トランザクションが使用されているため、このシナリオのスループットは前のシナリオよりも大幅に低くなります。 また、予想どおり、2 つのテクノロジのパフォーマンスは、WCF のパフォーマンスが若干向上した場合とほぼ同じです。

図 11

3.4 .NET リモート処理

このセクションでは、同じコンピューター上のプロセス間で通信が必要な場合の WCF と .NET リモート処理のパフォーマンスを比較します。 3 つの異なるサイズのペイロード。この比較では、各バイト配列が使用されます。 次のインターフェイスは、サービス操作のシグネチャを示しています。

public interface IRemoteObject 
{
        [OperationContract]
        byte [] GetRBytes(int NumBytes);
}

返されるメッセージ ペイロードのサイズは、128 バイト、4k、256k のデータの "NumBytes" によって決まります。 NetNamedPipeBinding は、このシナリオではセキュリティなしで使用されます。

3.4.1 名前付きパイプ アプリケーションの要求/応答

プロセス間の名前付きパイプは、メッセージ交換プロトコルとして要求/応答と共にトランスポート プロトコルとして使用されます。 図 12 に示すように、WCF は、それぞれ 128 バイトと 4k バイトのメッセージ ペイロードに対して .NET リモート処理を 29%、30% 上回っています。 ペイロードのサイズが大きくなると、テクノロジのパフォーマンスが収束し、256k バイト配列のパフォーマンスはほぼ同じになります。

図13では、クワッドプロセッサの対応するデータが示されている。 WCF のスループットは、それぞれ 128 バイト、4k バイト、256k バイトのメッセージ ペイロードの場合、38%、18%、28% の方が優れています。

図 12

図 13

4. 結論

ASP.NET Web サービス、WSE、.NET Enterprise Services、.NET リモート処理を使用して作成された分散アプリケーションを WCF に移行する場合、パフォーマンスは、少なくとも他の既存の Microsoft 分散通信テクノロジと同等です。 ほとんどの場合、他の既存のテクノロジよりも WCF のパフォーマンスが大幅に向上します。 WCF のもう 1 つの重要な特性は、スループットパフォーマンスが本質的にユニプロセッサからクワッドプロセッサにスケーラブルであるということです。

結果を要約すると、WCF は 25% (ASP.NET Web サービスよりも 50% 高速で、.NET リモート処理よりも約 25% 高速です。 .NET Enterprise Service との比較は負荷に依存します。1 つのケースでは WCF の方が 100% 近く高速ですが、別のシナリオでは 25% 近く遅くなります。 WSE 2.0/3.0 実装の場合、それらを WCF に移行すると、明らかにほぼ 4 倍のパフォーマンス向上が得られます。

5. 付録

5.1 バインディングの説明

システム提供のバインディングは、クライアントとサービスが相互に通信するために必要なトランスポート プロトコル、エンコード、およびセキュリティの詳細を指定するために使用されます。 システム提供の WCF バインディングを表に示します。 バインディングの詳細については、WCF ドキュメントを参照してください。 WCF では、独自のカスタム バインドを定義することもできます。

バインド 説明
BasicHttpBinding ASMX ベースのサービスなどのWS-Basic プロファイル準拠 Web サービスとの通信に適したバインディング。 このバインディングでは、トランスポートとして HTTP を使用し、メッセージ エンコードとして Text/XML を使用します。
WSHttpBinding 二重のサービス コントラクト以外に適した、セキュリティで保護された相互操作可能なバインディング。
WSDualHttpBinding 二重のサービス コントラクト、または SOAP 中継局を介しての通信に適した、セキュリティで保護された相互操作可能なバインディング。
WSFederationHttpBinding WS-Federation プロトコルをサポートする、セキュリティで保護された相互操作可能なバインディングで、フェデレーションに属す組織のユーザーを効率的に認証、および承認することができます。
NetTcpBinding WCF アプリケーション間のマシン間通信に適した、セキュリティで保護された最適化されたバインディング
NetNamedPipeBinding WCF アプリケーション間でのコンピューター上の通信に適した、セキュリティで保護され、信頼できる最適化されたバインド。
NetMsmqBinding WCF アプリケーション間でのコンピューター間通信に適した、キューに置かれたバインド。
NetPeerTcpBinding セキュリティで保護された、複数のコンピューター通信を可能にするバインディング。
MsmqIntegrationBinding WCF アプリケーションと既存の MSMQ アプリケーション間のマシン間通信に適したバインディング。

5.2 パフォーマンス テスト マシンの構成

図 14

図 14 は、1 台のサーバーと 2 つの 1 Gbps イーサネット ネットワーク インターフェイスで接続された 4 台のクライアント マシンで使用されるマシン構成を示しています。 サーバーは、Windows Server 2003 SP1 を実行するクワッド プロセッサ AMD 64 2.2 GHz x86 マシンです。 各クライアント マシンは、サーバーと同じオペレーティング システムを実行するデュアル プロセッサ AMD 64 2.2 GHz x86 マシンです。 システムの CPU 利用状況はほぼ 100% で推移します。 ホストに必要なすべてのシナリオは、インターネット インフォメーション サービス (IIS) 6.0 サーバーを使用して行われました。 単一プロセッサのシナリオでは、サーバーは単一のプロセッサ コンピューターとして起動されます。

6. 参考資料

  1. Windows Communications Foundation Services の構築の概要、Clemens Vasters。 2005 年 9 月。
  2. Windows Communication Foundation アーキテクチャの概要、Microsoft Corporation、2006 年 3 月。
  3. Basic セキュリティ プロファイル バージョン 1.0、Web サービス相互運用性組織、2006 年 8 月。
  4. Web サービス セキュリティ 1.1、OASIS、2006 年 2 月。

7. 著者について

Saurabh Gupta は、Microsoft の Windows Communication Foundation チームのプログラム マネージャーであり、テクノロジのパフォーマンス、信頼性、ストレスの問題に関与しています。

8. 確認

次の寄稿者および校閲者の方々のご協力に感謝します。

  • Mark Fussell、Microsoft Corporation
  • Bob Dimpsey、Microsoft Corporation
  • Ryszard Kwiecinski、Microsoft Corporation
  • Mauro Ottaviani、Microsoft Corporation