Java Web サービス: Metro と Axis2 のパフォーマンス比較

Metro と Axis2 のパフォーマンスを、WS-Security を使用した場合、使用しない場合の両方で比較する

Metro Web サービス・スタックと Axis2 スタックが提供する機能は同じです。けれども、Axis2 ではオプションで JAXB および JAX-WS を使用できることを除けば、この 2 つが使用する関連技術の実装はまったく異なります。Dennis Sosnoski の連載「Java Web サービス」では今回、Metro スタックと Axis2 スタックのパフォーマンスの違いを、WS-Security を使用した場合と使用しない場合の両方で比較します。

Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Solutions, Inc.

Author photoDennis Sosnoski は Java ベースの XML および Web サービスを専門とするコンサルタント兼トレーナーです。専門家としてのソフトウェア開発経験は 30 年以上に渡り、この 10 年間はサーバー・サイドの XML 技術や Java 技術に注力しています。オープンソースのJiBX XML Data Binding フレームワークや、それに関連した JiBX/WS Web サービス・フレームワークの開発リーダーを務め、さらに Apache Axis2 Web サービス・フレームワークのコミッターでもあります。彼は JAX-WS 2.0 および JAXB 2.0 仕様のエキスパート・グループの一員でもありました。



2010年 1月 19日

Metro Web サービス・スタックは JAXB 2.x データ・バインディングおよび JAX-WS 2.x Web サービス標準のリファレンス実装をベースとしていますが、JAX-WS が定義する基本サポートの枠を超えた機能を提供するために追加のコンポーネントを使用しています。具体的には、WS-Security およびその他の SOAP 拡張技術を実装する WSIT (Web Services Interoperability Technologies) プロジェクト、そして実際の WS-Security の処理を実装する XWSS (XML and WebServices Security Project) というコンポーネントです。

この連載について

Web サービスは、エンタープライズ・コンピューティングにおいて Java 技術が担う重大な役割の一部です。この連載では、XML および Web サービスのコンサルタントである Dennis Sosnoski が、Web サービスを使用する Java 開発者にとって重要になる主要なフレームワークと技術について説明します。この連載から、現場での最新の開発情報を入手して、それらを皆さんのプログラミング・プロジェクトにどのように利用できるかを知っておいてください。

一方、Axis2 がベースとしている技術はまったく異なり、Axis2 専用に開発された ADB (Axis2 Data Binding) データ・バインディング実装と Axis2 エンジン、そして WS-Security サポートには WSS4J (Web Services Security for Java) と Rampart モジュールを組み合わせて使用します。WS-Security の処理が Axis2 Web サービス・スタックでのパフォーマンスに与える影響については、この連載の以前の記事、「(WS-)Security に伴う高コスト」で説明しました。

後続の記事「Metro の紹介」、「Metro での WS-Security」では、インストール、構成、そして実際の使用方法に関する Metro と Axis2 の違いを説明しました。今回の記事では、この 2 つのスタックのパフォーマンスの違いについて、WS-Security を使用した場合の影響も含めて比較検討します。

パフォーマンスについての検討

(WS-)Security に伴う高コスト」で使用した手法と同じく、この記事でも単一システム上で稼働しているクライアントとサーバーを使用して、リクエストの特定シーケンスを実行するのに必要な時間を測定します。この手法は、Web サービスの処理のオーバーヘッドを比較する際に大きな効果を発揮します。なぜなら、ネットワークの待ち時間とオーバーヘッドによる影響が測定結果にまったく含まれないためです。また、サーバー・コードの実行速度がクライアント・コードとそれほど変わらないことを前提とすれば、測定結果の数値にも、負荷状態にある実際のサーバーのパフォーマンスがよく表れているはずです。

今回の記事では、前の記事と同じテスト・アプリケーションを使用します。この地震データ検索サービスは、1 年間に世界各地で起こった 93,000 件を超える地震のデータを保管する実際のデータベースを利用しています。サービスに対するリクエストで期間と緯度、経度の範囲を指定すると、指定された範囲内のすべての地震データが返されます。このアプリケーションの詳細と、リクエストとそれに対するレスポンス・メッセージのサンプルについては、「(WS-)Security に伴う高コスト」を参照してください。

