jmeterを用いたlotus domino web アプリケーションの...

© 2011 IBM Corporation

JMeterを用いた Lotus Domino Webアプリケーションのパフォーマンス計測

2011/09/21Lotus Technical Update Workshop

⽇本アイ・ビー・エムシステムズ・エンジニアリング株式会社コラボレーション・ソリューション岡本茂久


JMeterを⽤いたLotus Domino Webアプリケーションのパフォーマンス計測

2

このセッションのGOAL

LotusDomino のWebアプリケーションのパフォーマンステストを⾏うにあたって、実際のユーザー動作を再現した負荷をLotus Dominoサーバーにかけられること！

？



3

アジェンダパフォーマンステストについて

負荷テストツールの役割

JMeterによるLotus Domino Webアプリのテスト計画

Tips 〜より良いテスト計画のために



4

パフォーマンステスト（性能テスト）でシステムの性能を知ろう！

パフォーマンステストの必要性

Web化開発したアプリがLotus Notesクライアントからのアクセス時より重い……サイジング通りのシステム構成なのにユーザーアクセスが増えるとダウンする……チューニングの必要性を感じるがどこがボトルネックかはアクセス負荷を再現しないと分からない……



5

パフォーマンステストについてパフォーマンステストシステムがお客様のパフォーマンス要件を満たしているか

検証する⼈⼿や負荷テストツールでアクセス、動作を検証ボトルネックの発⾒、分析、除去

→レスポンスタイム、リソースの使⽤状況（CPU使⽤率、メモリ使⽤量、ページング率、

ディスクI/O）

負荷テスト⾼い負荷のかかった状況下でのシステムの性能を検証する

ピーク時やそれ以上の負荷状況下でのシステムの動作検証飽和点を超えても安定したシステムであることの確認

→レスポンス、リソースの他にスループットも測定



6

いつパフォーマンステストを⾏うかアプリ開発の単体テストの他、サービスイン前の総合テストの中で⾏われることが多い

パフォーマンス（性能）要件……⾮機能要件から抽出

サイジング（システム構成決定）

システムの評価（パフォーマンステスト）

チューニング

サービスイン

構築…開発…単体テスト……



7

スループット：単位時間当りの処理量スループット：

５件 / 秒システム要件

レスポンスタイム：１アクセス当りの応答時間レスポンスタイム：３秒

ユーザー要件

ピーク時の同時ユーザーアクセス数900⼈のうちの70%がアクセス

= 630ユーザー

パフォーマンステストの指標あれこれ多くはキャパシティ・プランニン

グの際に性能要件として定義される

特にスループットは、マシンスペック（CPU能⼒）に直結する

ユーザーのページ遷移における平均 ThinkTime （思考時間） ThinkTime ：7分ユーザー要件



8

同時ユーザーアクセス数

パフォーマンス値

例スループット︵件/

秒︶

レスポンスタイム︵㍉秒︶

70006000500040003000200010000

システムの飽和点

「パフォーマンスが良い」とは？飽和点における最⼤同時ユーザー数が多いレスポンスタイムが短いスループットが⾼いシステムリソースが効率良く使⽤されている（CPU、メモリ、ディスク）

適切にチューニングされたシステムでは飽和点を超えてもスループットはほぼ⼀定の値を⽰す

参考：スループット、レスポンスタイム曲線

最⼤同時ユーザー数

スループット曲線レスポンスタイム曲線

同時ユーザーアクセス数

パフォーマンス値

例スループット︵件/ 秒︶


70006000500040003000200010000

スループット曲線適切なスループット曲線レスポンスタイム曲線

リソース増強

チューニングの必要性

チューニングされていないシステムでは最⼤同時ユーザー数を超えるとレスポンスタイムは急激に下がる。

最悪のケースではサービスダウンをもたらす



9







10

負荷テストに実際に必要なユーザーを集めることは困難パラメーターやユーザー数を変えて繰り返しテストを⾏う必要がある

⼤量のトランザクションを擬似的に⽣成し、サーバーに負荷をかける

本番時と同等の負荷状況下でのパフォーマンスを測定

どうやってテストするの？〜負荷テストツールの役割

サーバー

負荷⽣成のシナリオ

