Java Web サービス: CXF のパフォーマンス比較

CXF のパフォーマンスを最新バージョンの Axis2 および Metro と比較する

Apache CXF のベースとなっているコンポーネントは Apache Axis2 および Metro とある程度共通していますが、CXF はこの 2 つとは全く異なるアーキテクチャーでコンポーネントを構成しています。Dennis Sosnoski の連載「Java Web サービス」では今回、CXF、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年 4月 27日

Apache CXF Web サービス・スタックがベースとする技術の一部は、この連載の以前の記事で説明した Apache Axis2 スタックおよび Metro スタックと共通しています。CXF は Axis2 と同じく Apache WSS4J WS-Security 実装を使用し、Metro と同じく JAX-WS 2.x Web サービス構成と JAXB 2.x データ・バインディングを使用します (バージョンはスタック間で共通していないかもしれませんが、使用する JAXB のリファレンス実装も Metro と同じです)。このように共通するコンポーネントはあるものの、この 3 つのスタックは、処理エンジンや WS-SecurityPolicy 構成の処理を含め、多くの点で異なっています。

Axis2 のパフォーマンスと Metro のパフォーマンスについては、連載の過去の記事で、単純なメッセージ交換の場合と、異なる WS-Security 構成を使用した場合の両方で比較を行いました。今回の記事では CXF のパフォーマンスを、最新リリースの Axis2 および Metro のパフォーマンスと比較します。

この連載について

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

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

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

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

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

このテストは Athlon X2 5400+ プロセッサーと 4GB の RAM を搭載したマシンに Mandriva 2009.1 64-bit Linux システムをインストールした環境で、Sun (Oracle) Java 1.6.0_13 32-bit JVM (特定のヒープ・サイズでは、64-bit の JVM より多少パフォーマンスが向上します) を使用して実行しました。サーバー・コードを実行した Tomcat 6.0.20 は 1,024MB のヒープを使用するように構成されています。一方、クライアント・コードが使用するヒープは 512MB です。使用した各 Web サービス・スタックのバージョンは以下のとおりです。

  • CXF 2.1.7
  • Metro 2.0
  • Rampart 1.5 リリースを適用した Axis2 1.5.1

お使いのハードウェアと JVM でこのテストを試すには、サンプル・コードをダウンロードしてください。


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

図 1 に、WS-Security を一切使用せずに Axis2、Metro、CXF の各スタックで測定したテスト時間を示します。このグラフからわかるように、多数のリクエストで一致件数の少ないレスポンスを返すテストの場合、Metro スタックの実行速度は Axis2 と CXF の両方を大幅に上回っています (約 25 パーセント高速化)。少ない数のリクエストで多数のレスポンスを返すテストの場合には、Metro スタックとApache スタックの実行速度はほぼ同じです (この記事に記載するグラフではいずれも棒の長さが時間の長さを示すため、棒が短ければパフォーマンスに優れていることになります)。

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

上記の結果には、以前に行った Metro 1.5 と Axis2 1.5.1 のパフォーマンスの比較との興味深い違いが表れています。少なくともこのテスト・アプリケーションで使用したデータでのテスト時間の結果からわかるのは、Metro 2.0 はリクエストごとの処理時間という点で、Axis2 にも、CXF にも勝っているということです。一方、XML へのデータ変換および XML からのデータ変換に関しては、3 つのスタックの実行速度はほとんど変わりません。これは、Metro と CXF に関しては当然の結果と言えます。それは、この 2 つのスタックはどちらも XML 変換に JAXB リファレンス実装を使用するからです。以上の結果から判断すると、Axis2 がデフォルトで使用する ADB (Axis2 Databinding Framework) バインディング実装の実行速度は、JAXB とほとんど同じということになります。


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

以降の図に示されているテスト時間は、以下のセキュリティー構成を使用した場合の結果です

  • plain: セキュリティーなし (図 1 と同じ値)
  • username: リクエストで WS-Security による平文の UsernameToken を使用
  • sign: 本体とヘッダーに WS-Security による署名を付与し、タイムスタンプを使用
  • signencr: 本体とヘッダーに WS-Security による署名を付与してタイムスタンプを使用し、本体を暗号化

