.NET 2.0 および IBM Websphere 6.0: Web アプリケーション サーバーのパフォーマンスの比較

November 2005

日本語版最終更新日 2006 年 9 月 7 日

この記事で参照されている ソース コード をダウンロードする。

PDF フォーマットで この記事 (英語) をダウンロードする。

概要

この記事の目的は、2 つの Web アプリケーション サーバーの比較を示すことにあります。1 つは、Windows Server 2003 で稼働する Microsoft .NET Framework 2.0 であり、もう 1 つは、最新のリリースの IBM WebSphere Application Server のバージョン 6.0.2.3 です。 2005 年 10 月からの IDC の調査によれば、世界各国において開発中の主幹業務のアプリケーション プロジェクトのおよそ 78% で、アプリケーション サーバーが使用されています。その調査では IDC はまた、.NET および Windows Server 2003 の組み合わせが、主幹業務のアプリケーションに対して現在最もよく使用されているアプリケーション サーバーであることも明らかにしました。つまり、IBM WebSphere の 12% と比較して .NET/Windows サーバーの使用率は 37% であるという点で、IBM WebSphere の使用率をしのいでいます。この調査結果の詳細は、 IDC Research 2005 Mission Critical Survey (Oct 2005) (英語)を参照してください。

この記事では、この 2 つのアプリケーション サーバーのパフォーマンスを比較した新規のベンチマーク結果を紹介します。このベンチマークは、WebSphere 6 に付属しているプライマリ サンプル アプリケーションである PlantsByWebSphere サンプル アプリケーションをベースにしています。このベンチマークの場合、機能的にそれと同等の .NET アプリケーション (DotNetGardens) を実装し、IBM アプリケーション コード ベースに対してパフォーマンス上のいくつかの最適化も実施しました。それは、データ駆動の Web アプリケーションのパフォーマンスを公平に比較するためでした。

完全開示要綱

このベンチマークの完全なソース コード、すべてのテスト スクリプト、およびテスト手順は、オンラインで手に入れることができます。誰でも、テスト対象のすべての実装内容の実際のコードをダウンロードして表示することができます。また、ベンチマークをさらに独自に実行して、結果をご自身で検証することができます。ベンチマーク キットは、https://msdn.microsoft.com/en-us/vs2005/aa700836.aspx (英語) からダウンロードできます。

テスト対象の実装内容

以下に、テスト対象の実装内容を表で示してあります (すべて、まったく同じハードウェア上でテストされました)。将来的には、間もなくリリースされる新しい Microsoft SQL server の JDBC ドライバを使用して SQL Server2005 と連係して稼働する WebSphere EJB 実装も公開する予定になっています。

結果の概要

結果を見ると、SQL Server 2005 に対して実行するベンチマーク アプリケーションを .NET 2.0/Windows Server 2003 で実装した場合、Java EJB ベースの WebSphere 6.0.2.3/RedHat Linux 実装より 183% パフォーマンスが優れています。またこの結果では、テスト対象のすべての実装において WebSphere 6 よりも .NET のほうが、価格/パフォーマンスの比率の点ではるかに勝っていることも示されています。この記事では、Java アプリケーションは、SQL Server 2005 への接続時にパフォーマンスが向上することも示します。つまり、間もなくリリースされる Microsoft SQL Server 2005 の JDBC ドライバを使用したときの PlantsByWebSphere JDBC ベースのアプリケーションは、Oracle 10G に接続している同等のアプリケーションのパフォーマンスとほぼ同等であるということです。

(クリックすると、拡大表示されます)

詳細な内訳は付録を参照してください。

ベンチマーク

IBM 側のコーディングの最良事例に準拠したアプリケーションを使用して、公平かつ細大漏らさぬやり方でベンチマークを実行するために、比較の基盤として PlantsByWebSphere サンプル アプリケーションを選択しました。この Java アプリケーションを開発したのは IBM だからです。 PlantsByWebSphere サンプル アプリケーションは、EJB ベースの開発ガイドラインに従って IBM によって作成された J2EE ベースのアプリケーションです。これは、プライマリ J2EE サンプル アプリケーションとしてどの WebSphere 6.0 にも付属しています。このアプリケーションは、J2EE のきわめて通常の設計内容を使用しています。たとえば、コンテナ管理パーシスタンス (CMP) を使用してデータベースにアクセスするエンティティ Bean をラップするステートレス セッション Bean ファサードなどの、Enterprise Java Beans を使用しています。ユーザー インターフェイスは Web ベースですが、UI レイヤの中心的アーキテクチャ要素として、Java Server Pages および サーブレットに依存します。 IBM アプリケーションはモデル オブジェクトを使用して、データベース情報を表します。そのモデル オブジェクトが EJB と UI レイヤの間でやりとりされることで、アプリケーションの UI、ビジネス、およびデータの各レイヤが明確に分離した状態に保たれます。