リソース監視

・負荷⽣成・パフォーマンス測定

クライアント


JMeterを用いたLotus Domino Webアプリケーションのパフォーマンス計測

11

Lotus Domino付属のツールではコンテンツ書き込み系のテストがWebで出来ないので、無償のJMeterを今回選択

負荷テストツールの選定

◯◯☓参照系（GET）のみ

使用するプロトコルのサポート（今回HTTP）

テスト結果の分析補助

作成したシナリオの実⾏とテスト結果の記録

仮想ユーザー数、実⾏スケジュールの設定

テストシナリオの作成・保存

必要となる機能

◯グラフ作成

△グラフは自作

△グラフは自作

◯◯◯

◯複数ユーザー可能

◯複数ユーザー可能

△固定ユーザーのみ

◯プロキシでユーザー操作トレース

◯プロキシでユーザー操作トレース

△スクリプトの作成

負荷テスト製品（有償ライセンス）

無償ツールLotus Domino管理クライアントに付属している

IBM Rational Performance Tester

Apache JMeterServer.Load



12

Apache JMeterとはApache Jakarta プロジェクトにより開発されている、フリーで100% Javaのパフォーマンス・汎⽤テスト⽤ツール。 http://jakarta.apache.org/jmeter/v2.5 が最新（2011/08時点）複数のスレッドを同時に起動して多重度による負荷をかけることが可能。プロキシサーバー機能でブラウザ動作をキャプチャーしてテストシナリオを作成可能。



13

JMeterを⽤いたテストの流れJMeterのダウンロード・インストール

JMeterの起動

テスト計画の記録・スレッドグループの作成・プロキシ機能でブラウザ動作を記録

zipの解凍のみhttp://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

bin/JMeter.bat で起動

様々な部品、結果確認機能が⽤意されている

JMeterでテスト実⾏

結果の分析

テスト計画のカスタマイズ・リクエスト内容のカスタマイズ、パ

ラメーター、ログファイル定義・テスト計画の保管（JMXファイル）

レポートやグラフの検討またはCSVファイルをExcelなどで加⼯

ブラウザのリクエスト内容が⾃動記録されてシナリオのベースとなる

JMeter

定義したループをすべて終えるか、「停⽌」で終了

JMeter



14

JMeterテスト計画の作成例（1/4）① テスト計画（テストシ

ナリオ）作成の準備・スレッドグループの作成・HTTPプロキシサーバー

の追加

② HTTPプロキシサーバーの開始

（デフォルトでポート番号は8080）



15

JMeterテスト計画の作成例（2/4）③ Webブラウザのオプションでプロ

キシサーバーの使⽤を設定する

④ テスト対象にするWebアプリケーションにアクセス、テストシナリオのユーザーの⾏動を実施する



16

JMeterテスト計画の作成例（3/4）⑤ Webブラウザー上の⾏

動内容がHTTPリクエストのエレメントとして記録される

・プロキシの停⽌

⑥ 必要に応じてシナリオを調整・不要なリクエスト要素の除去（gifなど）・リクエストのグループ化、条件追加・リクエスト内容の変数化・タイマ（待ち時間）やリスナー（結果表⽰）

の設定： etc.



17

JMeterテスト計画の作成例（4/4）

⑦ 編集したシナリオを保存して、テスト計画を「実⾏」＞「開始」

⑧ テスト結果の検討・レスポンスタイムやス

ループット、エラーは発⽣していないか

・必要に応じてシナリオを修正して再実⾏

・ログをExcelなどでグラフ作成

：etc.



18







19

Lotus Domino Webアプリパフォーマンステストシナリオ例検索対象DB ：ディスカッションテンプレート(discsw7.ntf)によるDBユーザー：100⼈参照系テスト：1,000⽂書（アクセス権による⾮表⽰有り）、セクションのある

ビューから⽂書を３つ閲覧、添付ファイルをダウンロード投稿系テスト：タイトル、本⽂を含んだ⽂書を３つ投稿、添付ファイルもアップロード

Lotus Dominoアプリ利⽤形態の特徴として、・重たくなりがちなビュー・ユーザーによる投稿はぜひテストに含めたい！

HTT

P



20