図 2 に、1,000 のリクエストで一致件数の少ないレスポンスを返すテストで測定した時間を示します。

図 2. 少数のレスポンスを返すテストで測定した時間
少数のレスポンスを返すテストで測定した時間を示す棒グラフ

図 3 に、上記の 1,000 のリクエストで一致件数の少ないレスポンスを返す場合の相対時間 (CXF の結果を基準に正規化) を示します。

図 3. 少数のレスポンスを返す場合のテスト時間を正規化した結果
少数のレスポンスを返す場合のテスト時間を正規化した結果を示す棒グラフ

Axis2 は、このテスト・ケースでどのセキュリティー構成を使用した場合においても、3 つのスタックのなかで最も処理に時間がかかる結果となっています。Metro はいずれのテストでも最も速く処理が終わる結果となっていますが、Metro と CXF の差は、CXF と Axis2 の差に比べるとほんのわずかです。Metro はそれぞれのセキュリティー構成で一貫して CXF より 10 パーセント程度、高速に処理される一方で、Axis2 は CXF の 2 倍以上の時間を処理に要しています。

図 4 に、100 のリクエストで一致件数の多いレスポンスを返すテストで測定した時間を示します。

図 4. 多数のレスポンスを返すテストで測定した時間
多数のレスポンスを返すテストで測定した時間を示す棒グラフ

図 5 に、上記と同じ 100 のリクエストで一致件数の多いレスポンスを返す場合の相対時間 (CXF の結果を基準に正規化した時間) を示します。

図 5. 多数のレスポンスを返す場合のテスト時間を正規化した結果
多数のレスポンスを返す場合のテスト時間を正規化した結果を示す棒グラフ

この 2 番目のテスト・ケースでも、Axis2 の処理速度は Metro や CXF よりかなり遅くなっています (この場合も、CXF の速度の約半分)。一方、Metro と CXF との差は、一致件数の少ないレスポンスを返す場合とは逆転し、CXF の速度は全体的に Metro の約 15 パーセント増となっています。

CXF 2.1.7 と 2.1.6 の違い

上記のテスト時間には、CXF のバージョン 2.1.6 からバージョン 2.1.7 にかけて、パフォーマンスが大幅に改善されたことが反映されています。このパフォーマンスの改善は、コードが調整されたことにもよりますが、それにも増して、「CXF での WS-Security」で説明した問題が修正されたことが大きな要因となっています。CXF 2.1.6 では、WS-SecurityPolicy 構成に <sp:TransportBinding> ポリシーや何らかの形での暗号化または署名ポリシーが含まれていない限り、UsernameToken を処理しませんでした。そのため通常は、UsernameToken が使用されるときには、このようなポリシーが追加されることになります。平文の UsernameToken を使用する場合には尚更のこと、トランスポート・レベルまたはメッセージ・レベルのいずれかで暗号化が行わなければ、ユーザー名とパスワードがデータ送信中に盗み見られてしまうからです。しかしポリシーの観点からすると、(この記事での「username」の構成で使用しているように) UsernameToken を単独で使用してもまったく問題ありません。そしてこのような場合に対処するのが、CXF 2.1.7 で実装された修正です。CXF 2.1.7 で行われた修正では、この特定のテスト・ケースでのレスポンス・メッセージ・フローへの WS-Security 処理の追加を省略しています。