PlantsByWebSphere アプリケーションに対して適用した最適化

このベンチマークでの 2 つのプラットフォームのスケーラビリティおよびパフォーマンスを包括的に査定するために、IBM によって WebSphere に添付されている PlantsByWebSphere サンプル アプリケーションに対して、いくつかの最適化および追加を行いました。

1. 業務クラスのデータベースの使用のための変換　オリジナルのサンプル アプリケーションは、シンプルな IBM CloudScape スターター データベースを使用して動作するためのアプリケーションであって、大規模な同時ユーザー負荷を処理するのに適したデータベースではありません。このベンチマークは、データベースのスループットの測定には重点を置いていませんが、開発クラスのデータベースの場合、パフォーマンス テスト時にボトルネックを生じるおそれがあります。そのため、Oracle 10G (Release 2) シン JDBC ドライバを介して、専用サーバー上で稼働する Oracle 10G エンタープライズ データベース と連係して稼働するように、PlantsByWebSphere EJB アプリケーションを移植しました。 DotNetGardens の実装は、この同じデータベースと連係して稼働しますが、これは SQL Server 2005 とも連係して稼働するように設計されています。
   
   
2. イメージ機能の最適化　 IBM 実装の場合、商品イメージはデータベースに保管され、各要求ごとにイメージ サーブレットを使用してそのイメージが取り出されてから、ブラウザ内でレンダリングされます。アプリケーションのパフォーマンスを改善するために、イメージをデータの塊としてデータベースに保管するのではなく、URL だけをデータベースに保管するようにアプリケーションを変更しました。そして、実際の商品イメージは、Web サーバー (WebSphere の場合は IBM HTTP Server、.NET の場合は IIS 6.0) によって直接提供されるようにしました。これによって、テスト対象のすべての実装のパフォーマンスに対する劇的な効果が生じました。イメージ サーブレット (およびそれに関連した asp.net イメージ提供ページ) のパフォーマンスの詳細は、CachePerf: Examining the Impact of 64-bit Extended Memory Addressability on .NET and WebSphere Middle Tier Applications (英語) というタイトルのベンチマーク関連資料を参照してください。
   
   
3. いくつかのサーブレットをリファクタリングして 1 つにまとめる　ユーザーが商品データ (検索結果、カテゴリの参照、商品の詳細) をキャッシュするときに簡単にサーブレット キャッシングを使用できるようにするために、いくつかのアプリケーション関数が Category サーブレットに統合されました。すなわち、該当サーブレットに対してサーブレット キャッシングを有効にすると、アプリケーションの各部分でその利点を活用できるようになります。ただし、ベンチマークの場合、どの実装 (.NET あるいは WebSphere) でもキャッシングを使用しなかったことに注意してください。それは、アプリケーション ロジックのかたまりであるアプリケーションのデータ アクセス部分のパフォーマンスを特にテストしたいと考えたからです。
   
   
4. ローカル インターフェイスの使用のための EJB の修正　パフォーマンス テストは、EJB および Web アプリケーションが共存する単一のアプリケーション サーバーに対して実施されるので、リモート インターフェイスの代わりにすべてローカル インターフェイスを使用するように EJB ベースの実装を変更し、JSP Web 層からの EJB の呼び出しが最大限に高速化されるようにしました。
   
   
5. JNDI の検索およびローカル ホーム インターフェイスのキャッシングの導入　これは、IBM WebSphere 6.0 の Performance and Scalability Redbook で公開されている IBM 社の最良事例ガイダンスに沿ったものです。 JNDI のキャッシュ付きのローカル ホーム インターフェイスの検索は、最初のサーブレット初期化 (init) メソッドでのみ実行されます。
   
   
6. 検索機能の追加　任意の e-commerce スタイルの Web アプリケーションとの通常のユーザー対話である商品在庫データベースのランダム検索をテストできるように、この機能がアプリケーションに追加されました。
   
   
7. 検索結果のページ ナビゲーションの追加　 IBM サンプル アプリケーションは、レコード セットのページ ナビゲーションをサポートしていないので、この機能が追加されました。
   
   
8. EJB の代わりに JDBC レコード セットを使用するための新規の検索機能の修正　 EJB 実装の場合、JDBC と EJB の直接的な比較を使用するように検索結果ページを変更し、追加した新商品名の検索機能のパフォーマンスを向上しました。 EJBSQL Locate コマンドを使用したワイルドカード検索の実行時に EJB を使用すると、きわめて遅くなるので、その代わりに JDBC を使用することによって、EJB ベースの PlantsByWebSphere サンプル アプリケーションでの新規の検索ページのパフォーマンスを大幅に改善することができました。テスト対象の Oracle10G/EJB 実装での他のすべての EJB ロジックは未変更のままになっています。
   
   
9. アプリケーション内のフレームの使用を排除しました。それによって、広範囲にわたる負荷テスト ツールを使用して、顧客がより簡単にアプリケーションのベンチマーク測定を行えるようになっています。