シナリオ例１．参照系テスト①アプリケーションのURLにブラウザでアクセス②認証ダイアログ（フォーム認証ならログインページ）が出て認証が求められるのでテストユーザーIDでログイン③ナビゲーターの「カテゴリ別」をクリックしてカテゴリ別ビューを表⽰

④カテゴリセクションのAを開く⑤⽂書１を開く⑥ナビゲーターの「カテゴリ別」をクリックしてカテゴリビューに戻る⑦カテゴリセクションのAを閉じる

⑧カテゴリセクションのBを開く⑨⽂書２を開く⑩添付ファイルのダウンロードを⾏う⑪ナビゲーターの「カテゴリ別」をクリックしてカテゴリビューに戻る⑫カテゴリセクションのBを閉じる

⑬カテゴリセクションのCを開く⑭⽂書３を開く⑮ナビゲーターの「カテゴリ別」をクリックしてカテゴリビューに戻る⑯カテゴリセクションのCを閉じる

⑰（ブラウザを閉じる）……特にJMeterからのリクエストはなし



21

参照系シナリオのテスト計画例

テスト計画

スレッドグループ

HTTPヘッダマネージャ

タイマ

統計レポート（リスナー）結果をツリーで表⽰グラフ表⽰

HTTPプロキシサーバ（Non-Testエレメント）

HTTPリクエスト（サンプラー）

ロジックコントローラ

HTTP認証/クッキーマネージャ（設定エレメント）

ユーザーパラメータ（前処理）

⼀連のリクエスト要素をコントローラでグループ化

左ペインで選択された要素の設定値



22

シナリオ例２．投稿系テスト①アプリケーションのURLにブラウザでアクセス②認証ダイアログ（フォーム認証ならログインページ）が出て認証が求められるのでテストユーザーIDでログイン

③「新規⽂書を作成」をクリック④⽂書１を保存（タイトル、カテゴリ、本⽂）⑤ナビゲーターの「カテゴリ別」をクリックしてカテゴリビューに戻る

⑥「新規⽂書を作成」をクリック⑦⽂書２を保存（タイトル、新カテゴリ、本⽂）⑧ナビゲーターの「カテゴリ別」をクリックしてカテゴリビューに戻る

⑨「新規⽂書を作成」をクリック⑩⽂書３を保存（タイトル、カテゴリ、本⽂、添付ファイルのアップロード）⑪ナビゲーターの「カテゴリ別」をクリックしてカテゴリビューに戻る

⑫（ブラウザを閉じる）……特にJMeterからのリクエストはなし



23

投稿系シナリオのテスト計画例

⼀連のリクエスト要素をコントローラでグループ化

左ペインで選択された要素の設定値

投稿する添付ファイル



24

テスト計画：テストシナリオの単位。JMXファイルとして保存できるスレッドグループ：テストシナリオをプロパティに設定した値で実⾏

できる。⼀つのテスト計画に複数のスレッドグループを作成可能

同時に発⽣させる仮想ユーザー数

スレッドの開始時間遅延 = ユーザーの投⼊間隔

スレッドを何回実⾏して終了か？

開始 / 終了時間を設定可能

JMeterテスト計画の要素（例 1/9）

ユーザー1ユーザー2：ユーザー100

ユーザー投⼊におけるRamp-Up期間のイメージ

経過時間Ramp-Up期間



25

URL （サーバー名、パス）情報

ログイン時のユーザーパラメータ（フォーム認証時）

ロジックコントローラ：複数のリクエストをまとめることができる。実⾏条件などを指定可能

→複数アプリへの同時アクセスシナリオや、シナリオ分岐に便利例）IFコントローラ、シンプルコントローラ、ランダムコントローラ、ルー

プコントローラ……HTTPリクエスト：実際にアクセスするURL、

パラメーターが記述されるHTTPヘッダマネージャ：Referer情報など含む




26

ユーザーパラメータ：POST処理で投⼊する定義パラメータ（ユーザーID、ページID、検索ワードなど）を設定できる。HTTPリクエストから変数として呼び出せる

→複数ユーザーがログイン認証するWebアプリケーションで必須！

「繰り返しごとに更新」にチェックすることで、スレッドごとに違うユーザーとして振舞える


