Comments
Description
Transcript
テクてくLotus 技術者夜会 (ザ・アドミン編)
テクてくLotus 技術者夜会 (ザ・アドミン編) 2011/02/21（Mon）- Session 2 Server.load を使用した 日本アイ・ビー・エム株式会社 ソフトウェア開発研究所 Lotusコンサルティング - 第１ Lotus Domino サーバーのストレステスト 宮田 孝一 日本アイ・ビーエム株式会社 YSL. Lotusコンサルティング ロータスコンサルティング第二担当 日付フィールド 1 フッターフィールド 滝澤 光治 2011/02/21 （Mon） - Session 2 Agenda ストレステストの目的とポイント ストレステストの目的・効果 ストレステストのポイント Lotus Notes/Domino におけるストレステスト Server.load とは Server.load とは Server.load の特徴 組み込みスクリプト紹介 Server.load 実行のための設定 Server.load 操作 Server.load によるストレステストの実際 ストレステスト計画 ストレステストの準備 テスト実行時のポイント 結果の考察 レポート例 制限事項・注意事項 Server.load によるストレステストでのテクニック Server.load によるストレステストの実際 2 日付フィールド 2 フッターフィールド 2011/02/21 （Mon） - Session 2 Agenda Server.load 以外のストレステスト メールルーティング Web ストレスツール 3 日付フィールド 3 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステストの目的とポイント 4 日付フィールド 4 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステストの目的・効果 システム構築（変更）プロジェクトにおけるストレステストの一般的な目的 構築（変更）するシステムのサービスイン後に想定されるシステム負荷を、事前にシミュレーションする ことによって、以下のような検証を行う 1. キャパシティ・パフォーマンスの検証 キャパシティの限界や想定した高負荷時のパフォーマンスを確認することができる 2. 高負荷時の稼動確認 高負荷時にのみ発生する、環境特有の問題やサーバ構築における誤設定がないかなどを 事前に確認することができる 3. チューニングパラメータの事前チューニング チューニングパラメータは、最適値を机上で算出するのが難しいものがあり、実際に運用しながら 統計結果を元にチューニングしなければならないものもある パラメータを変更しながらストレステストを実施することで、ある程度の最適化を事前に実施する ことができる 5 日付フィールド 5 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステストのポイント シミュレーションであるため実際の環境・運用にどれだけ近づけることができるかが重要 インフラ環境 • • システムのハードウェア、OS、ネットワークなどのインフラ環境 できれば実際の環境を利用 データ • • 扱われるデータの量、内容 あらかじめ保持している分も考慮 ワークロード • • システムに対する負荷をシナリオ化、モデル化 作業量、多重度、タイミング 特にパフォーマンス・キャパシティに影響の大きなものを重視 とはいえ、テスト環境に制約があったり、データやワークロードは想定であったりすることもある 実際の環境との差異を明確にし、その影響を考察する 実績があれば取り入れること ピーク時の状況を想定する 想定より高い負荷でテストする、限界値を確認する、十分な余裕をもたせる 6 日付フィールド 6 フッターフィールド 2011/02/21 （Mon） - Session 2 Lotus Notes/Domino におけるストレステスト まずはテスト環境を以下のようなポイントについて実際の環境・運用にできるだけ合わせ用意する a. サーバーのハードウェア構成 できれば実際のハードウェアを利用 特に Lotus Domino サーバーはディスク I/O 性能に影響を受けやすいため、ディスクは容量よりも構成重視 b. サーバーのソフトウェア構成・設定 OS ・Lotus Notes/Domino のバージョン、パッチレベル Domino ディレクトリや notes.ini の各種パラメータ設定 ウィルスチェックツールなどのソフトウェアパッケージ・運用ツール c. サーバー上のタスクによる動作設定 サーバーエージェント、インデクサ、ジャーナリング設定、各種ログ取得設定など クラスタ複製やメールルーティングなどのサーバー間処理を実現するためには、相手サーバーが必要に 逆に夜間にテストを実施する場合など、夜間のメンテナンスタスクなどが動作しないように停止する 7 日付フィールド 7 フッターフィールド 2011/02/21 （Mon） - Session 2 Lotus Notes/Domino におけるストレステスト d. 取り扱うデータベースの設計内容 カスタマイズしたメールテンプレート データベースプロパティ、全文索引の有無 e. データベースの数、データ量 データベースの文書数、サイズ 保存する文書のサイズ、添付ファイル有無 f. ユーザーアクセス数や利用内容（ワークロードシナリオ） ユーザーアクセス数、要求内容、頻度 利用クライアント種類、プロトコル Lotus Notes/Domino におけるキャパシティ・パフォーマンスは Lotus Notes や Web ブラウザなどのク ライアントからの大量で非同期なユーザーアクセス負荷による影響が大きい ⇒ 想定されるユーザーアクセスを如何に実際に近付けられるかが特に重要となる ⇒ Server.load のようなツールを活用する 8 日付フィールド 8 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load とは 9 日付フィールド 9 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load とは Server.Load は IBM が提供する Lotus Domino サーバー用ストレステストツール Server.load は NotesBench から派生したツール 一般向けに GUI による操作性の向上やシンプルな構成でのテストを可能にしたもの ※ NotesBench は主にハードウェアベンダー向けに Lotus Domino サーバーのベンチマークテストを実施するた めに提供されるツール Domino Administrator のオプションとしてインストーラに同梱 カスタムセットアップのオプション 10 日付フィールド 10 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load とは ターゲットとなる Domino サーバーに対して、１台の PC から複数のクライアントアクセスに相当するセッ ションを確立し、ユーザーのオペレーション内容に相当する処理要求を送信 ND8 版では１PC あたり最大 2048 クライアント分のワークロードを実行 PC を複数用意することで、さらに多くのワークロードを再現可能 テスト対象の Lotus Domino サーバー （SUT＝ System Under Test） Server.load を導入した Lotus Notes クライアント PC （Test Driver） 最大2048 11 日付フィールド 11 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load の特徴 Domino サーバーに対するクライアントからの各種の要求をコマンド言語として提供 一般的な Domino サーバーの利用形態モデルをプログラミングした “組み込みスクリプト” （Built-In スクリプト）を用意 独自に一からコーディングしたり、組み込みスクリプトをベースとしてカスタマイズして 実行することも可能（“カスタムスクリプト”） Notes クライアントからの NRPC によるワークロード以外に、HTTP、POP3、LDAP、IMAP4の各インター ネットプロトコルによるシミュレーションも可能 NRPC によるストレステストツールとしては現状唯一のツール？ Web サーバーに対するストレステストツールはいろいろあるが、Domino Web Access（以下、DWA）のテストに ついては Server.load は非常に便利 • • • メールにアクセスするための URL は DB ファイル名や文書の UNID によって表現されるが、 メール DB はユーザー毎に異なり、メール文書の UNID が作成されるタイミングによって自動生成され 異なるため、自動操作が難しい Server.load では DWA 上での一般的なユーザー操作に相当する一連の HTTP 要求をセットで発行する 簡単なコマンドが用意されている 逆にコマンドとして用意された命令以外はできることが少ないため、メール以外のアプリケーションにつ いては一般の Web ストレスツールがお勧め ND8 からは SameTime サーバーへのワークロードもサポート 12 日付フィールド 12 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load の特徴 操作の間隔などを乱数によりばらつかせることで、ユーザーによる非同期でランダムな アクセス状況を表現することができる 例） ユーザーがメールの一覧を参照している時間やメール内容を記述している時間を考慮し、 メール文書を開く要求やメール送信など各要求の間にランダムな待ち時間（pause）を挿入する 送信するメールのサイズをいくつかの選択肢の中からランダムに選択する • SendMessage コマンドを「profile」引数をつけて実行した場合のメールの種類と選択割合 メッセージ本文のサイズ（ Byte） 添付ファイルのサイズ（ Byte） 選択率（％） 500 10 10,000 30 50,000 40 50,000 50,000 150,000 40 9.5 1,000 10,000,000 0.5 ※平均100KBになる これらにより、タイミングによって負荷が集中したり、分散したりする実運用に近い状況を再現 13 日付フィールド 13 フッターフィールド 2011/02/21 （Mon） - Session 2 組み込みスクリプト紹介 代表的な組み込みスクリプト（Built-In スクリプト） メールサーバーに対するワークロード “N7/N8 Mail Workload” • • Notes7 および 8 クライアントからの NRPC による Domino サーバーへのメールワークロード 以前のバージョンに比較し、より実際の Notes クライアントからの負荷に近くなっている • シナリオ内容：以下のようなオペレーションを平均１５分かけて実施し、ループする。 − 受信ボックスを開いて、スクロールする − 5 文書を読み取り、変数で指定したインターバル毎に 1 つのメッセージに返信 − 変数で指定したインターバル毎に 1 メールを送信（宛先数は変数で指定、 Domino ディレクトリで名 前を検索） − 変数で指定したインターバル毎に 1 メールを送信（宛先数は変数で指定、 Domino ディレクトリで名 前を検索） − 変数で指定したインターバル毎にカレンダーにスケジュールを追加 − 変数で指定したインターバル毎に会議召集を実施 − 1文書をフォルダに移動 − 会議召集に対し回答 − 2 文書を削除 − 最初にもどる 14 日付フィールド 14 フッターフィールド 2011/02/21 （Mon） - Session 2 組み込みスクリプト紹介 “R6 Mail Routing” • R4 時代からのシナリオであり、実際の Notes クライアントからの負荷に比較して軽い • シナリオ内容：以下のようなオペレーションを平均１５分かけて実施し、ループする。 − 受信ボックスを開いて、スクロールする − 5 文書を読む − 2文書を更新 − 変数で指定したインターバル毎に 1 メールを送信（宛先数は変数で指定、 Domino ディレクトリで名 前を検索） − 2文書を作成（ドラフト保存） − 変数で指定したインターバル毎にカレンダーにスケジュールを追加 − 変数で指定したインターバル毎に会議召集を実施 − 2 文書を削除 − 会議召集に対し回答 − ビューを閉じる − 最初にもどる 15 日付フィールド 15 フッターフィールド 2011/02/21 （Mon） - Session 2 組み込みスクリプト紹介 “R6 iNotes” • HTTP による DWA 利用のメールワークロード ※ ヘルプには iNotes6 テンプレートが前提となっているが、iNotes7 テンプレートでは実績あり、 8でも正しく動作するかは不明 “R6 IMAP” • IMAP4 および SMTP、LDAP による Domino サーバーへのメールワークロード “SMTP AND POP3 Workload” • POP3 および SMTP、LDAP による Domino サーバーへのメールワークロード “Cluster Mail” • • Notes クライアントによるフェールオーバーに対応したメールワークロード • 均衡化していない場合は “N7/N8 Mail Workload” をクラスタの各サーバーに実施する方が おすすめ クラスタサーバー間で MaxUsers や AvailablityThreshold による負荷均衡化を行っている際の シミュレーションに利用 16 日付フィールド 16 フッターフィールド 2011/02/21 （Mon） - Session 2 組み込みスクリプト紹介 アプリケーションサーバー系のワークロード “R5 Shared Database” • • Notes クライアントによるディスカッションテンプレートを想定した単一DBへの参照・書き込みを実施 作成する文書はタイトル（Subject）と本文（Body）のみであるため、カスタムアプリケーションに対するシミ ュレーションには不向き Sametime サーバーのワークロード “Sametime 70/75 IM Workload” • Sametime クライアントからの Sametime サーバーへの在籍確認、チャット利用による ワークロード（IM 機能のみ） そのほかに、各ワークロードの実行準備用 “Initialization Workload” あり メールDBをシミュレーションユーザー数分作成 初期メール文書の作成 所有者やACL設定などの初期化 などを実施 17 日付フィールド 17 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 実行のための設定 – SUTの設定 SUT（サーバー）の設定 Domino ディレクトリのサーバー設定 • • サーバー文書などのパラメータを実際の設計にあわせる テスト中に実行させたくないプログラム文書などは無効化しておく ユーザー文書の設定 • メールサーバーのテストでは、宛先として定型のユーザー名のユーザー文書を用意しておく − “mail[番号]” − 例） 1000ユーザーが登録されている環境をテストする場合 mail1、mail2、・・・、mail1000 • Domino サーバー付録のエージェント「namagent.nsf」を使用してユーザー文書の作成、設定が可能 − エージェントを Domino ディレクトリへコピー − 使い方は Administrator ヘルプの「Server.Load エージェント」を参照 • テストユーザー以外のユーザーへテストメールが配信されないように、その他のユーザー文書は 削除しておく − あらかじめ Domino ディレクトリはバックアップを取得しておくこと 18 日付フィールド 18 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 実行のための設定 – SUTの設定 Notes.ini の設定 • Administrator ヘルプを参照し、関連するパラメータを設定する 例） − Server_Pool_Tasks=100 − Server_Max_Concurrent_Trans=100 − SERVER_SHOW_PERFORMANCE=1 など 統計情報、ログ取得設定 • ストレステスト実施中の統計情報を取得するため、Events4.nsf を設定し、Collector タスクを 実行しておく • パフォーマンスモニターや、vmstat などの OS パフォーマンス統計情報の取得設定 サーバー間連携用のサーバー準備 • • メールルーティングやクラスタ複製などのサーバー間の処理を行うための相手側サーバーを準備 相手側からのメール送信や、複製などが実行されるようにする − 相手側にも Server.load でワークロードを実施する − エージェントなどで自動的にメールや文書の作成を行う 19 日付フィールド 19 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 実行のための設定 – Test Driver の設定 Test Driver （クライアント）の設定 ユーザーID • • SUTに対して管理者権限のあるユーザーIDを使用する セッションはすべてこの管理者IDによるものとなる ポートの設定 • ネットワーク圧縮を使う場合など注意 Notes.ini の設定 • • Administrator ヘルプを参照し、関連するパラメータを設定する スクリプト上に変数として指定しているものは、Server.load の GUI から変更可能 テンプレート、添付ファイルの配置 • DBを作成するシナリオを実行する場合、データディレクトリにテンプレートファイルを 配置しておく • メールで添付ファイルを指定する場合、指定する添付ファイルを配置しておく ※ Notes クライアントを使用して、対象のサーバーやDBに正しくアクセスできることを確認しておく 20 日付フィールド 20 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 操作 - Test Parameter タブ メインのテストパラメータ設定画面 スクリプトのコー ドを表示 テストのタイプ 実行するスクリプ トの指定 設定した内容で 実行準備 同時実行ス レッド数 スクリプトのルー プ回数 スレッドの起動間 隔 開始スレッド番号 実行時間方式の 選択 メール宛先などアド レスを自動選択す る際のDomino デ ィレクトリのパス 実行ログファイルの パス 21 日付フィールド 21 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 操作 – Stop Conditions タブ 途中終了する場合の条件を設定する画面 指定した回数タイ ムアウトを記録し た場合ワークロ ードを終了する 平均レスポンスタ イムが指定した値 を超過した場合ワ ークロードを終了 する 22 日付フィールド 22 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 操作 – Script Variables タブ スクリプト中の変数の値を設定する画面 クリックすると編集 可能 Notes.ini パラメー タとして保存される 23 日付フィールド 23 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 操作 – Command Line Screen タブ 「Manual」モードでスクリプトコマンドを実行する画面 テストタイプ で“Manual”を 選択 実行結果のログが 表示される コマンドを入力 し“Submit”で実行 24 日付フィールド 24 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 操作 – 状況表示画面 ワークロード実行中の統計情報取得設定・表示画面 記録したいDomino サーバーの統計値 を選択 レスポンスタイムを 記録したいコマンド を選択 ワークロードを開始 選択したコマンドのレ スポンスタイムや統計 値の最小・最大・平均・ 実行回数を表示 ワークロードを停止 実行ログ画面を表示 統計値を取得するサ ーバーを指定 統計値を記録する ファイルパスを指定 最近1分間のトランザ クション実行数や平均 レスポンスタイムなど の統計値を表示 タイムアウトの発生 回数を表示 テスト開始・終了時 刻を表示 ステータスを表示 25 日付フィールド 25 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 操作 – 実行ログ画面 ワークロード実行中のコマンド実行ログの表示画面 実行ログをリアルタイムに表示 • • 「>」で始まる行は実行したコマンド行の内容 それ以外は実行結果ログ 複数のスレッドによるログが非同期で表示される Test Parameter 画面の“Strage Test Output to”に指定したファイルにも記録される。 Pause ボタンで 表示を一時停止 26 日付フィールド 26 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load によるストレステストの実際 27 日付フィールド 27 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load によるストレステストの実際 ストレステストの流れ 1. 全体計画策定 2. シナリオ検討、パラメータ検討 現行環境における実績値の取得・分析 シナリオ妥当性の確認 3. 環境準備、スクリプト作成 4. 事前検証 計画したワークロードが問題なく動作するか、負荷は想定範囲かを確認 想定外の負荷である場合には、シナリオやスクリプトに問題がないか、妥当性を再検討 5. テスト実施、データ取得 6. 結果分析、考察 7. 対策実施、再テスト 28 日付フィールド 28 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステスト計画 時間がかかることを考慮したスケジュールを組むこと シナリオ検討のために実績値を取得・分析する期間が必要 テスト実施および結果分析にも時間・工数がかかる • • • １ケースの実行前準備と実行に２時間～６時間以上かかる 失敗・手戻りの無い様に事前検証期間を持つこと 最初に最も負荷の高いテストを実施し、問題がありそうかどうかの目処を見た上で詳細なテストを 実施することで手戻りを少なくする テスト結果に問題があった場合の調査・対応・再テストを実施するための期間を考慮 どんな評価をするか検討しておくこと 評価基準 • • レスポンスタイムやサーバーパフォーマンスデータの限界値、目標値の定義・合意 現行運用との比較 テストケース • • • ピーク時を想定 特性考察のために、構成やパラメータを変えたいくつかのケースを計画する リスクを考慮して、想定よりも大きな負荷のケースを実施 29 日付フィールド 29 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステスト計画 ワークロードシナリオの妥当性を検証すること すでに実績があれば送信メール数やメールサイズ、ピーク時のアクセスユーザー数、 ハードウェア統計、レスポンスタイムなどを確認しておき、テストパラメータに反映 どのような状態がピークなのか確認しておく 現行環境またはそれに近い構成の環境でワークロードを実行 • • ワークロード実行中の統計値が実際の運用に近くんるようテストパラメータを調整 ワークロードと実際の運用にどのような差異があるのかを確認 30 日付フィールド 30 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステストの準備 環境面の準備 前出のポイントを考慮して SUT 環境の設定 サーバー間処理も考慮 クライアントPCがネックにならないよう複数準備して分散させる 計測用、監視用のPCを別途用意する ネットワーク注意 • ストレステストでは運用中のネットワークに 影響を与えないために、サーバーの 存在するセグメントにテスト用PCを接続して ストレステストを実施するケースがあるが、 このときPCのネットワーク設定サーバー セグメントにあっているか確認すること。 • リンクスピードとDuplexが、 クライアント設定はAutoネゴシエーション、 サーバーは固定になっているケースが 多いため。 31 日付フィールド 31 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステストの準備 準備段階で少ないユーザー数で問題なく動作することを確認しておく サーバー、クライアントのログにエラーがないか メールが送信され、ただしくメールDBに配信されているか 統計情報が取得でき、テストによる負荷が反映されているか クライアントPCボトルネックの確認 １PCであまり多くのスレッドを実行したり、ワークロードの高いスクリプトでは、クライアントが ボトルネックとなって想定したワークロードがサーバーにかからないこともある スレッド数に比例してトランザクションが発行されることを確認しておく • 最初に少ないユーザー数でテストを実施し、１スレッド（１ユーザー）あたりのトランザクション数を確認し ておく • 多数のスレッドを起動した際に、１スレッドあたりのトランザクションが実行されているかを 確認し、クライアント側のボトルネックにより想定される要求がサーバーに行かないような ことがないことを確認 PCの能力やスクリプトの内容にもよるが、１PCあたり５００～１０００ユーザー（スレッド）程度までに抑えて、複 数のPCに分散して負荷をかけることをお勧め 32 日付フィールド 32 フッターフィールド 2011/02/21 （Mon） - Session 2 ストレステストの準備 パフォーマンスデータの取得準備 取得するためのツール、手順を整備しておく 取得データ 利用用途 OSパフォーマンス HWリソースの消費状況を確認し、ボトルネックの確認や負荷の原因調査に使用し データ ます。 Windows：パフォーマンスモニタデータ UNIX： vmstat、 iostat、netstat、sar、nmon（ AIXではお勧め） ノーツ統計情報 ノーツ内部リソース状況やアクセス状況から処理が正しく実施されていることの確認 と、問題時の調査に使用します。 オペレーションレスポ ンスタイム ベンチテスト実施中にノーツクライアントからいくつかのオペレーションを実施し、ストッ プウォッチで体感的なレスポンスタイムを確認します。 各種ログ 処理が正しく行われていることの確認と問題時の解析に使用します。 Server.load 統計 Server.load による平均レスポンスタイムから、サーバー全体のレスポンス状況を確 認します。 33 日付フィールド 33 フッターフィールド 2011/02/21 （Mon） - Session 2 テスト実行時のポイント 毎回初期化を行うのは時間がかかるので、初期化完了後のデータをバックアップしておく ドミノサーバー起動直後はエージェントマネージャーによるサーバーエージェントのチェックや、 スケジューラタスクによる空き時間情報DBの更新などが発生するので、起動後一定時間経過してからテ ストを行うとよい 夜間にテストをする場合など、プログラム文書などによるメンテナンスタスクなどが実行されないよう、設 定をはずしておく Server.load でドミノサーバー統計は記録しない Server.loadの機能として、サーバーの統計値を記録できますが、サーバー統計値は Collector タスクでサーバ ー上の Statrep.nsf に取得することをお勧め。 クライアントの負荷を抑えるため。 必ずレスポンスタイムを計測すること ツールにより負荷をかけた状態で、実際のクライアントから操作を行い、負荷状態でのレスポンスタイムを 確認する • • いくつかの異なる操作について計測する ユーザーの体感時間を測定する テスト結果として、サーバーのパフォーマンスデータや、Server.load で表示されるレスポンスタイムでは 問題なくとも、実際のユーザーオペレーション、あるいはその種類によっては問題になりうる 34 日付フィールド 34 フッターフィールド 2011/02/21 （Mon） - Session 2 結果の考察 キャパシティに問題がないかどうかの判断基準 想定される負荷が発生した際にパフォーマンスが低下しないこと • オペレーションレスポンスタイム ケース① レスポンスタイム 50KBのメール1通を受信する 50KBのメール20通を受信する 1MBのメール1通を送信する 50KBのメールを開く 50KBのメール1通を送信する 10MBのメール1通を送信する − あらかじめ設定した範囲である − 低負荷時と比較して劣化していない • 実行トランザクション数 − 実績が要求トランザクション数とほぼ同じ − 滞留が発生していない • 1MBのメール1通を受信する 50KBのメール1通を送信する 10MBのメール1通を送信する 1MBの添付ダウンロードする 1MBのメール1通を送信する 8.00 6.00 秒 4.00 2.00 − 低負荷時と比較して劣化していない サーバーハードウェアリソース使用率 0.00 0ユーザ − 性能を維持できる範囲 − 運用ポリシー上の許容範囲 1000ユーザ 2000ユーザ CPU Total YKHML203 2007/12/02 User% Sys% Wait% 100 − 枯渇しない、余裕がある 90 80 70 60 負荷のない状態でのレスポンスタイムなどを必ず 確認しておき比較するのがポイント 50 40 30 20 グラフ化して可視化する 10 35 日付フィールド 35 フッターフィールド 15:48 15:43 15:38 15:33 15:28 15:23 15:18 15:13 15:08 15:03 14:58 14:53 14:48 14:43 14:38 14:33 14:28 14:23 14:18 14:13 14:08 0 2011/02/21 （Mon） - Session 2 結果の考察 実環境とテスト環境に差異がある場合には、机上での補正を考慮する 差異の内容によってキャパシティ・パフォーマンスに影響する特性が異なるので注意が必要 例） • 全部で１０台あるメールサーバーのうち１台についてテストを実施し、ネットワークの負荷は テスト結果の１０倍になると考察する。 ⇒ OK • CPU性能が実環境の５０％のサーバーでのアクセス限界をテストし、実環境ではテスト結果の ２倍のアクセスを許容できると判断する。 ⇒ 危険！ 何がボトルネックになりそうかを考慮 机上での計算の場合誤差を考慮する必要がある • • 安全率、余裕率を考慮 補正すべきファクターが多いほど誤差が大きくなる 特に Lotus Notes/Domino では一定のユーザー数を超えると急激にパフォーマンスが悪くなる 36 日付フィールド 36 フッターフィールド 2011/02/21 （Mon） - Session 2 結果の考察 複数のテストケースを実施し、ケース間の差異によるシステム特性を考察しておく 実環境との差異を補正するための特性を確認 想定以上の負荷発生時のケースを実施し、想定外の場合のリスクを考慮して余裕率を決定する パフォーマンスが急激に悪くなる状態まで負荷を高くし、対象システムではキャパシティ限界がなにに 依存するのかを確認しておく パラメータを変更してテストを実施し、その結果の変化を確認する 例） • • アクセスユーザー数を変化させてテストを実施、ユーザー数によるCPU 稼働率の変化を確認する LPAR の 割り当て CPU を変化させてテストを実施、アクセス数限界とCPU能力との関係を 確認する 必要に応じてチューニングを実施する ボトルネックが判明した場合、そのリソースの増強や節約するためのチューニング 限界値が判明した場合、限界値を超えないように同時セッション数などの制限を設定する チューニング実施後に再テストを行い、効果や副作用がないことを確認する 37 日付フィールド 37 フッターフィールド 2011/02/21 （Mon） - Session 2 レポート例 事例サンプル紹介 事例A • • • プロジェクト内容 対象システム構成 考察ポイント ：Lotus Notes Domino バージョンアップ ：メールサーバー（クラスタ）および掲示板サーバー ：SW、HW構成変更によるサーバーキャパシティ確認 事例B • プロジェクト内容 • • 対象システム構成 考察ポイント ：Lotus Notes Domino バージョンアップ （Webメールの使用開始、ジャーナリング開始） ：メールサーバー（クラスタ）および勤怠アプリサーバー ：SW、HW構成変更によるサーバーキャパシティ確認 データセンタ移設によるWANネットワークキャパシティ確認 事例C • プロジェクト内容 • • 対象システム構成 考察ポイント ：Lotus Notes Domino バージョンアップ （POP→DWAによる利用形態変更） ：メールサーバー ：SW、HW構成変更によるサーバーキャパシティ確認 （POP・DWAの混在期間を含む） 38 日付フィールド 38 フッターフィールド 2011/02/21 （Mon） - Session 2 制限事項・注意事項 Server.load ツールにおける制限 Server.Load のコマンドは、ノーツクライアントでのユーザーオペレーションそのものには一致しておらず、 オペレーションによって発生するサーバーへの処理要求（NRPCファンクション）に近いレベルのコマンドも ある。 • カスタムスクリプト作成の際には、ユーザーオペレーションによってどのような要求（NRPCファンクション） がサーバーに送信されるかを分析する必要がある。 • 例えば、あるデータベースのアクションボタンをユーザーが押すということをシミュレーションしたい場合、 この「ボタンを押す」というコマンドを実行できるのではなく、ボタンに設定された式などによってサーバー に対してどのような処理要求が行われるのかを分析し、その内容をスクリプト化する。 Server.Load のコマンドは、ノーツクライアントによるサーバーへの全ての処理要求やパラメータをサポートし ていない。このため、シミュレートできる内容には制限がある。 • • 例えば、文書の作成のコマンドでは、特定のフィールド情報のみを持った登録できない アプリケーション独自のフォームに従ったアイテム情報をもつ文書の作成を行うコマンドはない Server.Load のスクリプト言語では、条件処理などのフロー制御機能は充実しておらず、複雑な プログラムをコーディングすることはできない。 用意されているが動作しないコマンドもある（特にIMAPやWebメール） 39 日付フィールド 39 フッターフィールド 2011/02/21 （Mon） - Session 2 制限事項・注意事項 ストレステスト実行における注意事項 負荷の高いスクリプトを1台で多数実行したり、長時間実行するとダウンすることもある • • 耐久テストには向かない 複数のPCで分散を 1分より短い間隔でパフォーマンスデータを取らない • 1分おきに実施されるサーバー内部処理があり瞬間的に高いディスク稼働率が発生するため、 スナップショットでデータを取得すると、グラフにしたときに異常な形に見えてしまう。 CPU Total notes124 User% Sys% Wait% 100 80 60 40 20 14:03 13:58 13:54 13:49 13:45 13:40 13:36 13:31 13:27 13:22 13:18 13:13 13:09 13:04 13:00 12:55 12:51 12:46 12:42 12:37 12:33 12:28 12:24 12:19 12:15 12:10 12:06 12:01 0 Time of Day クライアントによるオペレーションレスポンスタイムは同じ人が実施した方がよい • • 同じ「文書を開く」でも人によって体感基準が異なる 1秒未満のレスポンスとなるものもあるので、数値として比較すると大きな差異になってしまう 40 日付フィールド 40 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load によるストレステストでのテクニック 実行を効率化する組み込みスクリプトのカスタマイズ 無限ループにして手動で停止する • • 実行時間が見えないため Rewind コマンドの引数をなしにする イニシャライズ部分は消してしまう • イニシャライズがすんだ状態でデータのバックアップを取っておく 固定でよい変数はスクリプト内でハードコート • 各PCで設定しなくてよくなる ユーザー文書だけ作成して、他サーバーへのメールを実装 他のサーバーへメールルーティングさせる場合、ホームサーバーを他サーバーにしたユーザー文書をエージ ェントで作成。他サーバー側のメールDBはユーザー数分は用意せずに共通化することもできる。 Driver PC 立ち上がりの切れ目でレスポンスタイムを計測 いくつものオペレーションに対するレスポンスタイムを計測するには時間がかかるため、アクセス数を順次増 加させるような場合に測定の最初の方と後の方で負荷状態が異なってしまう。 Driver を順次起動するようにし、Driver のスレッドが一通り起動したところで計測、計測終了後次の Driver を 起動する、というように、Driver に設定するスレッド数を切れ目として測定するとよい。 41 日付フィールド 41 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load によるストレステストでのテクニック カスタムアプリケーションに対するカスタムスクリプトの作成 標準のディスカッションテンプレート以外のカスタムアプリケーションに対するワークロードを作成するには できることが限られているため、以下のような工夫が必要 組み込みスクリプトやヘルプにあるサンプルを参考に ClientClock を使って NRPC ファンクションレベルで比較してみる • • クライアントの notes.ini に以下のパラメータを設定すると、NRPC通信毎にファンクション名やレスポン スタイムなどの情報が表示・記録される。 − Client_Clock=1 （通信ログを表示する） − Debug_Console=1 （コンソール画面が表示され、通信ログが表示される） （ログを指定したファイルに記録する） − Debug_Outfile=[ファイルパス] 実際のオペレーション実行時のファンクションを確認し、Server.load でもワークロードを実行した 場合のログを記録して比較する。 文書の作成に関しては内容やアイテムを指定できない • 文書の作成のみ適当な間隔で行うエージェントを用意し、Server.load と並行して実行する 42 日付フィールド 42 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load によるストレステストでのテクニック ClientClock 設定時のクライアントコンソールサンプル (3-24 [3]) OPEN_DB(CN=Server1/O=IBM!!mail\test.nsf): (Connect to Server1/IBM: 187 ms) (Exch names: 0 ms)(Authenticate: 0 ms.)(OPEN_SESSION: 18 ms) 26 ms. [78+270=348] (4-24 [4]) ISDB2_RQST: 17 ms. [18+20=38] (5-24 [5]) GET_UNREAD_NOTE_TABLE: 18 ms. [82+1128=1210] (6-24 [6]) OPEN_NOTE(REP49256ADB:00220A21-NTFFFF0010,03000400): 18 ms. [52+1034=1086] (7-24 [7]) OPEN_NOTE(REP49256ADB:00220A21-NTFFFF0010,03400000): 19 ms. [52+788=840] (8-24 [8]) GET_NOTE_INFO: 18 ms. [22+106=128] (9-25 [9]) GET_NAMED_OBJECT_ID($profile_024archive database profile_): 17 ms. [68+28=96] (10-25 [10]) OPEN_NOTE(REP49256ADB:00220A21-NT00008A0A,00400020): 17 ms. [54+200=254] (11-25 [11]) OPEN_COLLECTION(REP49256ADB:00220A21-NT000005C6,0060,4008): 21 ms. [106+56=162] (12-25 [12]) POLL_DEL_SEQNUM: (Connect to D19ML102/19/M/IBM: 34 ms) (13-25 [12]) GET_COLLATION: (OPEN_SESSION: 17 ms) 16 ms. [16+18=34] 17 ms. [72+40=112] (14-26 [14]) READ_ENTRIES(REP49256ADB:00220A21-NT000005C6): 84 ms. [68+3478=3546] 43 日付フィールド 43 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load によるストレステストの実際 トラブルの事例 一定のユーザー数を超過するとレスポンスがなくなる • キャパシティオーバー − CPU100%、ディスク稼働率100% − 単一データへのアクセス集中過多によるセマフォ待ち • Domino障害 − CPU性能の高いサーバーで、頻繁に新規メール受信を行うと新着通知の処理が IOCP の セマフォ待ちで滞留し、他の処理が受け付けられなくなる（R5における障害） • 設定ミス ２台の同スペックサーバーでテストを実施したが、パフォーマンスが異なる • ディスクの構成が異なっていた • − 同じSANストレージであるが、ボリュームの構成が異なっていた Dominoの障害 − 同じ構成の HW であるが、CPU の個体差による微細な速度差が影響し、レスポンスが悪い ことがある（R5における障害） 問題の対策後に再テストを実施することにより、問題の解消を確認できる 44 日付フィールド 44 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 以外のストレステスト 45 日付フィールド 45 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 以外のストレステスト メールルーティング負荷テスト メールハブサーバーや SMTP MTA 用サーバーなどのメールが集中するサーバーで想定メール量を処 理できるかの検証 エージェントやシェルスクリプトなどを用いて自動的に大量のメール発信を行う Server.load でも可能であるが、メール送信だけであればエージェント等の方が無難 検証ポイント メールの滞留が発生しないか • タイミング的に一時的な滞留は発生するので、一定時間継続して実施し、滞留メールが蓄積していかな いことを確認 • メールの送信元や送信先のサーバーで滞留していては意味が無いため、これらのサーバーは複数に分 散するなどの考慮が必要、計画量が送受信されていることを確認する • エージェント側がボトルネックになるような場合、サーバーの Router タスクを停止しておき、mail.box にメ ールを溜めて、Router の起動により送信させるような方法も 46 日付フィールド 46 フッターフィールド 2011/02/21 （Mon） - Session 2 Server.load 以外のストレステスト Web ストレスツールによる Web アプリテスト Webアプリケーションは一般的なストレスツールも使用可 Server.load でできるのは指定した URL をGETする程度 ただしメール系のテストなどユーザーによってアクセスするDBが異なる場合に、文書IDは異なるので アクセスする文書のURL指定を考慮する必要がある DWA のテストは Server.load がお勧め HTTP リクエストログを取得する際に、Domlog.nsf に記録すると各リクエスト毎にレスポンスタイムが記 録される テキストファイルの場合レスポンスタイムは記録されない ただし、DBへの記録はテキストログに比べて負荷が高いので注意 47 日付フィールド 47 フッターフィールド