「username」の構成でメッセージ・フローから WS-Security がなくなったことで、CXF 2.1.6 で同じテストを実行した場合と比べ、CXF の結果は全体的に数パーセント改善されました。しかし、このバージョン間での改善は、残念ながらうわべだけのものです。「username」のテスト・ケースでトランスポート・レベルまたはメッセージ・レベルでの暗号化を使用する場合、WS-Security の処理がレスポンス・メッセージ・フローの中に含まれることになるため、この構成での CXF のテスト時間は顕著に長くなります。CXF の今後のバージョンに期待されるのは、必要な場合にのみ、WS-Security がリクエスト・メッセージ・フローまたはレスポンス・メッセージ・フローのいずれかで構成されるように、ポリシー分析が拡張されることです。そうなれば、パフォーマンスのメリットがさらに広い範囲の使用ケースにもたらされることになります (これには、署名または暗号化が一方向でのみ必要な場合も含まれます)。


まとめ

この記事でレポートしたテスト時間から判断すると、Metro 2.0 は基本的なリクエスト/レスポンス処理においては、Axis2 1.5.1 や CXF 2.1.7 よりも高速に行われます。一方 WS-Security の処理となると、Metro の XWSS ライブラリーの総体的な速度は、Axis2 と CXF の両方で使われている WSS4J ライブラリーの速度を上回ることはありません。

おそらく、これらの結果が示す最も興味深い側面は、Axis2 にとってこれらの結果がどういう意味を持つかです。前に実行したテストでは、Axis2 が WS-Security を処理する速度は Metro を大幅に下回っていました。今回のテスト結果は、この違いが WS-Security 実装コードによって生じるものではないことを示しています。したがって原因は、Axis2 (および Rampart セキュリティー・モジュール) が WSS4J との間で受け渡しするメッセージの処理方法にあるはずです。このことは、「Metro と Axis2 のパフォーマンス比較」で説明した結果にも一致します。また、Axis2 は他のスタックに比べ、テストの実行にかなりのメモリーが必要です。特に「signenecr」構成の場合、Axis2 にはクライアント上で約 80MB のメモリーが必要でしたが、CXF は 48MB で問題なく動作しました。これらの問題は、Axis2 が WS-Security を処理する一環として、メッセージ表現を異なるメッセージ表現へと不要な変換をすることにより、処理時間とメモリーを無駄に使うという最初の印象を強くします。

テスト対象のすべてのスタックに共通して、WS-Security の署名と暗号化を使用することにより、相当なパフォーマンス・オーバーヘッドが発生します。このオーバーヘッドは、サービスが多用されている場合には問題になるはずです。次回の記事では、WS-Trust および WS-SecureConversation というアドオン技術を取り上げます。クライアントが特定のサービスを多用する場合、この 2 つの技術によって WS-Security のオーバーヘッドを減らすことができます。


ダウンロード

内容ファイル名サイズ
Source code for this articlej-jws14-src.zip4.86MB

参考文献

  • CXF: CXFは、Apache Software Foundation によるオープンソースの Web サービス・スタックです。
  • Axis2: Axis 2 も同じく Apache によるオープンソースの Web サービス・スタックです。
  • Metro: Metro は、JAXB 2.x および JAX-WS 2.x Java 標準の最新リファレンス実装を組み込んだオープンソースの Web サービス・スタックです。
  • WSS4J: WSS4J は Apache Software Foundation によるオープンソースの WS-Security 実装です、Axis2 と CXF は両方とも WS-Security の処理に WSS4J を使用しています。
  • XWSS: XWSS は、Metro で WS-SecurityPolicy の処理に対応するコンポーネントです。
  • 連載「Understanding Web Services specifications」: このチュートリアルの連載では、多数の重要な Web サービス標準を紹介しています。以下のチュートリアルがあります。
  • OASIS Web Services Security (WSS) TC: WS-Security 仕様およびトークン・プロファイルを担当している組織です。これらの標準のすべてのバージョンへのリンクは、このサイトに記載されています。
  • W3C Web Services Policy Working Group: このグループが、WS-Policy 仕様を定義しています。
  • OASIS Web Services Secure Exchange (WS-SX) TC: WS-SecurityPolicy および関連仕様を担当している組織です。

コメント

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, Open source
ArticleID=493247
ArticleTitle=Java Web サービス: CXF のパフォーマンス比較
publish-date=04272010