HTTPリクエスト初期値：HTTPリクエストに設定するサーバー名、ポート番号、プロトコルなどを初期値として別設定できる

→HTTPリクエスト内で空⽩になっている個所はこちらの設定が挿⼊される

→異なるサーバー環境にテスト計画を持っていくときに使える場合がある



27

HTTPクッキーマネージャ：ブラウザと同様にCookieを保存して、以降のリクエストに⽤いることができる。 →フォーム認証（Cookieでセッション管理）に必須


「繰り返しごとにクッキーを破棄」にチェックしていないと、次のスレッド（＝異なるユーザー）で同じセッションIDのクッキーが使われてしまう！

ここには何も設定しなくてもよい。

HTTP認証マネージャ：基本認証のアプリケーションへのログインの場合はこちらを⽤いる

ユーザーを複数登録する場合には「ユーザーパラメータ」に設定して変数として呼び出す（後述）



28

参考：認証形式と対応エレメントサーバー設定⽂書の「インターネットプロトコ

ル」>「DominoWebEngine」＞HTTPセッション＞セッション認証で設定

・「無効」（デフォルト） → 基本認証・「単⼀サーバー」 → フォーム認証・「複数サーバー（SSO）」→ LTPAなどによる

シングル・サインオン

ACL付きアプリにアクセス

認証ダイアログ（基本認証）認証ページ（フォーム認証）

/names.nsf?Login のHTTPリクエストでユーザー設定

でCookie管理にログインユーザー設定



29


タイマ：次の処理に⾏く前にポーズする間隔を設定できる。いわゆるThinkTimeに相当。例）定数タイマ、⼀様乱数タイマ、定数スループットタイマ…

ThinkTimeそのもの。ここでは3 秒。設置した階層で振舞いが異なる

JMeterの表記バグ。単位は（サンプル数/分）が正しい

スループットを指定すると、結果的にそのような負荷になるようにThinkTimeを調整してくれる。

テストでは、本番ユーザーの分だけ仮想ユーザー / スレッドを⽤意することは困難なので、実際に⽤いるスレッド数と、ThinkTimeの間隔を調整することで、想定した⼤規模ユーザーがアクセスしているのと同じ負荷がシステムにかかっているものと解釈することがある



30


統計レポート：JMeterのリスナー（レポート機能）の⼀つ

各リクエストをラベル名で表⽰→ラベルは⾒やすい名前に編集

しておいた⽅がよい

# Samples ：試⾏スレッド数（=x⼈⽬のﾕｰｻﾞｰｱｸｾｽ）Average ：レスポンスタイムの平均値Median ：同中央値90% Line ：同90%の値が収まっている範囲Min ：同最⼩値Max ：同最⼤値Error % ：エラー発⽣率（401、404など）Troughput ：スループットKB/sec ：データ転送量

リクエスト毎の各指標をリアルタイムに書き換えて表⽰する。テストを継続しても重くならない。

→本番テストでお勧め！

デフォルトのログ出⼒はXMLなのでExcelで解析する場合は設定でCSVに変更しておく



31


・あまり美しくない。・性能が頭打ちになる様⼦は判る。・単位がリクエスト/分であって、

page/secのグラフが欲しくてもカスタマイズできない。

・テストを継続すると描画が重くなる。

→デバッグの時だけ使える →カスタマイズグラフはログから

⾃作するしかない

このサンプル数はスレッド数（＝同時ユーザー数）ではなく、全リクエストの累算単位に注意（リクエスト / 分）

スループット曲線がリアルタイムに得られるが……

グラフ表⽰：JMeterのリスナーの⼀つ。スループット曲線をリアルタイムに表⽰する



32


結果をツリーで表⽰：JMeterのリスナーの⼀つ。各リクエストの結果、リクエスト内容、応答データの内容が確認できる。・認証エラーなどは⾚で表⽰。 →POST（コンテンツ投稿）が失敗しても⾚になるわけではない

ので注意！・POSTパラメータの確認・返答のHTMLが確認可能・テストを継続すると激重。やがてはJMeterがフリーズする→デバッグショットではお薦め

各リクエストの詳細情報を表⽰

