by Razeyah Stephen and Rich Buck
レベル：中級者
対象：Domino 5.0
原文の掲載：2002年1月2日
顧客の関心が非常に高いiNotes Web Accessの導入について、パフォーマンス・チームの2人がRnext プロジェクトの仕事を少し休んで、iNotes Web Accessのパフォーマンスについて調べた結果を皆様に紹介します。この記事では、パフォーマンス・ラボにあるいくつかのハードウェア構成において、R5iノーツのワークロードをかけたときのベンチマークのピーク値について検証します。ここで取り上げるハードウェア構成は、パフォーマンス・チームがe-メールや会議で受けた質問、コメントを参考にして選びました。
またこの記事では、 R5iノーツ・ユーザーのドミノ サーバーに対する負荷についても議論し、R5Mailのユーザーによる負荷と比較します。そして1つのサーバーに対して、両方のユーザーが混在している場合に何がおきるかを示します。それにより、パフォーマンス向上のために有用なコツを紹介します。
iNotes Web Accessは、 Web ベースでドミノのメッセージングやPIM (Personal Information Management) の機能にアクセスするための次世代 Web クライアントです。iノーツは優れたユーザー・インターフェースを備え、ドミノ・オフライン・サービス (DOLS) を利用して情報へのオフライン・アクセスを提供します。 iNotes Web Accessは、ドミノのリリース5.0.8の一部として、Windows 2000、Windows NT SP4、Solaris、pSeries (AIX)、iSeries (AS/400)、zSeries (S/390) といったプラットフォーム向けに2001年第2四半期に出荷されています。また、今後のドミノのリリースにおいて、LinuxとHP-UXにも対応する予定です。
iNotes Web Accessは、お客様からの要望の最も多いHTTPメッセージングを含め、下記のような多くの特長を備えています。
- 未読マークのサポート
- 豊富なビュー・マネジメントのユーザー・インターフェース
- メッセージのスペルチェック機能
- 無制限添付ファイル
- ビューのバーチャル・スクロール
- 改良されたカレンダー・ビュー
- グループ・カレンダー機能
- カレンダーの出力機能の充実、PDF 形式での出力
- Sametime チャット・インテグレーション
- 新着メール通知
- アーカイブ作成
- 不在通知エージェントのサポート
- タスク・ガント・チャート・ビュー
- メールおよびカレンダー&スケジューリングのアドレッシングに対する名前の確認と解決 (5.0.9の場合)
iNotes Web Accessはブラウザー・ベースのクライアントなので、管理やユーザー・トレーニングの手間が減り、展開も容易になっています。
パフォーマンス機能
iNotes Web Accessのパフォーマンス機能は次のとおりです。
- フォームやサブフォームのサーバー側でのメモリー・キャッシング
- サーバーにおける全ユーザー間の設計要素の共有
- ブラウザーの最適なキャッシングのためのHTTP ヘッダーの取り扱い
- ブラウザーへ送信する JavaScript コード全ての圧縮 ( 例えば、コメントの削除や識別子の長さを短く変更するなど )
- 外部スクリプトのスタティック・コードを最長1年間ブラウザーでキャッシング
- 外部スクリプトの変数データを最長1年間あるいはデータが変化するまでブラウザーでキャッシング
- ダイナミック HTML の利用によりページ全体の再読込を減らし、任意のページ・トランジションを避ける。
- カスケーディング・スタイル・シートの利用により、 HTML ページのサイズを減らす。
- スタティック・コード用の共有フォーム・ファイルへのURL の利用により、プロキシー・サーバーでの効率的なキャッシングを実現。
NotesBench Consortium（US）は、ベンダーがドミノの種々のハードウェア構成における性能を測定できるようにワークロード集を提供しています。これらのワークロードでは、 IMAP や NRPC や HTTP 等の種々のメッセージング・プロトコルが利用できるようになっています。NotesBench コンソーシアムが利用するワークロードのなかに、 R5Mail ワークロードと新しい R5iNotes ワークロードの2つがあります。前者は、ノーツ・クライアント・ユーザーをシミュレートし、後者はiNotes Web Accessを使って Web からドミノ・メールにアクセスするユーザーをシミュレートします。
NotesBench R5iNotes ワークロードは 5.0.8 で導入されました。このワークロードがかける負荷を次に列挙します。
- 15分ごとに1人のユーザーが、以下の作業を行ないます。
受信ボックスを開く
1番目のメッセージを読む
1番目のメッセージを削除する
2番目のメッセージを読む
3番目のメッセージを読む
4番目のメッセージを読む
5番目のメッセージを読む
-
6回の繰り返すたびに、そのユーザーが次の作業を行ないます。
新しいメッセージを作成する
宛先に3名を設定する
そのメッセージを送信する
なお、ワークロードにはカレンダーとスケジュールの負荷は含まれません。
下に、数種類のハードウェア構成における内部ピーク・ベンチマークの結果を示します。これはパフォーマンス・ラボでの測定結果です。 R5iNotes ワークロードを利用して測定しました。この結果は公式のものではなく、また NotesBench のメンバーの監査を受けたものでもないことに注意してください。公式発表されているNotesBench レポートは、NotesBench Consortium（US）の Web サイトから入手できます。さらに、以下の各点にも気を付けてください。
- 全てのテストは1秒以下の応答時間を示しています。これは、私達にとって許容できる応答時間が1秒以下であるということです。 ( NotesBench が公式に発表したレポートでは、許容できる応答時間は5秒以下となっています。 ) そのため一度に250人のユーザーを追加していく場合、平均応答時間が1秒以下になる範囲で最大の人数を使っています。このことは以下のグラフを見るとはっきり分かります。
- 表示されている応答時間の値は、サーバーから要求されたデータ全てがクライアントに届くのにかかる時間です。これはサーバーの処理時間全てとネットワーク転送速度を含みますが、クライアントがそのデータを処理したり変換したりするための時間は含みません。
- 利用した構成において、ディスク・システムとメモリーがなんらかの妨害による遅延を受けることはないので、これに関する計測結果は含まれていません。
- これらの構成においてRAID 0 を使っていますが、これは指定できるディスク・ドライブの台数が限られているためです。ハードウェア・ベンダーが発表した公式の NotesBench レポートでは、利用の自由度を高めるために RAID 0 + 1 や RAID 5 等を利用しています。有用な構成の詳細については、NotesBench Consortium（US）の Web サイトにあるレポートを参照してください。
ピーク・ベンチマークの情報を利用する際には、私達が特定のプラットフォームを比較、推奨しているわけではないことに注意してください。ここに示す結果は、パフォーマンス・ラボにある異なるハードウェア・システムに対する R5iNotes ベンチマークの結果のピーク値です。
また、ここのベンチマーク値は標準ワークロードに基づいてユーザーをシミュレートしていますので、お客様のハードウェア構成およびドミノの使い方に固有のキャパシティー・プランニング情報についてはベンダーにお問い合わせください。この記事の最後に URL を載せてありますのでご利用ください。
IBM RS/6000 Server S80, OS: AIX 4.3.3
はじめに RS/6000 Server S80 のピーク・ベンチマークを示します。
データはSSA ループ2つに1ループあたり15の9GB ドライバーを利用したものです。各ドライバーは1つの RAID 0 論理単位として設定されています。
このテストでは、メモリー容量および負荷を処理するためのバンド幅が十分で、バランスのとれたハイエンド・サーバーを利用しています。グラフから、ユーザーが 6000 人のあたりから、 CPU 利用率は飽和し、応答時間が増加し始めていることが分かります。
IBM RS/6000 Server B80, OS: AIX 4.3.3
このデータは RS/6000 サーバーでリソースが少ない場合のものです。
データはSSA ループ2つに1ループあたり15の 9GB ドライバーを利用したものです。各ドライバーは1つの RAID 0 論理単位として設定されています。
B80 は小規模な AIX サーバーですので、ユーザー数が2500 のところで CPU が飽和しています。
IBM Netfinity Server 8500R, OS: Windows 2000 SP1
8500R はハイエンドの Netfinity サーバーです。これを反映したベンチマークとなっています。
1つにつき9台の 9GB ドライバーをもち、 RAID 0 論理単位として設定された3つの EXP 200 についてのデータです。
このハイエンド・サーバーでは、ユーザーが 4500 人でも1秒以下の応答時間で快適です。ユーザー数が 4500 のときに、 CPU は飽和し、応答時間が増加しました。
IBM Netfinity Server 5500 M20, OS: Windows 2000 SP1
5500 M20 はミッドレンジ Netfinity サーバーです。結果は次の通りです。
2つのEXP 15で、それぞれが9台の 9GB ドライバーをもち RAID 0 論理単位に設定されているときのデータです。
5500 M20 では、ユーザーが 2750 人でも1秒以下の応答時間で快適です。2750 人のときに、 CPU は飽和し、応答時間が増加しています。
IBM Server zSeries Model 2064-116, OS: z/OS V1R1
これらの結果は、 IBM zSeries パフォーマンス・チームが彼らのラボで測定して得たものです。
データ・ディスクは、 Shark Enterprise Storage Server に載せてあります。ボリューム毎に HFS が2つあります。各ボリュームは、 2.4GB のディスクで、各 HFS は 1.2GB です。メール・データベースは、 204 のボリュームを利用して 408 の HFS に均等に分配されています。
IBM s/390 Server Turbo G5, OS: z/OS V1R1
IBM zSeries パフォーマンス・チームが彼らのラボで測定した初期の結果を示します。これらのテストは、古いハードウェアに対して行なわれました。このタイプのハードウェアをお持ちで、 iNotes Web Accessを展開したいとお考えのお客様のためにこの結果を記載しています。
データ・ディスクは、 RAMAC Enterprise Storage Server に載せてあります。ボリューム毎に HFS が2つあります。各ボリュームは、 2.4GB のディスクで、各 HFS は 1.2GB です。メール・データベースは、 25 のボリュームを利用して 50 の HFS に均等に分配されています。
次に、 iNotesを使っていて分かったテストの結果を紹介します。R5iNotes ユーザーがドミノ サーバーに対して発生させる負荷に注目し、それを R5Mail ユーザーが発生させる負荷と比較します。さらに、同じサーバーで両方のユーザーを混在させたときに起こる現象について紹介します。
私達が取り上げる結果は、 NotesBench ベンチマーク・ツールを使って様々な人数の R5iNotes あるいは R5Mail のユーザーをシミュレートして得たものです。これにより、サーバーに一貫した負荷を繰り返しかけ、ハードウェアや構成の違いによる影響を調査することができます。以下の表での「ユーザー数」とは、ベンチマーク・スクリプトの同時実行数であり、必ずしもサーバーでの実際のユーザー数に対応するものではありません。
分かりやすくするために、以下の数値は全て同じ Netfinity 4-way サーバーを使って測定した値となっています。これは最近の標準によればミッドレンジ・サーバーといえます。また、これは最大あるいはピーク・ユーザー・テストではなく、サーバーにほどほどの負荷をかけて行ったテストであることに注意してください。
| プロセッサー |
4x 500MHz Pentium III Xeon |
| メモリー |
2.5GB |
| ドミノ・データ・ディスク |
2x EXP 15 RAID 0 アレイ それぞれディスク9台 |
| ネットワーク |
100MHz 全二重 Ethernet |
| OS |
Windows 2000 server |
| ドミノ |
5.0.8 |
|
ドミノは、特に明記しない限り、 NOTES.INI ファイルのデフォルト設定でインストールされています。1つ違うところは、サーバー文書でHTTP スレッド数を 90 に設定しているところです。この理由については、「チューニングについて」のセクションで取り上げます。
サーバーに対して負荷を発生させるために、それぞれに 512MB のメモリーをもつ 800MHz PIII ドライバーを接続して利用しました。この種類のドライバーは、 1000 以上の NotesBench ユーザーを容易にシミュレートできます。これらのテストにおいて、1つのテストにつき 10 までのドライバーを使用しました。
観察
まずはじめに、 R5iNotes ユーザーの人数を増やすときのサーバー・リソース利用法の詳細についていくつか説明します。このサーバーは、約1秒以内の応答時間で 2500 の NotesBench 仮想ユーザーをサポートできます。
| ユーザー数 |
1,000 |
1,500 |
2,000 |
2,250 |
2,500 |
| 応答時間 (秒) |
0.5 |
0.5 |
0.5 |
0.6 |
1.0 |
| 応答時間 (秒) |
27.64 |
41.09 |
57.3 |
67.32 |
78.87 |
| 利用可能容量 (MB) |
1,919 |
1,784 |
1,591 |
1,438 |
1,298 |
ディスク
bytes/sec |
354,539 |
362,600 |
564,780 |
1,206,454 |
2,328,928 |
ネットワーク
bytes/sec |
332,238 |
410,688 |
598,482 |
670,016 |
753,381 |
|
iNotesは単純なブラウザーをクライアントとして利用しています。その結果、以前ならノーツ・クライアントで行なわれていた処理は大部分がドミノ サーバーに移っています。つまり、アクティブ・ユーザー数に比例して CPU 利用が増加するので、 CPU が最終的に限界を決めるリソースとなっています。メモリー、ネットワーク、ディスクの利用の程度はどれも比較的低く、このサーバーでは問題となりません。
これらの数値と比較するために、同じサーバーを使って、 R5Mail ワークロードを利用した場合の結果を示します。このワークロードは R5iNotes ワークロードにとてもよく似ていますが、カレンダーと予定表のイベントがいくつか加わっています。ご予想のとおり、高機能なノーツ・クライアントで処理しているときは、ドミノ サーバーがサポートできるユーザー数は多くなります。この場合、 R5Mail ユーザーが 6000 人でも1秒以下の応答時間を実現できます。
| ユーザー数 |
1,000 |
2,000 |
3,000 |
4,000 |
5,000 |
6,000 |
| 応答時間 (秒) |
0.1 |
0.1 |
0.1 |
0.1 |
0.2 |
0.3 |
| CPU 利用率 |
5.9 |
12.04 |
18.65 |
25.63 |
33.39 |
41.79 |
| 利用可能容量 (MB) |
1,310 |
1,202 |
1,117 |
995 |
859 |
691 |
| ディスク bytes/sec |
1,096,268 |
2,875,250 |
4,622,897 |
6,343,839 |
8,271,697 |
10,546,564 |
| ネットワーク bytes/sec |
115,319 |
239,785 |
358,773 |
478,997 |
557,688 |
667,086 |
|
サーバーの観点から見ると、 R5iNotes ユーザーの基本的な特性は、 R5Mail ユーザーの場合より CPU 利用が増えるということです。また、iNotes Web Accessは生データだけよりも多くクライアントにデータを送る必要があるため、ネットワーク・トラフィックがおおよそ2倍になることが分かります。ブラウザーでデータをきれいに表示するために JavaScript を送る必要があるのです。それに加えて、ブラウザーに対して送信するデータは ASCII テキストでなくてはなりません。これは、バイナリー・データを送る (ノーツ・クライアントなら利用できる方法です。) ほど効率の良い方法ではないのです。
利点は次の通りです。メモリー使用量が R5iNotes クライアントでは減少し、ディスクから読みとるデータの量も減少します。これは、 iNotes Web Accessのユーザーは共通の設計要素を共有し、ドミノ サーバーはそれらをより効率的にキャッシュできるからです。
iNotes Web Accessのユーザーを、すでに R5 のメール・ユーザーを抱えているサーバーに追加するためには、どのような対策をとればよいのでしょうか。主なものは、 CPU の能力およびネットワークのバンド幅を追加することです。次の表は、 R5iNotes ユーザーと R5Mail ユーザーの混在したワークロードに対するサーバーの応答を示しています。最初のテストでは全ユーザーの 25% が R5iNotes ワークロードを実行して、次のテストでは、全ユーザーの 50% が R5iNotes ワークロードを実行しています。残りは R5Mail ワークロードを実行しています。
| ユーザー数 |
1,000 |
2,000 |
3,000 |
4,000 |
5,000 |
| 応答時間 (秒) |
0.1 |
0.1 |
0.2 |
0.3 |
0.5 |
| R5iNotes ユーザーの応答時間 (秒) |
0.3 |
0.4 |
0.5 |
0.6 |
1.2 |
R5Mail ユーザーの
応答時間 (秒) |
0.1 |
0.1 |
0.1 |
0.1 |
0.2 |
| CPU 利用率 |
11.53 |
24.98 |
37.67 |
55.63 |
71.81 |
| 利用可能容量 (MB) |
1,420 |
1,159 |
1,018 |
876 |
741 |
ディスク
bytes/sec |
1,000,064 |
2,693,818 |
4,561,753 |
6,634,726 |
8,374,760 |
| ネットワーク bytes/sec |
160,732 |
319,892 |
460,958 |
607,691 |
733,699 |
|
混在したワークロードでの実行結果と、先に示した R5Mail ユーザーのみのデータとを比較してみます。R5iNotes の割合が 25% の場合、ユーザー数 4000 のところを見ると、 CPU 利用率が 26% から 56% へ倍増していることが分かります。また、ネットワーク利用率が 478997 bps から 607691 bps へ増加していることも分かります。さらに、サーバー・リソースの必要性が高まったために、サポートされる ( 応答時間が約1秒の ) ユーザーの最大人数はおおよそ 5000 人に減ることも分かります。
| ユーザー数 |
1,000 |
2,000 |
3,000 |
4,000 |
| 応答時間 (秒) |
0.2 |
0.2 |
0.3 |
0.5 |
R5iNotes ユーザーの
応答時間 (秒) |
0.3 |
0.4 |
0.5 |
0.9 |
R5Mail ユーザーの
応答時間 (秒) |
0.1 |
0.1 |
0.1 |
0.1 |
| CPU 利用率 |
17 |
35.86 |
57.5 |
81.95 |
| 利用可能容量 (MB) |
1,575 |
1,223 |
1,114 |
1,010 |
ディスク
bytes/sec |
808,688 |
2,045,142 |
4,129,333 |
5,598,383 |
ネットワーク
bytes/sec |
206,385 |
371,177 |
560,131 |
755,129 |
|
R5iNotes ユーザーの割合が 50% へ増加すると、ユーザー数が 4000 人の場合で CPU 利用率が 82% 、ネットワーク利用が 755129 bps にまで増加していることが分かります。サポートされるユーザーは 4000人を若干越える程度で、この人数は R5Mail クライアントだけの場合の約3分の2となっています。もちろん、この比率はハードウェア構成に強く依存します。このケースでは、 CPU 能力は十分であり、主にディスク・バンド幅に制約を受ける R5Mail サーバーで行ないました。
データの別の見方は、ユーザーが一人増えたときにサーバーのどのリソースの必要がどのように変化するかを試して確かめることです。これにより異なるワークロードのもつ負荷の相対的関係が分かり、ある規模のユーザー数をサポートするために、どのような能力がサーバーに必要かという問題に対する大まかなイメージを得ることができます。サーバー・リソースの変化を、 R5Mail や R5iNotes ワークロードのユーザーの増加数で割ると、以下の情報が得られます。
右記の範囲での
平均リソース使用量 |
R5iNotes 2500人から1000人 |
R5Mail 6000人から1000人 |
R5iNotes 対 R5Mail の比 |
| CPU 利用率 (%) |
0.034 |
0.009 |
3.8 |
| 使用メモリー容量 (MB) |
0.41 |
0.15 |
2.7 |
| ディスク bytes/sec |
1,316 |
2,363 |
0.56 |
| ネットワークbytes/sec |
281 |
138 |
2.03 |
|
この環境の場合、R5iNotes ユーザーを R5Mail サーバーに1人追加すると、ノーツ・クライアントと比べてCPU が約4倍、メモリーが約3倍サーバーに必要であることが分かります。前のデータでは、純粋に R5iNotes ベースのサーバーは初期状態のメモリー消費が少ないために、ユーザーあたりのメモリー消費が比較的大きいことが相殺されていました。さらに、ネットワーク・トラフィックの増加はおおよそ2倍ですが、ディスク利用は半分にすぎません。
これはベンチマークの結果であって、予測するための一般的な指針にすぎないことを忘れないでください。現実には、ユーザーがベンチマークを実行することはなく、現実の環境での結果はラボで得た結果とは違ってしまいます。
チューニングはシステムのある部分から借り物をして、別の部分の弱点を補強するということです。私達がこれらのテストに使ったもののようにハードウェアがバランスのとれたものであったら、ドミノのデフォルトの構成に加えるべき変更はほとんどないでしょう。私達のテストから、 iNotes Web Access・サーバーがもっとも必要とするものは CPU の能力であるという傾向がわかります。したがって、 CPU の必要性を減らすことが、その方法が見つかればの話ですが、 iNotes Web Access・サーバーをチューニングする際にもっとも有効な方法です。
一般に推奨されているチューニング法が iNotes Web Access・サーバーにおいてどのような影響をもつかを確かめるために実験を重ねてきました。2000人のアクティブな R5iNotes ユーザーに対する結果を次の表に示します。もっとも有力な方法は、 HTTP スレッド数を、全てのユーザーが確実に接続できる最小値へ調節することです。このケースでは、スレッド数 90 がちょうど良いようです。HTTP スレッドが 40 でワークロードが同じ場合、ユーザーの多くが1回目の接続に失敗しています。また、 HTTP スレッドが 256 の場合、全て順調ですが、 CPU 利用率が 7% 増えています。
| |
応答時間
(秒) |
CPU
利用率
% |
利用可能
メモリー容量 MB |
ディスク bytes/sec |
| HTTP スレッド数 90 |
0.5 |
57.3 |
1,591 |
564,780 |
| HTTP スレッド数 256 |
0.5 |
64.29 |
1,537 |
780,525 |
| HTTP スレッド数 40 |
0.5 |
52.95 |
1,683 |
608,621 |
バッファー・プール
50% 増加 (1120) |
0.5 |
56.22 |
1,529 |
505,633 |
バッファー・プール
50% 減少 (375) |
0.5 |
59.54 |
1,714 |
542,716 |
NSF_DBcache_
MaxEntries = 3100 |
0.5 |
56.13 |
1,602 |
555,461 |
| Web 認証がオンのとき |
0.5 |
61.14 |
1,595 |
540,011 |
デフォルトのサーバー・
タスクが全て有効なとき |
0.5 |
58.72 |
1,313 |
1,142,466 |
|
NSF バッファー・プールのサイズと NSF_DBcache エンティティーの個数を変更することも試しましたが、メモリーやディスクのバンド幅が本当に制約になっているわけではないので、効果はほとんどありませんでした。ユーザーに対する Web スタイルの認証をオンにすると、データベースのために CPU 利用率は 4% 増加しました。先に示した結果は、 Web 認証が有効でない場合の値です。
通常、ベンチマークでは、測定に絶対必要なもの以外全てのタスクを無効にします。これは、アップデートのようなことが発生するときに数値が突然飛ぶのを防ぐためと、実現可能な最高値がいくつなのかを示すために行なっています。R5iNotes 測定に対しては、ルーターと HTTP タスクを走らせています。一方、 R5Mail に対しては、ルーター・タスクのみを走らせています。
他のタスクの影響について質問を受けることが多いので、最後のテストで NOTES.INI ファイルで有効に設定されているデフォルトのタスクを全てそのままにしました。この場合に重要なことは、利用可能メモリー容量が大幅に減ることおよび、その結果としてオペレーティング・システムによるディスク・キャッシュのために使えるメモリーが減りディスク・アクセスが増加することです。
この記事では、 iNotes Web Access リリース5.0.8 に関して私達が得たパフォーマンス・データを紹介しました。種々のハードウェア構成において得られたピーク値を示し、ミッドレンジのシステムについてより実用的なパフォーマンス・データを提供しました。また、デフォルトの設定は、パフォーマンスの観点で最適化されているので、展開に当たってチューニングがほとんど必要ないことがおわかりいただけたと思います。
iNotes Web Accessは単純なブラウザーをクライアントとして利用します。したがって、以前ならノーツ・クライアントで行なっていた処理の多くをドミノ サーバーで行なっています。そのため、 CPU 利用率がアクティブなユーザーの人数に比例して増加します。一方、クライアントが iNotes Web Accessのユーザーのときには、使用メモリー容量の合計は減少し、同様にディスクから読みとるデータの量も減少します。
パフォーマンス関連情報については、以下の Web サイトをご覧ください。
- The NotesBench Consortium（US）
- IBM Web サイトの zSeries Domino performanceのページ (現在はリンク切れ)
- IBM Web サイトの xSeries Domino performanceのページ (現在はリンク切れ)
著者について
ラジーヤ・ステファンは、ドミノ・パフォーマンス・チームの副代表です。彼女は 1998 年からアイリスで働いていました。彼女は現在の Compaq の前身である Digital Equipment corporation からアイリスに入りました。そこでは5年間 StorageWorks 部門で働いてきました。
リッチ・バックは IBM でパフォーマンスの分野において長い経験を積んできました。リッチはドミノがサポートするオペレーティング・システムについて広範な仕事をしてきました。現在は、 Solaris に専念しています。
|
 |
|