上記のような変更を加えたのは、ユーザーが実稼働環境で実際に WebSphere Application Server にアプリケーションをデプロイするときに使用すると思われる設計をより忠実に反映するようにするためです。そのような設計上の変更はすべて、J2EE アプリケーションに対する一般的な設計ガイドラインでサポートされている変更内容です。これらの変更のいずれもが、修正後のアプリケーション設計におけるパフォーマンスの向上や、あるいはより優れたさらに実務的な機能へとつながりました。パフォーマンス関連のすべての変更がもたらしたアプリケーションの実際のパフォーマンスに対する総合的な効果は、かなり絶大なものと言えます。

最後に、上記の変更に加えて、新たに代替の EJB を使用しない実装 も構成しました。 J2EE 関係者の間では、全体的なパフォーマンスとスケーラビリティ以外に、アプリケーションの複雑さという点で、EJB を望ましくないとみなすべきかどうかで意見が分かれています。一部の関係者 (IBM も含む) が、データ駆動型 Web アプリケーションを構築するには EJB が最適のアーキテクチャであるとしているのに対して、アプリケーションのパフォーマンスの全体像を描くために、PlantsByWebSphere アプリケーションの第 2 の実装を作成しました。その実装では EJB をまったく使用していません (セッション Bean もエンティティ Bean も) が、オリジナルの IBM EJB 実装および DotNetGardens アプリケーションと機能的にまったく同等の実装です。この実装では、その代わりに JDBC ロジックのみを使用して、データベースにアクセスします。 JDBC ロジックは別個のデータ アクセス レイヤ内にカプセル化されています (ADO.NET 実装に非常によく似ています)。これは、オリジナルの EJB ベースの PlantsByWebSphere サンプル アプリケーションで用いられているのと同じサーブレット アーキテクチャを介して起動されます。この第 2 の実装では、多くのコードおよび設計をオリジナルの EJB ベース実装と共有しています。つまり、層どうしの間でのデータのやり取りで同じモデル オブジェクトが使用され、同じベース サーブレットおよび UI レイヤが使用されています。また、上記のとおりのその他の最適化も適用されています。

EJB ベースのアプリケーションをテストしたのは、Oracle 10G バックエンドに対してのみでしたが、この第 2 の実装は、新規の間もなくリリースされる Microsoft SQL server の JDBC ドライバを使用して、Oracle 10G のほかに SQL Server 2005 に対してもテストしました。このドライバのベータ版は、MSDN から無償でダウンロードできます。 Microsoft の完全サポート付きの、Microsoft SQL Server 2000/2005 用に最適化された (しかも無償の) 新規の JDBC ドライバの開発は、J2EE ベースのアプリケーションで SQL Server 2005 を使用する予定の J2EE 開発者にとっては、待ち焦がれていた開発です。このドライバは、2006 年 1 月に一般にリリースされる予定であり、ベータ 2 版が MSDN に掲載されています。

最適化済みの EJB 実装ならびにテスト済みの新規の JDBC/サーブレット実装に対するソースは、ベンチマーク キットに入れて Web 上に用意されています。

.NET ベンチマーク実装: DotNetGardens

ここでは、PlantsByWebSphere と機能的に同等の、DotNetGardens という名称のアプリケーションを作成しました。それは、2 つのアプリケーション サーバー プラットフォームのパフォーマンスを比較するためです。 DotNetGardens は、PlantsByWebSphere と同じバックエンド データベース スキーマに対して稼働します。 DotNetGardens アプリケーションは、PlantsByWebSphere アプリケーションの機能上の動作にならって、UI、ビジネス、およびデータの各層の操作を明確に分離した状態に保つための、3 層に分かれた類似の論理アーキテクチャを採用しています。この 3 層アーキテクチャは、業務開発用に Microsoft より提唱されている最良事例に基づいています。 DotNetGardens アプリケーションは、.NET アセンブリを使用して、データ アクセス クラスの単一のレイヤでのすべてのデータ アクセスをカプセル化します。そのようなデータ アクセス クラスは ADO.NET 2.0 を使用して、アプリケーションのデータ アクセス機能を提供します。それは、EJB エンティティ Bean が WebSphere アプリケーション用のデータ アクセスを提供するのに似通っています。 .NET 実装はストアド プロシージャをまったく使用しません。その代わりに、事前に準備された SQL ステートメントを使用して、WebSphere 実装との釣り合いをとります。データ アクセス クラスは、別個のビジネス層によってフロントエンド化されます。最後に付け加えると、アプリケーションの UI 層は、ASP.NET 2.0 Web フォームを使用して開発されました。 WebSphere 実装と同様に、すべてのデータ レコードは、各層間でやりとりされるモデル クラス内にカプセル化されて、UI、ビジネス、およびデータの各層の操作が明確に分離した状態に保たれます。 DotNetGardens アプリケーションが稼働するのは、Oracle 用の .NET Framework Data Provider (これは .NET Framework そのものに統合されています) を使用する Oracle10g バックエンド データベース と SQL Server 2005/2000 の両方に対してです。 DotNetGardens アプリケーションもまた、ダウンロード用のベンチマーク キットの一部として用意されています。