前回の記事と同様、パフォーマンス・テストには 2 つのリクエスト・シーケンスを使用しました。最初のシーケンスで使用する 1,000 のリクエストでは、地震データベース全体のほんの一部とだけ一致するようにクエリー・パラメーターを調整してあります (1,000 のリクエストに対して、一致結果として 816 件の地震データだけが返されます)。2 番目のシーケンスでは、それよりも多くのデータと一致するように調整された 100 のリクエストを使用します (100 のリクエストに対して、一致結果として 176,745 件の地震データが返されます)。それぞれのリクエスト・シーケンスを異なるセキュリティー構成で何度か実行し、構成ごとの最短処理時間だけを結果に残しました。

このテストは Athlon X2 5400+ プロセッサーと 4 GB の RAM を搭載したマシンに Mandriva 2009.1 64-bit Linux システムをインストールした環境で、Sun Java 1.6.0_13 32-bit JVM (特定のヒープ・サイズでは、64-bit の JVM より多少パフォーマンスが向上します) を使用して実行しました。サーバー・コードを実行した Tomcat 6.0.20 は 1,024 MB のヒープを使用するように構成されています。一方、クライアント・コードが使用するヒープは 512 MB です。Web サービス・スタックのバージョンは、Metro についてはバージョン 1.5 (WSIT および XWSS が含まれます) を、Axis2 についてはバージョン 1.5.1 を使用して Rampart コードの最新ビルド (Axis2 1.5.x コードに対応する Rampart リリースがなかったため) を適用しました。お使いのハードウェアと JVM でテストを試すには、サンプル・コードをダウンロードしてください。

前の記事では、平文、SSL、異なる WS-Security/WS-SecureConversation 構成を使用して、Axis2 のパフォーマンスだけを調べました。今回はそれよりも構成の種類を絞りますが、それぞれの構成で Axis2 と Metro のパフォーマンスを直接比較します。


WS-Security を使用しない場合のパフォーマンス

図 1 に、WS-Security を一切使用せずに Axis2 と Metro のそれぞれで測定したテスト時間を示します。この図から、2 つのスタックにはわずかな違いしかないことがわかります。1,000 のリクエストで一致件数の少ないレスポンスを返すテストの場合、Metro の実行時間は Axis2 より 0.5 秒短くなっています。わずか 100 のリクエストで一致件数の多いレスポンスを返すテストでは、2 つのスタックの実行速度は同じく優れていました (その差は 0.1 秒以内でした)。

図 1. セキュリティーを使用しない場合のテスト時間
セキュリティーを使用しない場合のテスト時間を示す棒グラフ

これらのテスト時間の結果からわかることは、(テスト・アプリケーションで使用したデータの場合) リクエストごとの処理速度については Metro のほうがわずかに Axis2 より勝っているかもしれませんが、実際のデータ変換を行う速度は互角であるということです (Axis2 でデフォルトの ADB データ・バインディングを使用した場合です。他のデータ・バインディングでは異なる結果になる可能性もあります。特に XMLBeans バインディングでは、速度が大幅に落ちることがわかっています)。


WS-Security を使用した場合のパフォーマンス

以下の 2 つの図に、次のセキュリティー構成を使用した場合の相対テスト時間を示します。

  • plain — セキュリティーなし (図 1 と同じ値ですが、Axis2 の時間を基準に正規化されています。)
  • username — リクエストで WS-Security による平文の UsernameToken を使用
  • sign — 本体とヘッダーに WS-Security による署名を付与し、タイムスタンプを使用
  • signencr — 本体とヘッダーに WS-Security による署名を付与してタイムスタンプを使用し、本体を暗号化

図 2図 3 ではどちらも結果を比較しやすいように、plain 構成を使用した Axis2 での測定時間を 1 とし、他の測定時間をその倍数で表しています。まず図 2 に、1,000 のリクエストで一致件数の少ないレスポンスを返すテストでの時間を示します。

図 2. 一致件数の少ないレスポンスを返すテスト
一致件数の少ないレスポンスを返すテストの棒グラフ

図 3 は、100 のリクエストで一致件数の多いレスポンスを返すテストでの時間を示しています。

図 3. 一致件数の多いレスポンスを返すテスト
一致件数の多いレスポンスを返すテストの棒グラフ