リクエストに対する HTTP応答コード、LTPAトークン、セッションIDなどが確

認できる



33

JMeterテスト計画の要素（例 9/9）結果をツリーで表⽰（続）

応答データのHTMLを確認

POSTデータを表⽰（フォーム認証のログインユーザーID/パス

ワード）



34

テスト結果ファイル・CSV / XMLファイル・デフォルトの拡張⼦は.jtl

経過時間リクエストのラベルスレッド名成功/失敗 … レスポンスタイム HTTPステータスデータモード …

「数値」表⽰に直す

UTF-8形式なので⽂字化け

エディタなどでSJISに変換保存してから開く

桁を略表記



35

参考：サーバーリソース観測結果例：CPU使⽤率

エディタなどで変換参照系テストにおけるCPU負荷（nhttpサー

ビス）

投稿系テストにおけるCPU負荷（nhttpサービス）

(％)

(hh:mm:ss)



36

参考：リソース監視ツールWindows パフォーマンス・モニター

– Windowsに付属の監視ツール– 「スタート」⇒「コントロールパネル」⇒「管理ツール」⇒「パフォー

マンス」で起動– ⾮常に多くの種類のカウンタ（計測項⽬のこと）が⽤意されている– コマンドでの実⾏例：

typeperf "¥Process(*)¥% Processor Time" "Memory¥Available Bytes" >c:¥temp¥perF.csv

※AIXやLinux環境のツール：nmon、nmon analyser、topas



37

ここまでのまとめ

Webアプリの負荷テストツールである Apache JMeter は LotusDomino の Webアプリにも使えそうだ。

複数ユーザーのログインや、ビューの閲覧、添付ファイルのアップロード・ダウンロードといった重たい処理もテスト対象にできそう。

これならサーバーに負荷をかけられそう！



38







39

シナリオ記録の時点でコントローラーにまとめておく

デフォルトでワークベンチにリクエストが記録されるけど、後で整理するのが⾯倒…

予めスレッドグループにロジックコントローラーを置いておき、そこに記録させると扱いやすい！



40

パラメーターを外部ファイル読み込みにする複数ユーザー登録

できるのはいいけど、100⼈も1000⼈も⼿作業で登録はたいへん……

パラメーター（csv or txt）

JMeter関数のStringFromFileで定義可能

ユーザー群を分けたり、検索語や投稿コンテンツなどにも応⽤可能



41

アクセス権を反映したテストシナリオにするには

１つの同じシナリオだと、ユーザーによってアクセス許可が異なるコンテンツにアクセスした場合エラーになってしまう……

コントローラー

コントローラー

ユーザーAログイン⽂書１を開く

ユーザーBログイン⽂書２を開く

IFコントローラーユーザーAだったら実⾏

⽂書１を開く

ログイン

IFコントローラーユーザーBだったら実⾏

⽂書２を開く

ロジックコントローラーを使ってシナリオを個別にしたり分岐したりできるんだ！



42

参考：複雑なシナリオ例

ログイントップ全社⼈事部

ログイントップ全社

通達便利営業ログアウト

ログイントップ全社

⼈事部

営業部

その他の社員

10回ループ

⼈事部のIDならなら

実⾏

営業部のIDならなら

実⾏10回繰返

し

ユーザー認証処理



43

POSTリクエストが空振りの結果になることがある……なぜ？

トラブルシュート：JMeter経由でコンテンツ投稿に失敗する？！（1/3）

Webブラウザから直接だと投稿できる⼿順が……プロキシ経由だとInternalServerError（ResponseCode500）に終わるプロキシ経由だと添付ファイルのアップロードに失敗し、java.io.FileNotFoundExceptionが表⽰されるプロキシ経由ではうまく投稿できているが、JMeter上でシナリオを実⾏すると投稿できていない

： etc…

？JMeter



44

POSTのHTTPリクエスト⾃体は記録されているので……対応策１．「□Browser-compatitble headers」オプションをチェックし

てみる（プロキシで記録されたデフォルト状態ではチェック無し）