注意 : Sun Java PetStore アプリケーションに基づいた Web アプリケーションの以前のパフォーマンス比較 (2002 年 10 月に実施) では、.NET のほうが Java 実装よりもパフォーマンスに優れているという結果の主な原因として、SQL Server ストアド プロシージャの使用が多くの人によって指摘されました。 Middleware Company 社によって実行されたフォローアップ調査 (2003 年 6 月) では、すべてのストアド プロシージャを排除した .NET のパフォーマンス結果は同じであることが示されたのに対して、今回は、Plants のベンチマークにまつわるアーキテクチャ上の総体的な問題を一掃するために、DotNetGardens ではストアド プロシージャをまったく使用しないことに決定しました。

テスト対象の実装のダイアグラム

PlantsByWebSphere EJB の実装

PlantsByWebSphere JDBC の実装

DotNetGardens .NET の実装

ベンチマーク ハードウェア

アプリケーション サーバー

すべての実装は、次のようなアプリケーション サーバー ハードウェア上でテストされました。

• HP DL585 4 x 1.8 GHz AMD Opteron サーバー
  
  
• 4GB RAM
  
  
• ギガビット ネットワーキング

該当サーバーにインストールされたソフトウェアは、以下の OS/アプリケーション サーバーの組み合わせで構成されました。

Windows Server 2003 Standard Edition x86 (32 ビット)

• 32 ビットの WebSphere 6.0.2.3 Network Deployment Edition (IBM HTTP Server (Apache) を使用)
  
  
• Oracle 10G Client、Release 1。
  
  
• x86 用の 32 ビットの .NET 2.0 市販製品 (ビルド 50727 が、一般向けに MSDN に用意されているビルド)

AMD Opteron 用の Red Hat Linux Advanced Server (リリース 4)

• 32 ビットの WebSphere 6.0.2.3 Network Deployment Edition (IBM HTTP Server (Apache) を使用)

データベース サーバー

すべての実装は、次のような専用データベース サーバー ハードウェア上でテストされました。

• HardDrives Northwest デュアル コア AMD Opteron 2 x 2.4 GHz サーバー (合計 4 個のプロセッサ)
  
  
• 16GB RAM
  
  
• ギガビット ネットワーキング
  
  
• 2 個の専用高速 SCSI コントローラ
  
  
• 2 個の RAID アレイ、RAID 0+1 構成としてそれぞれが構成された 14 個のドライブ

(1 個の RAID アレイが中心的データ ファイル用に使用され、1 個がロギング用に使用されます。)

データベース用にインストールされたソフトウェアは次のとおりです。

• Windows Server 2003 x86 Enterprise Edition (32 ビット)
  
  
• Windows x86 用の Oracle 10G Enterprise Edition Release 1
  
  
• x86 用の SQL Server 2005 Enterprise Edition 一般用リリース

データベースは慎重にモニタされて、どのような場合もパフォーマンス上のボトルネック (CPU 使用、ネットワーク使用、あるいは物理ディスク使用のいずれにおいても) が示されないことを確認しました。言い換えると、ピーク時のすべてのパフォーマンス負荷を処理するのに十分なデータベース容量があることを前提に、テスト対象の各実装ごとにアプリケーション サーバーで達成された最大限のパフォーマンスが、ベンチマーク結果に示されたということです。どのベンチマークの実行でも、それぞれの実装で使用された中間層データ アクセス テクノロジを含め、アプリケーション サーバーそのもののピーク スループットを所定どおりに正確に捕捉するため、アプリケーション サーバー /テスト対象のベンチマーク実装を 96% を超える CPU 使用率で完全稼働することができました。これはデータベースのベンチマークではないことに気を付けることが大切です。なぜなら、SQL Server 2005 と Oracle10g は両方とも、テスト対象の中間層ハードウェア/ソフトウェア プラットフォームでサポートされているものをはるかに超えるユーザー負荷を処理できたはずだからです。つまり、ベンチマークでは、Web ベース シナリオでの中間層のパフォーマンスと、各種のバックエンド データベースへの接続およびそれとの連係作業がどの程度高速であるかが測定されます。そしてそこでは、各プラットフォームごとに、最もよく使用されるデータ アクセス技法とドライバが使用されます。