WS-Security 構成を使用した場合、Metro の速度は Axis2 よりも大幅に速くなっています。全体的には 2 倍以上の速さで、メッセージ数が多い場合の username 構成および sign 構成では 3 倍を超えているほどです。この 2 つの Web サービス・スタックがほとんど同じ成熟度にあることを考えると、これは驚くべき結果です。

Rampart には、org.apache.rampart.TIME ロガーを使用した基本的なタイム・ロギング機能が組み込まれています。このロガーを DEBUG レベルで有効にすると、Rampart 処理のさまざまな部分のクロック時間を調べることができます。奇妙なことに、このロガーを署名によるセキュリティー構成を使用した例で有効にしたところ、Rampart の処理時間はテストの所要時間全体の半分も占めていないことがわかりました。これが何を意味しているかと言えば、Axis2/Rampart WS-Security 処理における第一のパフォーマンス問題は、Rampart にではなく、ベースとなる WSS4J セキュリティー実装にあるということです。

確かに Rampart には改善の余地が大いにあります。「(WS-)Security に伴う高コスト」でも言及したとおり、Rampart は WS-Security の処理が関わってくると、常にメモリー内に完全なメッセージ・モデルを作成します。メモリー内にモデルを作成することから生じるオーバーヘッドが、UsernameToken の例での Axis2/Rampart のパフォーマンス不足の原因であることは明らかです。これ以外の WS-Security のシナリオでも、Axis2/Rampart のパフォーマンス不足がこの種の変換問題に関連している可能性があります。


Metro についてのまとめ

Metro をスタンドアロン用に構成するとなると、入手できるドキュメントが限られていることを考えても (「参考資料」を参照) 厄介な作業になるかもしれません。その上、広範なデータ・バインディングとさまざまな構成をサポートする Axis2 とは対照的に、Metro は JAXB 2.x データ・バインディングと JAX-WS 2.x Web サービス構成でなければ機能しません。しかしその一方、Metro は平文のメッセージ交換では Axis2 と同等のパフォーマンスを提供し、さらに WS-Security が関係してくると、Axis2 より遥かに優れたパフォーマンスを提供します。WS-Security を使用していて、パフォーマンスについての懸念があるとしたら、是が非でも Metro をアプリケーションに使用することを検討してください。

次回の記事では別の Apache Foundation プロジェクトとして、CXF Web サービス・スタックを取り上げます。CXF が使用する基礎コンポーネントのいくつかは Axis2 と同じですが、Web サービスの構成およびデプロイに関してはかなり異なるスタイルを使用しています。CXF の使用についての基本、そして Axis2 と Metro との違いを学んでください。


ダウンロード

内容ファイル名サイズ
Sample code for this articlej-jws11.zip3.7MB

参考文献

学ぶために

  • Metro: Metro は、JAXB 2.x および JAX-WS 2.x Java 標準の最新リファレンス実装を組み込んだオープンソースの Web サービス・スタックです。プロジェクトのサイトにアクセスして、ダウンロード、資料を入手してください。
  • Apache Axis2/Java: Axis2 の開発および状態に関する情報が記載されています。
  • WSIT (Web Services Interoperability Technologies): WSIT は Metro のコンポーネントで、WS-SecurityPolicy とその他いくつかのセキュリティー関連の技術を処理します。
  • XWSS (XML and WebServices Security Project): XWSS は Metro のランタイム・セキュリティー処理を実装します。
  • Security Token Configuration in Metro」(Kumar Jayanti 著、java.net、2009年6月): セキュリティー処理に対応した Metro/WSIT の構成については、このブログ・エントリーが多少なりとも包括的な唯一の資料となります (ただし適用対象は、現行の 1.5 リリースではなく、現在予定されている 2.0 リリースです)。
  • JAXB リファレンス実装: JAXB リファレンス実装のホーム・ページです。
  • JAX-WS リファレンス実装: JAX-WS リファレンス実装のホーム・ページです。
  • Technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。
  • developerWorks Java technology ゾーン: Java プログラミングのあらゆる側面を網羅した記事が豊富に用意されています。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Java technology, SOA and web services
ArticleID=467944
ArticleTitle=Java Web サービス: Metro と Axis2 のパフォーマンス比較
publish-date=01192010