プロキシ経由でNGでもテスト実⾏でうまくPOSTされることがあるJMeterのバージョン2.4 ではPOSTがうまく再現できないバグがあったBug 50684 Optionally disable Content-Type and Transfer-Encoding in Multipart POSThttps://issues.apache.org/bugzilla/show_bug.cgi?id=50684最近出たバージョン2.5 （モジュールの⽇付が 2011/8/17）ではリクエストに上記のheaders

オプションが付き、この問題が回避されるようになっている




45

対応策２．プロキシ経由だと添付ファイルのパスがうまく記録されないことがある

⼿動でHTTPリクエスト中のファイル名を修正すると改善

対応策３．タイプミスなどで認証処理のユーザーID/パスワードがうまく設定されていない可能性がある

フォーム認証の場合、リスナー「結果をツリーで表⽰」でログインのPOST内容のユーザーID/パスワードを確認できる




46

参考：Dominoサーバー側でHTTPリクエストのPOSTのログを取る

HTTPEnableThreadDebug=1HTTPEnablePostDataLogging=1

Notes.ini ファイルを編集して次の２⾏を追記し、サーバー再起動

HTTP リクエストログが有効になり、クライアントから要求されるPOST データのロギングが⾏われる。出⼒ファイルは<Domino_root>/Data/IBM_TECHNICAL_SUPPORT/ の下にhtthr_<pid>_<tid>_<YYYYMMDD@HHMMSS>.log

*** New Request -- Parse and Check Request: Session 384, Thread 508, Clock 57990296POST /discuss7_test.nsf HTTP/1.1Connection: keep-aliveCookie: DomAuthSessId=0552757B4EA48E8137BB51286A1BCA97;SessionID=CY02EEUK52Accept-Language: ja,en-us;q=0.7,en;q=0.3Host: dom852.japan.ibm.comAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Keep-Alive: 115 ：



47

参考：Dominoサーバー側でユーザーセッションを確認する（フォーム認証の場合）

コンソールで tell http show users とタイプ

テスト前：ユーザーなし

テスト直後のユーザーセッション

管理クライアントのサーバー> ステータス >インターネットユーザーでも同等の情報が確認できる



48

負荷ツールのマシンがスペック低い… →分散環境でJMeter実⾏設定は⾮常に簡単：コントローラーでJMeterを起動し、「全て開始（リモート）」で開始するスレーブ側は、コントローラーからRMI経由で依頼を受け、負荷テストを実⾏してマスターにデータを送付する

jmeter.properties を編集してスレーブマシンのIPアドレスを記述する

スレーブ１・負荷⽣成

スレーブ２

スレーブ３

コントローラー・シナリオ実施・ログの集計

JMeter-Server を起動。rmiregistryも同時起動。

（JMeterの起動は必要無い）

コントローラーの負荷が思った以上に⾼い……

代替案：複数のマシンをスケジュー

ラで同時開始する（ログのマージは⼿作業）



49

参考：パフォーマンス指標の設定値の考え⽅（例）性能要件例

12.3 page/sec⽬標スループット

6ページ →ThinkTimeは10分= 600秒

ピーク時１時間での平均ページ遷移数

6,300 （9,000⼈の70%）ピーク時間の同時ユーザーアクセス数

スレッド数：6,300ThinkTime（ミリ秒）：600,000

30 スレッド実施が限界のクライアントが３台しか⽤意できない

スレッド数：30 * 3台ThinkTime（ミリ秒）：約

8,600

＊画像ファイル、JSファイルなどの扱いを検討しておく

１．省く２．⼀緒に分析する →１シナリオで 10ページ

70リクエスト

定数タイマを⽤いる場合定数スループットタイマを⽤いる場合

⽬標のスループットが 12.3 →多めの負荷を検討 →15 page / sec

30 スレッド実施が限界のクライアントが３台しか⽤意できない

(15 page / sec) / (30 スレッド) / (10 page)

* (70 Request) * (60sec) = 1台に設定するスループット= 210 リクエスト/ 分

30スレッド

スレッド遅延8,600ミリ秒

ターゲットスループット210 リクエスト / 分



50

参考：ログからスループット、レスポンスタイム曲線を算出する（例）

＊シナリオ全体のスループット :統計レポートのスループット合計値（Request / 秒） * ページ数 / リクエスト数で求まる。