テスト スクリプト

各種の実装のベンチマークの測定では、Mercury LoadRunner 7.51 が使用されました。 LoadRunner テスト スクリプトは、ソース コード付きで公開されているので、顧客は自分自身でアプリケーションを簡単にテストすることができます。負荷の生成のために 20 台の物理的なエージェント コンピュータが使用されました。それらのエージェントはすべて、1 秒の思考時間を指定されうえで稼働するように設定されました。したがって、テスト対象の各実装ごとに、ピークの TPS レートはまた、テスト対象のプラットフォーム上でサポートされている同時ユーザー数にほぼ等しくなります。このスクリプトは、アプリケーション内で次のような機能を実行しました。

• ホーム ページ
  
  
• カテゴリの参照
  
  
• カートへの追加
  
  
• カテゴリの参照
  
  
• カートへの追加
  
  
• 検索 (25% がワイルドカード/複数結果、75% が完全一致)
  
  
• 商品詳細情報
  
  
• 検索 (25% がワイルドカード/複数結果、75% が完全一致)
  
  
• 商品詳細情報
  
  
• 検索 (25% がワイルドカード/複数結果、75% が完全一致)
  
  
• 商品詳細情報
  
  
• 検索 (25% がワイルドカード/複数結果、75% が完全一致)
  
  
• 商品詳細情報
  
  
• 検索 (25% がワイルドカード/複数結果、75% が完全一致)
  
  
• 商品詳細情報
  
  
• ログイン
  
  
• チェックアウト
  
  
• チェックアウトのファイナライズ
  
  
• オーダーの送信
  
  
• 会計情報の表示/修正

このベンチマークでは、Plants 顧客データベースには 10,000 人の個別顧客がロードされ、在庫データベースには 20,000 件の個別商品がロードされました。

ベンチマークの結果

ピーク TPS

価格および価格/パフォーマンスの比較

顧客側での値の比較時に役立つよう、しかも生パフォーマンスのみにとどまらないよう、テスト対象の各構成で使用されるアプリケーション サーバーをサポートするのに必要なソフトウェア ライセンスに価格を付けました (バックエンド データベースのライセンス費用を除きます)。 IBM WebSphere Application Server Express v6.0 (最も廉価な IBM WebSphere エディションを選択しました) 用の構成どおりの PlantsByWebSphere アプリケーションを作成して Red Hat Linux ES 上で実行するためのソフトウェア ライセンスの合計費用は $12,054 になります。それと機能的に同等の DotNetGardens アプリケーションを作成し、.NET 2.0 を使用して Windows Server 2003 上で実行するためのソフトウェア ライセンス費用は $6,668.92 になります。中間層ソフトウェア ライセンス費用としては、IBM 構成のほうが 2 倍近く高価です。

詳細な内訳および情報源の詳細は、付録を参照してください。

以下のグラフは、価格/パフォーマンスの比率を示しています。このグラフ中の数字は、各構成ごとのソフトウェア ライセンスの費用を、該当構成で達成されたピーク TPS で除算して算出されています。　これは、アプリケーション サーバー ソフトウェアの価値の測定です。たとえば、パフォーマンスが 2 倍であっても、費用も 2 倍かかるアプリケーション サーバーの場合、価格/パフォーマンスのスコアは等しくなります。価格パフォーマンスの数字が低いほうが、より大きな価値 (より低い費用/より良好なパフォーマンス) を示します。データベース ライセンスの費用は下記の計算には入っていません。中間層ソフトウェア ライセンスの費用のみをベースにしています。費用の詳細な内訳とそのソースは、付録を参照してください。

ピーク TPS の結果の表

たいていの場合、ピーク TPS レートの有効なベンチマーク結果は、テスト対象のシステムの CPU が「飽和状態」にある時点で報告される必要があります。言い換えると、過剰使用に陥らずに 100% 近くの CPU 使用率で稼働している必要があります。 CPU の能力が飽和状態になると、特定の構成およびアプリケーションでのピークのスループットにマシンが達したことになります。なぜなら、CPU の使用率が 100% の時点で、テスト対象のシステムの処理効率以外に、システム内に他のボトルネックはないからです。以下の表は、テストしたさまざまなアプリケーション実装のそれぞれで達成された CPU レベルおよびピークのトランザクション レートを示しています。

IBM WebSphere のヒープ サイズのチューニング

