ホーム ライブラリ ラーニング ダウンロード サポート コミュニティ
サインイン | United States - English | |
このトピックはまだ評価されていません - このトピックを評価する

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

Saurabh Gupta
Program Manager
Microsoft Corporation

February 2007
日本語版最終更新日 2007 年 6 月 28 日

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

目次

1. はじめに
2. 目的
3. 比較
3.1 ASP .NET Web サービス (ASMX)
3.1.1 IIS でホストされた相互運用可能な Basic Profile 1.0 Web サービス
3.1.2 IIS でホストされた、相互運用可能な Basic Profile 1.0 Web サービス (トランスポート セキュリティを使用した場合)
3.2 Web Services Enhancements (WSE)
3.2.1 IIS でホストされた相互運用可能な Web サービス (WS-Security を使用した場合)
3.3 .NET Enterprise Services (ES)
3.3.1 自己ホストされた要求/応答 TCP アプリケーション
3.3.2 自己ホストされた、セキュリティで保護された要求/応答 TCP アプリケーション
3.3.3 セキュリティで保護された要求/応答 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 の標準バインディングについては、「Introduction to Building Windows Communication Foundation Services」(英語) を参照してください。

2. 目的

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

  • ASP.NET Web サービス (ASMX)
  • Web Services Enhancements (WSE)
  • .NET Enterprise Services (ES)
  • .NET リモート処理

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

3. 比較

この記事で紹介するデータはすべて、同じハードウェア構成を使用して収集したものです。シングル プロセッサまたはクワッド (4) プロセッサで構成された 1 台のサーバーを稼動させるために、双方向のクライアント システムを 4 台使用しました。どのシナリオに関してもネットワークがボトルネックにならないようにするため、2 GB のカードを 2 枚使用しました。使用したトポロジの詳細については、図 14 を参照してください。

クライアント システムで使用したクライアント プロセスの数は、サーバーの CPU 使用率をほぼ 100% に保つのに十分な数でした。この記事で紹介するデータは、集中的に実行した複数回の結果の平均を反映しています。また、すべてのデータの再現性が高く、維持しやすいものであるように気を配りました。

この記事での比較はすべてスループットの比較なので、達成値が大きいほど、優れているということになります。また、すべてのグラフでは、バーが高いほどパフォーマンスが優れていることを表します。

この記事では、.NET 分散通信テクノロジの、サーバーのスループットに重点を置いて説明します。スループットは、これらのテクノロジが 1 秒間に維持できる処理数で定義されています。1 つの処理とは、1 つの要求/応答メッセージで、サービスによって行われる処理はほとんどありません。冒頭で述べたことの繰り返しになりますが、適切に構築された SOA ソリューションでは、ビジネス ロジックによってサービスのコストが左右されると思われます。これは非常に重要なことです。サービスのビジネス ロジック処理を省くことによって、メッセージング インフラストラクチャのコストだけを測定することができます。

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

