WLRTの有効性を実証するために、Traderという名前のサンプル株式取引アプリケーションをチューニングし、ベンチマークを測定しました。動作中のTraderアプリケーションは、 株価照会と 注文のリクエストを繰り返し実行する1つ以上のクライアントで構成されます。株価照会リクエストは、メッセージ駆動型Bean（MDB）に対するJMSの非永続的メッセージングを介して、WebLogic Server上の 株価照会サービスから株価を取得します。一方、注文リクエストは 注文サービスを呼び出します。このサービスは、MDBに対するJMSの高信頼性永続的メッセージングを介して、エミュレートされたデータベースにトランザクション的にリクエストを記録します。

どちらのJVMも手動であまりチューニングせずに達成できる結果を生成することが目標であったため、JRockit JVMとSun JVMのどちらも大幅なチューニングは行いませんでした。実際、ほとんどのチューニングは、1つの例外を除いて標準的なベストプラクティスに従っていま す。例外はサーバJVMのメモリを256MBに制限するというもので、これはJRockitのDetGCアルゴリズムに適したサイズです。Traderア プリケーションの最適化に必要なチューニングについては、「Traderサンプルのチューニング」で詳しく説明しています。

結果概要

このベンチマークの結果は、DetGCを有効にしたWLRT 1.0のJRockit JVMが、IncGCを備えたSun JVM、およびDetGCを使用しないデフォルトのJRockit JVMと比較して、スループットとレイテンシの両面で高いパフォーマンスを発揮したことを示しています。パフォーマンスが最重視されるリアルタイムアプリ ケーションでは、多くの場合、スループット性能を犠牲にしてでも応答時間を短縮する必要があります。しかしながら、WLRT 1.0では、高水準のスループットを維持しながらレイテンシを大幅に低減することができました。

実際、DetGCを有効にしたJRockitは、ベンチマーク対象の他のJVMの約5分の1のレイテンシを実現した上で、17%高いスループットを 達成しました。また、DetGCなしのJRockitでは、最大で275ミリ秒のGC（ガベージコレクション）休止時間がレポートされました。一方、 DetGCを有効にしたJRockitでレポートされた最大GC休止時間は、それをはるかに下回る約30ミリ秒でした。これらの結果の詳細については、「拡張ベンチマーク：マシン2台、実行時間2時間」および「ベンチマーク詳細グラフ」を参照してください。

最初の短時間ベンチマーク

最初のベンチマークでは、1台のマシン上で、シングルスレッド構成で、ごく短時間のベンチマークを連続して実行しました。このベンチマークの目的 は、Sun JVMおよびJRockit JVMの両方を対象に、クライアントおよびサーバでそれぞれ確定的GCまたは非確定的GCを使用してアプリケーションを実行し、最適な組み合わせを探すこ とでした。JRockitのDeterministic Garbage Collectionオプションと比較するために、Sun JVMのIncremental Garbage Collection（IncGC）オプションを使用しました。

結果から分かったのは、短い応答時間を安定的に達成するためには、サーバJVMだけでなく クライアントJVM上でもDetGCオ プションを使用する必要がある、ということです。ただし、負荷の高い少数のクライアントが1台のマシン上で動作しているのではなく、（実際のアプリケー ション環境で典型的なように）それほど負荷の高くないクライアントが多数のマシンに分散しているような環境では、クライアントでのDetGCの使用は必要 ではない可能性もあります。

中間のベンチマーク：実行時間20分、マシン2台

続いて、応答時間に悪影響を及ぼさずに高スループットを達成する同時クライアントスレッドの最大数を調べるために、20分の実行をJRockit上で連続して行いました。このベンチマークでは、 ランプアップ（ramp-up：立ち上げ）時間として、レポートされたすべての結果から 各実行の最初の60秒のデータを除外しています。

次のグラフは、「ベンチマーク詳細グラフ」で示している詳細グラフから得られた結果を図示したものです。

図1：最適なスループットと応答時間を達成するスレッド数のグラフ（画像クリックで標準サイズのスクリーンショットを表示）

この結果から、スレッド数が8のときにスループットと応答時間の組み合わせが最適になることが判明しました。1230オペレーション/秒のスルー プットに対し、50ミリ秒以内の応答の割合は99.98%です。スレッド数が32のときに最高のスループット（1460オペレーション/秒）を記録してい ますが、応答時間が犠牲になっています。50ミリ秒以内の応答は95.72%にとどまっています。これらの実行の詳細なグラフについては、「20分間のベンチマーク実行結果」を参照してください。

最後に、前回のベンチマークで判明したクライアントスレッド数の最適値（8スレッド）を使用して、2台のマシン上で2時間のベンチマークを3回実行しました。

結果は、DetGCを有効にしたJRockitがスループットとレイテンシの両面で、IncGCを使用するSun JVMのパフォーマンスを上回ったことを示しています。JRockitはSun JVMより17%高速なパフォーマンスを達成しました。また、レイテンシが50ミリ秒を超えるオペレーションの比率については、Sun JVMのほうが5倍高い数値を示しました。また、DetGCなしのJRockitでは最大275ミリ秒のGC休止時間が報告されましたが、DetGCを有 効にしたJRockitで報告された最大のGC休止時間は、それをはるかに下回る約30ミリ秒でした（次に示すGC休止時間のグラフを参照）。

次の2つのグラフは、WLRTのJRockit JVMとSun JVMの性能差を示します。最初のグラフは、WLRTのJRockit JVMを使用した場合について、2時間のベンチマーク期間中のTraderアプリケーションのパフォーマンスを要約したものです。2番目のグラフはSun JVMを使用した場合のものです。それぞれのグラフで、上方の黒線はスループット（右目盛）を示します。下方の赤線と青線はアプリケーション応答時間（左 目盛）を示します。この値は小さいほどパフォーマンスが高いことを意味します。

図2：JRockit DetGC使用時のパフォーマンスを示す2時間のベンチマーク（画像クリックで標準サイズのスクリーンショットを表示）

図3：Sun IncGC使用時のパフォーマンスを示す2時間のベンチマーク（画像クリックで標準サイズのスクリーンショットを表示）

これらの実行の詳細なグラフは、「ベンチマーク詳細グラフ」で示しています。