多くの J2EE アプリケーションの最も重要なチューニング領域の 1 つは、Java ヒープ サイズです。すべての IBM 実装には、さまざまなヒープ サイズを設定したうえでテストを行い、EJB および JDBC ベースの両方の実装に最適のヒープ サイズを判別しました。このアプリケーションの場合、アプリケーションそのもののメモリ フットプリントが小さいため、1,000 MB を超える RAM を使用してヒープ サイズが構成されている場合、パフォーマンス上の有意義な効果は見られませんでした。また、EJB ベースの実装の場合、JDBC の実装よりも大きなヒープ サイズの使用時に最大限のパフォーマンスが得られることも確認しました。それはおそらく、EJB キャッシュでのメモリ使用が原因と考えられます。 JDBC 実装の場合にヒープ サイズを 1,800 MB より大きく増大すると、パフォーマンスが若干低下することも確認しました。それはおそらく、ヒープが大きくなったので、ガベージ コレクションに関連したオーバーヘッドも増大したためと考えられます。その他のアプリケーションでは、このしきい値はそれぞれ異なります。

Windows Server 2003 上で稼働する .NET をベースとする Web アプリケーションでは、ヒープ サイズを最適化する必要はないことに注意してください。 WebSphere アプリケーションでそのような最適化を実行するのに要する時間と労力は測定しませんでしたが、多くの場合、かなり大量の技術的な手間をかける必要があると思われます。しかも、アプリケーションのプロファイル (ソース コードあるいはマシン構成のどちらか一方または両方) を大幅に変更するたびに、この分析を再度実行する必要があります。

以下の表は、JDBC および EJB の両方の実装に対してヒープ サイズを選択するときの参考になるように測定したデータを示しています。ここに示したデータは、RedHat Linux OS のものです。ただし、Windows OS 上の WebSphere 6 でも同じ分析結果になりました。 IBM WebSphere および .NET の両方のすべてのチューニング パラメータ セットの総合リストは、付録を参照してください。

まとめ

このベンチマークの結果が示す内容は次のとおりです。

• このベンチマークでは、Microsoft SQL Server 2005 バックエンド データベースを使用して実行したときのアプリケーションとしての .NET 2.0 のピーク パフォーマンスは、IBM WebSphere 6.0 の最適化済み EJB 実装のパフォーマンスよりも 183% 以上優れていました。
  
  
• Oracle 10G バックエンド データベースに対して .NET 2.0 実装を実行した場合、最適化済みの IBM EJB/J2EE 実装のパフォーマンスを 75% 上回りました。
  
  
• われわれが作成した WebSphere JDBC 実装は、該当アプリケーション用の IBM 提供の EJB 実装よりもはるかに優れたパフォーマンスを示しました。
  
  
• 間もなくリリースされる SQL Server 用の Microsoft リリースの JDBC プロバイダを使用する SQL Server 2005 バックエンド データベースに対して PlantsByWebSphere JDBC 実装を実行した場合、それと同等の Oracle 10G データベースに対して同じアプリケーションを実行した場合のパフォーマンスにほぼ一致します。
  
  
• RedHat Linux 上の IBM WebSphere 6.0 (Express) の中間層ライセンス費用は、Windows Server 2003 上で同等の .NET アプリケーションを実行するのに必要な中間層ライセンス費用のほとんど 2 倍になります。
  
  
• .NET は、テスト対象のベンチマークのどの実装でも、価格/パフォーマンスの比率という点で IBM WebSphere 6 をはるかにしのいでいます。この非クラスタ化ベンチマークでは、WebSphere と比較して .NET は、1 ドルあたりのパフォーマンスが最大で 4 倍優れています。 IBM WebSphere Network Deployment Editon を実行するアプリケーション サーバーと、それより低いローエンドの WebSphere Express 製品のクラスタを比較するテストでは、Microsoft Windows および .NET の価格/パフォーマンスの優位が大幅に高まります。

実際のデータ駆動 Web アプリケーションでの結果はそれぞれ異なります。たいていの顧客アプリケーションは、このベンチマークより複雑です。どのベンチマークでも、すべての顧客の実際の実務要件をすべて捕捉することはできません。また、たった 1 つのベンチマークで、パフォーマンスに関するすべての疑問に答えることもできません。とはいえ、このベンチマークは、業務開発者にとっては興味深いものです。それは、アプリケーションは、シンプルでありながら、複雑な実務アプリケーションで使用されるのと同じ業務アーキテクチャ素材の多くを使用して実行されているからです。データ駆動 Web アプリケーションの構築および実行では、.NET 2.0 のパフォーマンスおよび価格/パフォーマンスのほうが IBM WebSphere 6 よりも優れていることが、このベンチマークで実証されたものと確信します。ベンチマーク キットをダウンロードし、各自の環境に合わせて修正し、それぞれ独自にテストを行うことをお勧めします。

付録 1: 価格