3.1 ASP .NET Web サービス (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 でホストされた相互運用可能な Basic Profile 1.0 Web サービス

ここでは、IIS 6.0 でホストされている場合の ASMX と WCF のパフォーマンスを比較します。どちらの場合も、セキュリティは使用していません。使用する WCF バインディングは BasicHttpBinding です。この標準バインディングでは、トランスポート プロトコルとして HTTP を使用します。Basic Profile の仕様については、http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html (英語) を参照してください。.NET Framework 2.0 の一部である ASP.NET 2.0 では、Basic Profile への準拠を保証するために CLR 属性が用意されています。WCF については、BasicHttpBinding を使用すると同程度の保証が得られます。

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

図 2 のグラフは、図 1 と同じシナリオをクワッド プロセッサで実行した場合の、WCF と ASMX のスループットの比較結果を示しています。WCF のスループット パフォーマンスは、メッセージに 1 個、10 個、100 個のオブジェクトが含まれる場合に対してそれぞれ 19%、21%、36% だけ、ASMX よりも優れています。2 つの構成で使用したソフトウェアは同じで、サーバーでは 1 つのサービスを公開しました。これらの 2 つのグラフのデータを比較すると、テクノロジ固有のスケーラビリティを知ることができます。

Bb310550.Bb310550_wcfperform01(ja-jp,MSDN.10).gif

図 1


Bb310550.Bb310550_wcfperform02(ja-jp,MSDN.10).gif

図 2


3.1.2 IIS でホストされた相互運用可能な Basic Profile 1.0 Web サービス (トランスポート セキュリティを使用した場合)

ここでは、HTTPS を使用して処理を行った場合の、WCF のパフォーマンスと ASMX のパフォーマンスを比較します。WCF ではこのシナリオに BasicHttpBinding を使用します。図 3 から、トランスポート レベルのセキュリティを使用する場合に WCF のパフォーマンスが ASMX より優れていることがわかります。メッセージに 1 個、10 個、100 個のオブジェクトが含まれる場合に対してそれぞれ 16%、18%、26% だけ、WCF は ASMX よりもパフォーマンスが優れています。

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

Bb310550.Bb310550_wcfperform03(ja-jp,MSDN.10).gif

図 3


Bb310550.Bb310550_wcfperform04(ja-jp,MSDN.10).gif

図 4


3.2 Web Services Enhancements (WSE)

ここでは、WCF のスループットを Web Services Enhancements のスループットと比較します。ここでは WSE 2.0 と比較していますが、このペイロードに関して WSE 2.0 と 3.0 のパフォーマンスはほぼ同じです。このシナリオで使用したメソッド シグネチャとペイロードは、ASMX シナリオ (3.1 参照) で使用したものと同じです。

3.2.1 IIS でホストされた相互運用可能な Web サービス (WS-Security を使用した場合)

ここでは、X. 509 証明書をセキュリティ資格情報として使用するメッセージ レベルのセキュリティを使います。WCF では WSHttpBinding を使用します。WSHttpBinding には WS-Security 1.1 の仕様が実装されています。使用するトランスポート プロトコルは 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 倍近く高速になります。

Bb310550.Bb310550_wcfperform05(ja-jp,MSDN.10).gif

図 5


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

グラフからわかるように、メッセージ資格情報とトランスポート セキュリティの併用によって、メッセージ レベルでさまざまな資格情報を使用できる状態を維持しながら、パフォーマンスが向上します。メッセージ レベルの資格情報には、タイムスタンプ処理、標準化、および署名処理が含まれます。メッセージ保護 (署名、暗号化、リプレイ検出などの保護メカニズム) は依然として、個々のメッセージ境界の下の、転送バイト ストリーム レベルで行われます。WS-Security ヘッダーがありますが、このヘッダーに含まれるのは、タイムスタンプ、セキュリティ トークン、および、そのセキュリティ トークンをタイムスタンプに対して使用する署名のみです。一方、WCF で 完全な WS-Security を使用する場合は、メッセージ保護はメッセージ レベルの変換として行われ、署名と暗号化はヘッダーと本文の XML フラグメントを通じて行われます。また、WS-Security ヘッダーには、すべての必要なセキュリティ メタデータが XML 構造として含まれています。この XML 対応のセキュリティ処理が追加されたこととセキュリティ ヘッダーのサイズが大きくなったことがパフォーマンスの違いの原因となっています。この WCF 設定を使用するアプリケーションで使用可能なセキュリティ機能とパフォーマンスの間のトレードオフを考慮する必要があります。

Bb310550.Bb310550_wcfperform06(ja-jp,MSDN.10).gif


図 6


3.3 .NET Enterprise Services (ES)

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

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

コピー 
string TransferFunds(int source, int destination, Decimal amount);

ここでは、サービスはただ "成功" または "失敗" の文字列を返します。注文メッセージでは、次のコード サービスを使用します。

コピー 
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 自己ホストされた要求/応答 TCP アプリケーション

ここでは、既に説明した 2 つのペイロードに関して、セキュリティを使用しない場合の WCF と ES の比較を行います。図 7 から、ES の方が高速な場合もあれば、WCF の方が高速な場合もあることがわかります。高速なシリアライザを使用できる (おそらく、整数など一握りのプリミティブ型の場合) プリミティブ メッセージのペイロードに関しては、ES のパフォーマンスが WCF よりも 21% 優れていますが、注文メッセージのペイロードに関しては WCF が ES よりも 149% 優れています。

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

Bb310550.Bb310550_wcfperform07(ja-jp,MSDN.10).gif

図 7


Bb310550.Bb310550_wcfperform08(ja-jp,MSDN.10).gif

図 8


3.3.2 自己ホストされたセキュリティで保護された要求/応答 TCP アプリケーション

ここでは、前の項 (3.3.1) と同じメッセージ ペイロードに関して、セキュリティを有効にした場合の、WCF と ES のパフォーマンスを比較します。具体的には、トランスポート レベルの SSL セキュリティを使用し、承認には ASP.NET のロール原則を使用しています。図 9 から、シングル プロセッサでは、プリミティブ メッセージ タイプに関しては ES のパフォーマンスが WCF よりも 24% 高速であり、注文メッセージ タイプに関しては WCF が ES よりも 69% 高速であることがわかります。

図 10 から、クワッド プロセッサでは、プリミティブ メッセージ タイプに関しては ES が WCF よりも 16% 高速であり、注文メッセージ タイプに関しては WCF の方が 37% 高速であることがわかります。

Bb310550.Bb310550_wcfperform09(ja-jp,MSDN.10).gif


図 9

Bb310550.Bb310550_wcfperform10(ja-jp,MSDN.10).gif

図 10


3.3.3 セキュリティで保護された要求/応答 TCP アプリケーション (トランザクションを使用した場合)

前の 2 つの項 (3.3.1、3.3.2) では、サービスで行った作業はクライアントに返すオブジェクトの作成だけでした。ここでは、実装するサービスでデータベース トランザクションを使用する場合の、WCF のスループットを .NET ES のスループットと比較します。使用するトランザクションはフローせずサービス内で作成および使用しています。このシナリオの目的は、展開に使用するテクノロジにかかわらず、実際のサービス実装によってインフラストラクチャのコストが左右されることを示すことです。そのため、シングル プロセッサ シナリオのプリミティブ メッセージ タイプに関してだけ、比較を行いました。

図 11 では、プリミティブ メッセージのペイロードに関して、WCF のパフォーマンスを .NET Enterprise Services のパフォーマンスと比較しています。トランザクションを使用しているため、このシナリオのスループットは予想どおり、1 つ前のシナリオに比べて大幅に低くなっています。また、これも予想どおりですが、2 つのテクノロジのパフォーマンスはほぼ同じで、WCF のパフォーマンスの方が少しだけ優れています。

Bb310550.Bb310550_wcfperform11(ja-jp,MSDN.10).gif

図 11


3.4 .NET リモート処理

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

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

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

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

プロセス間の名前付きパイプをトランスポート プロトコルとして使用し、要求/応答をメッセージ交換プロトコルとして使用します。図 12 からわかるように、メッセージ ペイロードが 128 バイト、4 キロバイトの場合に対してそれぞれ、29%、30% だけ、WCF は .NET リモート処理よりもパフォーマンスが優れています。ペイロードのサイズが大きくなればなるほど、2 つのテクノロジのパフォーマンスは近づくので、256 キロバイトの配列に関してはパフォーマンスはほぼ同じです。

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

Bb310550.Bb310550_wcfperform12(ja-jp,MSDN.10).gif

図 12


Bb310550.Bb310550_wcfperform13(ja-jp,MSDN.10).gif

図 13


4. まとめ

ASP.NET Web サービス、WSE、.NET Enterprise Services、.NET リモート処理を使用して記述された分散アプリケーションを WCF に移行すると、移行後のパフォーマンスは少なくとも他の既存のマイクロソフトの分散通信テクノロジに見合うものになります。ほとんどの場合、WCF の方が他の既存のテクノロジよりも大幅にパフォーマンスが優れています。WCF のもう 1 つの重要な特性は、スループット パフォーマンスは、シングル プロセッサからクワッド プロセッサに変更することで本質的に拡張可能であることです。

結果を要約すると、WCF は ASP.NET Web サービス よりも 25 ～ 50% 高速で、.NET リモート処理よりも約 25% 高速です。.NET Enterprise Services との比較に関しては、負荷に左右され、WCF の方が 100% 近く高速な場合もあれば 25% 近く低速な場合もあります。パフォーマンスが最も大幅に向上するのは明らかに WSE 2.0/3.0 の実装を WCF に移行する場合で、その向上は約 4 倍にもなります。

5. 付録

5.1 バインディングの説明

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

バインディング説明
BasicHttpBindingWS-Basic Profile 準拠の Web サービス (ASMX ベースのサービスなど) との通信に適したバインディング。このバインディングではトランスポート プロトコルとして HTTP が使用され、メッセージのエンコードとして Text/XML が使用されます。
WSHttpBinding二重でないサービス コントラクトに適した、セキュリティで保護され相互運用可能なバインディング。
WSDualHttpBinding二重のサービス コントラクトまたは SOAP 仲介者を使用した通信に適した、セキュリティで保護され相互運用可能なバインディング。
WSFederationHttpBindingWS-Federation プロトコルをサポートし、フェデレーション内の組織での効率的なユーザーの認証と承認を可能にする、セキュリティで保護され相互運用可能なバインディング。
NetTcpBindingWCF アプリケーション間のコンピュータ間通信に適した、セキュリティで保護され最適化されたバインディング。
NetNamedPipeBindingWCF アプリケーション間の 1 台のコンピュータ上の通信に適した、セキュリティで保護され、信頼性があり、最適化されたバインディング。
NetMsmqBindingWCF アプリケーション間のコンピュータ間通信に適した、キューに登録されたバインディング。
NetPeerTcpBinding複数のマシン間のセキュリティで保護された通信を可能にするバインディング。
MsmqIntegrationBindingWCF アプリケーションと既存の MSMQ アプリケーション間のコンピュータ間通信に適したバインディング。

5.2 パフォーマンス テストのコンピュータ構成

Bb310550.Bb310550_wcfperform14(ja-jp,MSDN.10).gif

図 14


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

6. 参考資料

  1. Introduction to Building Windows Communications Foundation Services (英語)、Clemens Vasters、2005 年 9 月
  2. Windows Communication Foundation Architecture Overview (英語)、Microsoft Corporation、2006 年 3 月
  3. Basic Security Profile Version 1.0 (英語)、Web Services Interoperability Organization、2006 年 8 月
  4. Web Services Security 1.1、OASIS、2006 年 2 月

7. 著者について

Saurabh Gupta はマイクロソフトの Windows Communication Foundation チームのプログラム マネージャで、このテクノロジのパフォーマンス、信頼性、および負荷の問題に携わっています。

8. 謝辞

以下の寄稿者とレビューアの尽力に感謝します。

  • Mark Fussell、Microsoft Corporation
  • Bob Dimpsey、Microsoft Corporation
  • Ryszard Kwiecinski、Microsoft Corporation
  • Mauro Ottaviani、Microsoft Corporation
この情報は役に立ちましたか。
(残り 1500 文字)