ページごとのスループット、レスポンスタイムのグラフ化：Excelやテキストファイル抽出ツールを⽤いて算出を⾏う

同じリクエストが同じ秒台に発⽣している個数を調べる（ピボットテーブルなど活⽤）

結果ファイル分析したいページごとに作成

飽和点

200.0820.00:05

⼈事部ページ（/appli01.nsf/xxxx）

:::

150.120:00:0450.240:00:0330.10:00:01

リクエスト発⽣回数個数（=スループット）

レスポンスタイム平均（ミリ秒）

経過時間（秒）

経過時間（ユーザー暫時追加）

スループット︵件/

秒︶


スループット曲線レスポンスタイム曲線

上記の表を元にグラフ化する



51

クライアント描画負荷を極⼒避けるために「グラフィック無しモード」で実⾏するには？

コマンドラインから実⾏可能（GUI無し）> jmeter.bat -n -t Test.jmx（テスト計画定義ファイル） -l log.csv（ログ出⼒先）→「統計レポート」が確認できない……→分散環境での実⾏もできない……

まだJMeterの動作が重い……⼀部のリスナーは⾮常に重いので、シナリオのデバッグ時のみに⽤いるべき「グラフ表⽰」「結果をツリーで表⽰」

→「統計レポート」は重くならないのでお薦めJMeter⾃⾝のメモリチューニング項⽬がある

起動スクリプト（$JMETER_HOME/bin/jmeter.bat）を編集 Javaヒープの⼤きさを⼤きくする

例） set HEAP=-Xms256m -Xmx256m

表記バグに注意。すでに使⽤が推奨されていないコントローラーなどもある最新のバージョン、マニュアルを参照のこと

その他のTips



52

•Apache JMeter は⾮常に⾼機能な無償の負荷テストツールで、Lotus Domino のWebアプリケーションのテスト要件にも充分に応えることができる

•しかし、以下のことは考慮すべき：•ツールの各要素の特徴や、独特のパフォーマンス指標の扱いかたには慣れておく必要がある•出⼒機能（グラフ化など）が貧弱なのでデータの加⼯に⼯数がかかる→ デバッグの⽀援能⼒は⾼いが、肝⼼のパフォーマンステスト結果がリアルタイムで得られないことも

まとめ

ライセンスが調達できるのであれば、リアルタイムのレポーティング機能が充実しているIBM Rational Performance Tester の利⽤もお勧め



53

Apache JMeter Userʻs Manual (コンポーネントリファレンスなど充実)http://jakarta.apache.org/jmeter/usermanual/index.html

JMeter Distributed Testing Step-by-step (PDF) http://jakarta.apache.org/jmeter/usermanual/jmeter_distributed_testing_step_by_step.pdf

JMeterの基本 JMeter -TECHSCORE-http://www.techscore.com/tech/ApacheJakarta/JMeter/1.html

JMeterガイドhttp://wiki.livedoor.jp/susatadahiro/d/Index

J2EEパフォーマンス管理の勘所http://www.atmarkit.co.jp/fjava/rensai2/j2eeoprmng01/j2eeoprmng01.html

nmon と nmon analyserhttp://www.ibm.com/systems/jp/power/techinfo/aix/nmon/

参考⽂献（1/2）



54

Domino 6：HTTP リクエストログの仕様についてhttps://www.ibm.com/support/docview.wss?uid=swg21467436

Using Server.Load to evaluate and enhance IBM Lotus Domino server performance：http://www.ibm.com/developerworks/lotus/documentation/domino/d-ls-serverload/index.html

Dominoアプリケーションのパフォーマンスに関する考慮事項（PDF）http://www.ibm.com/jp/support/redbooks/Lotus/SG88851100.pdf

Lotus Notes/Domino 7 アプリケーションのパフォーマンス: 第2部:データベースのビューの最適化http://www.ibm.com/developerworks/jp/lotus/library/notes7-application-performance2/index.html

Lotus Domino Webサーバーのパフォーマンス・チューニングと問題判別http://www.ibm.com/developerworks/jp/lotus/ldd_tech/2010apr23_domino.html

参考⽂献（2/2）



55

Questions？

jmeterを用いたlotus domino web アプリケーションの...

Documents