以下の表は、このベンチマークで行ったように、単一の 4 CPU 中間層サーバー上で Plants アプリケーションを実行する場合の、アプリケーション サーバー中間層の価格明細を示しています。これは、Windows Server 2003 上で稼働する .NET と、Red Hat Linux 上で稼働する IBM WebSphere Express の価格を比較しています。また以下の価格は、各 OS のサポートされているバージョンごとのオペレーティング システム ライセンス費用と、アプリケーションサーバそのものの費用、アプリケーションの作成に使用する Microsoft および IBM の開発ツールの開発者 1 名あたりのライセンス料で構成されています。データベースの価格はこの表には入っていないことに注意してください。データベースの価格を比較したい場合は、https://www.microsoft.com/sql/ (英語) に掲載されている Oracle および SQL Server 2005 の価格比較のページを参照してください。

注意 : 業務上推奨されている IBM WebSphere Network Deployment Edition を使ってテストを行いましたが、それより廉価な IBM WebSphere Express の価格を記載しています。その理由は、単一の 4 プロセッサ サーバー上では、技術的には顧客は、より高価な IBM WebSphere Network Deployment ではなく IBM Websphere Express を使用して、WebSphere のライセンス費用を削減できるからです。ただし、顧客が、負荷分散および共用セッション状態を使用して、クラスタ内に Plants アプリケーションを実装したいと考えた場合、通常は IBM WebSphere Network Deployment Edition のライセンスを購入します。こちらのほうは、Express と比較して、デプロイ先の各サーバーごとに CPU あたり $13,000 の追加費用がかかります。 .NET 実装は、クラスタの場合のネットワーク負荷分散および共用セッション状態をサポートします。しかも、クラスタ内の各サーバーごとにオペレーティング システムのコピーを 1 つずつ追加して購入する以外に、追加のライセンス費用がかかることはありません (これは、WebSphere クラスタの場合にも当てはまります)。

価格に関する注意事項

IBM の場合の費用は、IBM.com オンライン ストアおよび Red Hat オンライン ストアから得たものです。より廉価な Red Hat Enterprise Linux ES とは対照的に、Red Hat Enterprise Linux AS が必要です。なぜならこの構成は 4 個の CPU を使用するのに対して、Red Hat Enterprise Linux ES のライセンスでサポートされる最大数の CPU は 2 個だからです。Windows Server 2003 Standard Edition は、最大 4 個の CPU をサポートします。 RWD Developer ツール用のシングル シート ライセンスが WAS Express に付属していますが、Plants アプリケーションの EJB 実装 (IBM のオリジナル開発のもの) には EJB のサポートが必要なので、その要件を満たすために、WebSphere 6 用の Rational Application Developer の価格を別に付け加えました。 RAD のフローティング ユーザー ライセンスの価格は、現行の (2005 年 10 月現在) 販売促進期間中は初年度は $2,155.00 ですが、通常の価格は $7,000/ユーザーになります。

すべての Microsoft ソフトウェアのライセンス費用は、Visual Studio 2005 のものを除いて、Microsoft 社の認可を受けた販売店から入手しました。

注意 : MSDN プレミアム サブスクリプション付きの Visual Studio 2005 Professional の価格は、販売店の実際の価格ではなく、推定小売価格です。この記事の発行時点ではこの品目の実際の販売店価格を確認できませんでしたが、ここで使用した推定価格より若干低くなると考えられます。

付録 2: チューニング

WebSphere 6 のチューニング (WAS 6.0.2.3)

• セッション状態の有効期限を 5 分に設定 (プロセス内セッション状態)
  
  
• アクセス ログをオフ
  
  
• パフォーマンス モニタ インフラストラクチャをオフ
  
  
• 診断トレースをオフ
  
  
• システム アウトをオフ
  
  
• EJB キャッシュ サイズ = 20,000
  
  
• HTTP チャネルの永続要求の最大数 = -1
  
  
• HTTP チャネルの readTimeout = 6,000
  
  
• HTTP チャネルの writeTimeout = 6,000
  
  
• HTTP チャネルの persistentTimeout = 3,000
  
  
• Web コンテナの最小スレッド数 = 75
  
  
• Web コンテナの最大スレッド数 = 75
  
  
• ORB の最小スレッド数 = 40
  
  
• ORB の最大スレッド数 = 40
  
  
• 既定スレッドの最小数 = 20
  
  
• 既定スレッドの最大数 = 20
  
  
• ヒープ サイズ:
  1. Windows Server 2003 上に 1,640 MB EJB を実装 (これは、Windows 上の 32 ビット WebSphere の最大値です)
     
     
  2. Linux 上に 2,300 MB EJB を実装 (これは、Linux 上の 32 ビット WebSphere の最大値です)
     
     
  3. Windows 上に 1,640 MB JDBC を実装
     
     
  4. Linux 上に 1,800 MB JDBC を実装
