Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

検証作業が明らかにした「WebLogic+仮想化」の
潜在力・前編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
検証作業が明らかにした「WebLogic+仮想化」の潜在力・前編
nPar0で動作する負荷生成ソフトウェアでは、以下のシナリオでオンラインショッピングをシミュレートする。
  1. トップページを表示する
  2. サイトにログインする
  3. 商品カタログを表示する
  4. ショッピングカートに商品を追加する
  5. 商品を購入する(2回に1回の割合で)
  6. 購入履歴を確認する
  7. サイトからログアウトする
検証作業が明らかにした「WebLogic+仮想化」の潜在力・前編
WebLogicの呪縛を仮想化技術が解放する
オンラインショッピングのシナリオ
この一連の流れを実行するスレッドを複数個生成することで、負荷を再現する仕組みである。同時スレッド数(多重度)を増やすことで、nPar1のWebLogic Serverにかかる負荷も上昇する。今回は、図5のような負荷パターンでテストを実施した。
 
負荷パターン
図 5:負荷パターン
  図5に示すように、一般ユーザについては120個のスレッドで一定の負荷を生成し、プレミアユーザについては段階的に負荷を変化させる。これにより、「プレミアユーザの負荷が上昇した場合でも一定のサービスレベルが維持できるか」を明らかにする。

サービスレベル低下への対処法

まずは、仮想化技術のワークロード分配を使わない状態でのパフォーマンス計測結果を紹介しよう。 図6は、一般ユーザとプレミアユーザそれぞれのレスポンス時間の変化を示したグラフである
 
「仮想化なし」の場合のレスポンス時間
図6:「ワークロード分配を利用しない」場合のレスポンス時間
  図6のグラフは、縦軸がレスポンス時間(ms)、横軸が経過時間(sec)である。グラフの左側を見るとわかるとおり、WebLogic Serverの負荷が低い状態では、いずれのユーザも20 ms程度でレスポンスを受け取ることができ、サービスレベルは良好に保たれている。一方、時間の経過とともにプレミアユーザの負荷が上昇すると、一般ユーザとプレミアユーザ双方のレスポンス時間が長くなり、高負荷時には70 ms程度になる。つまり、ユーザがレスポンスを得るまでに3倍以上の時間を要している。これは一般ユーザに対しては仕様どおりの振る舞いと言えるが、プレミアユーザに対してはサービスレベルを維持できておらず、仕様を満たしているとは言えない。

【HP Workload Manager(WLM) によるサービスレベルの確保

仮想化によるCPUリソースの配分
図7:WLMによるCPUリソースの配分
図6のテストでは、一般ユーザとプレミアユーザの両方に対して、nPar1のCPUリソースが均等に配分されていた。それがプレミアユーザのレスポンス低下の原因である。これを解消する手段としては、アプリケーション・サーバ内部でメッセージ・キューイングなどを実装し、プレミアユーザからのリクエストを優先処理するような実装も可能だろう。または、スレッドやプロセスの優先度を調節する方法もある。しかし冒頭でも述べたとおり、アプリケーション・サーバはハードウェアの制限を超えることはできない。これらの手法も、一度CPUリソースが枯渇してしまえばあまり意味をなさなくなる。

これに対し、それぞれのユーザに一定のCPUリソースを占有させ、その配分比率を負荷状況に応じて調整できれば、プレミアユーザのサービスレベルを一定に保つことができる。仮想化技術の導入により、こうしたCPUリソースの動的配分――つまりソフトウェアによるハードウェア性能の制御――が可能になる(図7)。
  つづく後編では、仮想化技術のWLMの導入がWebLogic Serverのパフォーマンスにどのような影響を与えるのか、検証結果を紹介する。
トップへ 戻る    

その他のコラム(特集)もお読み下さい

 
 

本ページの内容は執筆時の情報に基づいており、異なる場合があります。
印刷用画面へ
プライバシー ご利用条件・免責事項