• EJB の実装 : Inventory および Customer エンティティ Bean の読み取りメソッドに対して、アクセス インテント ポリシーをオプティミスティック読み取り分離レベルに設定

IBM HTTP Server

IBM HTTP Server の Windows:

• アクセス ログをオフ
  
  
• KeepAlive 要求の最大数を 3,000 に
  
  
• 最大スレッド数を 2,048
  
  
• Threads/child の数を 2,048

IBM HTTP Server の Linux :

• アクセス ログをオフ
  
  
• KeepAlive 要求の最大数を 3,000 に
  
  
• ThreadLimit を 50 に
  
  
• ServerLimit を64 に
  
  
• StartServers を 50 に
  
  
• MaxClients を 3,200 に
  
  
• MinSpareThreads を 100 に
  
  
• MaxSpareThreads を 100 に
  
  
• Threads/Child を 50 に
  
  
• MaxRequests/Child を 0 に

Linux のチューニング

• net.ipv4.tcp_max_syn_backlog=1024
  
  
• kernel.msgmni=1024
  
  
• kernel.sem=1000 32000 32 512
  
  
• fs.file-max=65535
  
  
• kernel.shmmax =4294967295
  
  
• net.core.netdev_max_backlog = 20000
  
  
• net.core.somaxconn = 20000
  
  
• net.ipv4.tcp_fin_timeout = 30
  
  
• net.ipv4.tcp_syn_retries = 20
  
  
• net.ipv4.tcp_synack_retries = 20
  
  
• net.ipv4.tcp_sack = 0
  
  
• net.ipv4.tcp_timestamps = 0
  
  
• net.ipv4.conf.all.arp_ignore = 3
  
  
• net.ipv4.conf.all.arp_announce = 2
  
  
• ファイル ハンドルの同時オープンの上限 (ソフト) を 20,000 に増大

Windows Server 2003 のチューニング

TCP/IP サービス用のレジストリ パラメータの設定 (CurrentControlSet/Services/tcpip/parameters) を次のように追加:

TcpTimedWaitDelay を 10 進数の 30 に設定

MaxUserPort を 10 進数の 32,768 に設定

.NET 2.0 のチューニング

.NET ワーカー プロセス

• Rapid Fail Protection をオフ
  
  
• ping をオフ
  
  
• リサイクル ワーカー プロセスをオフ

ASP.NET

• セッション状態のタイムアウトを 5 分に設定 (プロセス内セッション状態)
  
  
• IBM WebSphere への匿名アクセスに合わせて認証を「None」に設定

IIS 6.0 仮想ディレクトリ

• 基本認証のみ
  
  
• アクセス ログをオフ

Mercury の設定

エージェントの設定は次のとおり。

1. 各要求ごとに新規ユーザーをシミュレート (アプリケーション サーバーへの個々の接続を、各スクリプトの繰り返し時点で開き、終了時点で閉じる。ただし、どの場合も HTTP のキープアライブは有効のままになります。)
   
   
2. 2. アプリケーション サーバーから戻された HTML リソースのみをダウンロードし、グラフィックス ファイルや HTML 以外の他のリソースはダウンロードしない。

付録 3: 新規の Microsoft SQL Server JDBC ドライバ

MS SQL Server バックエンドで使用するために作成した PlantsByWebSphere の Java アプリケーションは、MSDN に用意されている新規の Microsoft SQL Server JDBC ドライバの Beta2 リリースを使用して稼働します。このドライバは、SQL Server 2000 用のこれまでのドライバとはまったく異なるコードベースを基盤とし、最新の機能とより優れたパフォーマンスを備えています。ただし、テストでは、このドライバの Beta2 以前のリリースを使用しました。なぜなら、われわれがアプリケーションに追加した新規の検索ロジック (アプリケーション内の 1 つのクエリ) にのみ影響を与えるバグが Beta2 リリース内に現存しているからです。このバグが原因で、ベータ版の JDBC ドライバを介した実行時に、SQL Server が LIKE 文節上で Query Optimizer を正しく使用できなくなります。その後、今後の一般向けリリースに備えて、このバグへの取り組みが開始されました。ただし、今回の結果を再現したい方や、ベンチマーク キットで SQL Server Java アプリケーションに対するさらに別のベンチマークを実行したいという方は、benchnet@microsoft.com (英語) に電子メールをお送りいただければ、われわれが使用した Beta2 以前のビルドのコピーを入手できます。また、SQL Server 2005 用の PlantsByWebSphere EJB 実装にも取り組んでいます。これは、コンテナ管理パーシスタンス (CMP)/EJB でのこの新規のドライバの使用法を示すものです。