パフォーマンスの向上とそれによるTCOの削減はLotus Notes/Domino 7の大きなテーマです。NRPC (Notes Remote Procedure Call、Notes/Dominoのメールプロトコル) については、内部的な制限を取り除くことによりスケーラビリティを向上させました。また、コードを最適化することでこれまでのCPU使用率でより多数のユーザーに対してサービスができるようになりました。全体として、Notes/Domino 7の殆どのプラットフォームでCPU使用率の低減化を図ることができました。(R6Mailユーザー測定時) CPU使用率の低減化はパフォーマンス向上での最大のものであり、開発陣はお客様の環境での結果を見てみたいと思っています。

三回シリーズの第一回目にあたるこの記事では、6.5と比較したLotus Notes/Domino 7のパフォーマンスの向上を解説します。この記事ではR6Mailの負荷ケースを使ったNotesユーザーのシミュレーションのベンチマーク結果を中心に扱っていきます。また、様々なプラットフォームで得られたベンチマーク結果をお見せしたいと思います。計測結果は単一のDominoパーティションで、特に断りがない限りトランザクションログは使用していません。Notes 6.5と7のメールテンプレートをDomino 7で使用した結果についても触れていきます。その双方については、Domino 6.5でNotes 6.5のメールテンプレートを使って計測した結果とも比較します。これにより、サーバーをアップグレードした後で発生するユーザーのメールファイルのDomino 7テンプレートへ変換する際の移行シナリオを想定することができます。

これらの結果はすべて1秒以下のDominoのリスポンスの回数になります。また、ベンチマークの目的であるため、ルータータスクのみを動作させています(別途記述がある場合は除く) これは他の動作によりデータが乱されないようにするためです。この記事の情報が有益であることを望むと共に、Notes/Domino 7が達成した進歩を理解していただきたいと思います。

The R6Mail ワークロード (負荷)

この記事でのベンチマークで使われるワークロードはserver.loadパフォーマンスツールのR6Mailです。このツールはDominoの中に入っています。server.loadの情報およびワークロードの情報については、Domino Administration Guideで見つけることができます。

まず概要ですが、ベンチマークの環境は複数の負荷(ワークロード)を生成するワークステーションからなっています。各ワークステーションはNotesのクライアント/サーバーのアクションを最大1500ユーザー分仮想的に生成することができます。平均1秒のリスポンスタイムを上回るまで負荷を生成するワークステーションを追加していきました。Dominoサーバー側では、テストで使用する仮想的なユーザーを適当な数だけDominoディレクトリーに追加しました。またそのユーザーについて各自のメールファイルをDataディレクトリーに作成しました。 仮想的な各ユーザーは90分の間に以下のタスクを実行します。

このワークロードをローレベルのDominoのトランザクションログに細分化すると以下の通りになります。

本記事の以下のセクションではプラットフォーム毎に結果を見ていきます。

上に戻る

AIX

AIXのテストでは、以下のハードウェアの設定を行いました。

パフォーマンスを最適化するために、以下の内容をnotes.iniに設定しました。

AIXではセグメント化されたメモリーのアーキテクチャをとっており、共有メモリーとヒープで使われるセグメントの最大数を制限しています。そのため、非常に小さい値をNSF_Buffer_Pool_Sizeに指定しています。これによりテスト環境では非常に多い仮想ユーザーをサポートできるようになっています。実際の運用における構成では、この値はもっと大きな値になるだろうと考えています。Server_Pool_TasksとServer_Max_Concurrent_Transの値は各Dominoリリースで大きなユーザー数をサポートできるように設定されています。これらの項目についてデフォルトの設定から値を変更する前に、使用する値が最適値になるよう、各自の環境を分析しておくことをお勧めします。

今回のテストではサーバータスクを最低限に絞っており、実際の運用で使われている一般的なものとは異なります。ただ、実際に運用されているDominoサーバーについては全てServer_Transinfo_rangeをnotes.iniに設定することを推奨します。設定値を決めるには、Server Expansion FactorとServer Availability Indexをモニターしながら、繰り返し行ってみる必要があります。これらの値と設定について完全な理解をするには、Domino Administrator HelpのServer Availability Indexの設定の項目を参照してください。

今回のラボでのテストでは、p670 LPARで約15,000のNotes仮想ユーザーをDomino 7で動作させることができました。一方、Domino 6.5では10,000でした。

以下に示す二つの表は、Domino 6.5とDomino 7とで10,000ユーザーを動作させた際に消費するシステムリソースを示しています。最初の表では、Mail6メールテンプレートを使った場合を示しています。

二つめの表では、Mail7のメールテンプレートを使用した場合を示しています。

Domino 7サーバー上でどのテンプレートを使うかにもよりますが、この表から、Domino 7は20から23%程度CPU使用率が低いこと、若干メモリーの使用率が高いこと、2から21％程度ディスク読み取りI/Oが低いことが分かります。また、図1からは、Domino 7サーバーでは12,000から14,000のR6Mailユーザーを、CPU使用率が25%を超えない程度でサポートできていることがわかります。(どのテンプレートを使うかによります。) 同じCPU使用率でDomino 6では10,000 のR6Mailユーザーしかサポートできませんでした。

p670を三つのLPARに分割して、ひとつのLPARを使った結果です。他の二つのLPARはテスト中もまた開発のトラブルシューティングやテスト用途に大きく使われていました。p670でLPARがいかによく動作しているかを示しているがこのことからよく分かります。異なる複数の処理を同一マシンで行ってもこの劇的なテスト結果が達成できたことを追記しておきます。

上に戻る

SuSE Linux (Intel)

以下の表は、NRPCのベンチマーク測定で使用したサーバーの構成を示したものです。

システムは「控えめな」Intelプラットフォームの1.4GHz Xeon MP CPU (ハイパースレッド) x 4 + 4GB RAMです。ディスクの構成はIBM EXPアレイでSCSIコントローラーに接続されています。FAStT 600システムは2つのQLogicのファイバーカード経由でサーバーに接続されています。測定においてはディスクのボトルネックを取り除き、15,000のNotesユーザーをシミュレートすることを達成することを目標におきました。OSはSuSE SLES 9を使用して、NPTL Posixライブラリーと同様、カーネル2.6をも最大限生かせるようにしています。

次の表は、notes.iniに変更した内容を示したものです。

ConstrainedSHMSizeMBの変数で興味ある特記事項があります。Domino 6.xではこの変数はおおよそ1GB前後に設定しておく必要がありました。これはDominoが最大で2GBまでしかメモリーを利用できない制限があるためです。(SuSE SLES 8 と SLES 9 では2GBがDominoに割り当てられる制限になっています。) そして、その一部はスタック空間に必要とされるものです。Domino 7ではこのnotes.iniパラメーター値は増やすことができるようになりました。これはSuSE SLES 8 と SLES 9でほぼ4GBまでデフォルトでメモリーを割り当てる方法が見つかったためです。これを行うには、tunekrnlと呼ばれる特別なプログラムを使います。これは自動的にシステムパラメーターを調整してDominoが効率的に動作するようにしてくれます。(Domino 7では自動的にこれが行われます。) また、この表にあるように、サーバー上で起動するタスクをNotesBenchのテストに必要なものだけに制限しています。これにより、テストで最大のパフォーマンスが出るようになっています。

Domino 6が設計された際には、Linix(x86) カーネルはsys-epollの機能ををサポートしなければならなかったが、実際にはそうではありませんでした。そのため、Dominoは他のプラットフォームで採用されているスレッドプールモデルをサポートすることができませんでした。これにより、NRPCユーザーはサーバースレッドを次々に作り出さなくてならなくなりました。各サーバースレッドはスタックを必要とし、256Kのメモリーを消費します。これらのスタックはOSがDominoに割り当てた2GBのメモリーから割り当てていきます。そのため、NRPCユーザー数をDomino 6では3000に制限していました。(zSeriesのLinuxでは、Domino 6.5にsys-epollを実装しています。)

Domino 7では、新しいカーネル (例えば、SuSE SLES 8やSLES 9) ではsys-epollの機能を活用しています。これにより、Dominoは他のプラットフォームと同じようにスレッドプールモデルを使えるようになりました。SLES 9に入っているNPTL Posixライブラリーにおける改善と相まって、Dominoのスケーラビリティーは大幅に改善されており、R6Mailユーザーで15,000 ユーザーを達成できています。これは400%も向上したことになります。(図2を参照)

Domino 7は15,000 ユーザーを達成できましたが、以下の表は3000ユーザーで取得した結果を比較したものです。その理由は、その値がDomino 6での最大値だからです。残念ながら、このローエンドの規模ではちょっとした値の変化が非常に大きなパーセント値となってきます。そのことを考慮にいれてデータをお読みください。また、Domino 7が利用可能なメモリーが多くあればあるほど、共有メモリーを大きく取ることができます。そうすることによって、大規模なユーザーの負荷を扱うことができるようになります。最初の表は、Mail6のテンプレートを使用してシミュレートしたものです。

二つめの表では、Mail7のメールテンプレートを使用した場合を示しています。

まとめですが、Linux上のDomino 7は、パーティションあたりのユーザー数は400％も増え、NRPCのスケーラビリティパフォーマンスの面で非常に大きな前進がありました。他のハイパフォーマンスなプラットフォームと同様にDominoを活用できるようになりました。

上に戻る

iSeries

Domino 7 iSeries版についても非常に大きなパフォーマンスのメリットがあります。このセクションでは異なる2つの構成での結果について解説します。ひとつはiSeries model 570でもう一つはiSeries model 810です。これら2つをテストすることでDomino 7のラボでのテストで観察された改善結果の幅の広がりを示したいと思います。

iSeries model 570

最初のテスト環境はiSeries model 570を使います。このサーバーには14個のプロセッサーが搭載されており、余裕のあるメモリーとディスクドライブのリソースを持っています。この構成を選択した理由は、Domino 7では制限のない環境での結果をお見せするためです。また、単一のDominoパーティションでのサポートできるユーザー数の増加についてテストを行うためでもあります。

全てのテストでデフォルトの設定が使用されました。ただし、model 570ではDomino 7のnotes.iniでserver_pool_tasksを100に設定しました。これは単一のDominoパーティションで多くのユーザーをサポートできるようにするためです。 Domino 6.5では最大で10,000 ユーザーに制限されていました。Domino 7ではこの制限が取り除かれ、このテスト用の構成では18,000 ユーザーまでサポートすることができます。CPU使用率を6.5と7で比べてみると、新しいMail7.ntfテンプレートをDomino 7で使用した場合、25%の向上が見られました。さらに、Mail6.ntfを使用した場合には、Domino 7の方が33％も多い10,000ユーザーをサポートすることができました。(図3を参照)

これらの数字は、お客様が実際に使用する環境で見られる最大改善値を示しています。CPU使用率が非常に低くなっている理由は、このシステム構成はDomino Web Accessのテスト用に設定されているためです。Domino Web AccessのテストではNRPCよりもCPUのリソースをより多く必要とします。

以下の二つの表は、10,000人のNotesユーザーをiSeries model 570でシミュレートしたものを比べたものです。最初の表ではMail6のテンプレートを使用しています。

二つめの表では、Mail7のメールテンプレートを使用した場合を示しています。

どちらのテンプレートでも大幅なCPU使用率の低下が見られています。その一方で、Dominoサーバーは多少高いディスクとメモリーの使用率になっていることが分かります。これはDomino 7で新たに入った機能をサポートするために生じたものです。これらの表から分かることは、単一のパーティションのDomino 7でサポートできるユーザー数が大幅に増え、さらにひとりあたりのCPU使用率が減少していることです。Domino 7では多少消費メモリー量とディスクの処理量が増えていますが、このシステム環境では双方のテンプレートを使ったテストで、リスポンスタイムもDomino 6.5と比較してよい結果をDomino 7は出しています

iSeries model 810

2つのプロセッサーを搭載したiSeries mode 810を使った二つめのテストです。このサーバーは16GBのメモリーと63のディスクドライブを搭載しており、4つのDominoパーティションに構成されています。

Notes/Domino 6.5/7双方ともデフォルトのnotes.iniを使用しました。

4つのDominoパーティションがこの環境で構成され、6000から9000ユーザーのポイントでテストしました。6000人のユーザーでテストしたポイントでは、1500ユーザーが各パーティションでアクティブでした。9000ユーザーでは2つのパーティションで3000ユーザーまで増えました。これらの数字は、model 570の構成で1パーティションあたりのユーザー数としてはより一般的なお客様の構成を反映したものになっています。また、ルータータスクでより多くの処理をさせています。

CPU使用率をDomino 6.5と7で比較してみると、Mail7.ntfをDomino 7で使った場合、9000ユーザーで4パーセントの向上が見られます。同じMail6.ntfで比べると、9000ユーザーで18パーセントもの向上が見られます。複数のDominoパーティションで各パーティションにユーザー数が比較的少ない場合は、お客様の環境でもこの程度のパフォーマンス向上が見られるのではないかと考えています。結果は図4を参照してください。

下の表はそれぞれのテンプレートでリソースの使用が削減できたかを示しています。最初の表はMail6を使って9000ユーザーをシミュレートしたものです。

二つめの表では、Mail7のメールテンプレートを使用した場合を示しています。

双方のテンプレートでCPU使用率が低下しているものの、Domino 7ではディスク使用とメモリー消費が増えています。これはMail7.ntfで加わった新機能によるものです。 このセクションで紹介した二つの環境でのDomino 7の性能向上は、お客様の環境でもある程度の範囲で見ることができることでしょう。パフォーマンスの向上はDominoが使えるCPU数、メモリー、ディスク、ネットワークなどのリソースがどの程度かによって変化します。既に紹介した表と説明にあるように、十分なリソースがある場合には、Domino 7とMail6.ntfを組み合わせて使用した場合に、高いレベルのパフォーマンス向上が見込まれます。Domino 7ではスケーラビリティーが向上し、より多くのユーザーを単一のDominoパーティションでサポートできるようになり、サーバーを統合することで少ないDomino パーティションで大きく向上したパフォーマンスを提供できるようになりました。

上に戻る

Solaris 9

Sun 6800は12CPUを搭載していますが、テストには8CPUを使用しました。T3アレイを6つ使用し、それぞれに9個のドライブが接続されています。

サーバーに以下のnotes.iniの設定変更を行いました。

Domino 6.5のテストでは1.5GBをNSF Buffer Poolに使用しましたが、Domino 7ではデフォルトの1.2GBまで少なくしています。これは、サポートする必要があるユーザーの数が増えたための措置です。また、server_pool_tasks、server_max_concurrent_trans、NSF_dbcache_maxentriesを増やし、増加したアクティブユーザーをサポートできるようにしています。その他の変更はSolarisでラージページサポートを有効にし、Domino 7が使えるようにしています。
Domino 6.5では、ハンドルを使い切っていないにもかかわらず、最大で10,000 のNotesユーザーが限界でした。Domino 7ではこの制限がなくなり、このテストにおいてはSolarisでは18,000 ユーザーまでサポートできました。加えて、18,000のうち10,000がアクティブな状態で計測したところ、CPU使用率は45%も低下していました。また、図5に見られるように、Domino 6.5で10,000ユーザーがアクティブな状態でのCPU使用率と同じCPU使用率で、Domino 7は14,000から15,000ユーザーをサポートすることができます。

以下の表は、双方のテンプレートを使って、6.5の最大数である10,000ユーザーが接続した際のリソースの利用状況を測定したものです。最初の表は10,000ユーザーがMail6テンプレートを使った時のものです。

二つめの表では、Mail7のメールテンプレートを使用した場合を示しています。

プロセスメモリーは、Domino 7の構成ではより大きくなっています。これは追加で多くのユーザーをサポートするために加えられた構成の変更によるものです。Domino 6.5の数字はMail6テンプレートを使用した時のものです。

単一のDomino 7のパーティションでSolarisでは18,000ユーザーまでスケーラビリティーが向上しました。6.5の時は10,000 でした。加えて、多くのユーザーが同時にアクセスした場合には、同じユーザーの負荷をかけた場合で比較するとCPU使用率が大幅に低下します。

上に戻る

Windows 2003 Enterprise Server

Domino 7は単一のパーティションで構成
eServer xSeries 365にWindows 2003 Enterprise Serverをインストールし、さらにDomino 7がインストールされています。サーバーは2CPUでハイパースレッディングはありません。Windowsから認識されているメモリーは3.5 GBです。Dominoの実行ファイルはIBM FAStT 600 (200 GB、RAID 0) のひとつにインストールされています。メールデータベースは5本のIBM FAStT 600 アレイ (RAID 0)に分散して配置されています。ネットワークアクセスは1GBのEthernet が一つで、全二重モードで動作しています。以下の表はxSeriesサーバーの設定を示したものです。

今回の他のテストの殆どの場合で、以下の通りサーバーのnotes.iniを調整しました。

他のプラットフォームでお見せしたように、Windows 2003 Enterprise ServerでのDomino 7はCPU使用率の低下とスケーラビリティーの向上が期待できます。Domino 7でサポートされる最大ユーザー数は15000まで増加しました。6.5では10,000 が最大でした。
10,000ユーザーの負荷をかけた場合に、Domino 6.5と比べるとDomino 7ではCPU使用率の大幅な低下が確認できました。6.5では58%であったのは47%になりました。約19%減りました。このCPU使用率の低下はユーザー数の増加につながります。図6に見られるように、12,000から14,000ユーザーをサポートすることができます。同じCPU使用率の状態ではDomino 6.5では10,000が最大アクティブユーザー数でした。

以下の表は、双方のテンプレートを使って、6.5の最大数である10,000ユーザーが接続した際のリソースの利用状況を測定したものです。最初の表は10,000ユーザーがMail6テンプレートを使った時のものです。

二つめの表では、Mail7のメールテンプレートを使用した場合を示しています。

双方のテンプレートで大きなCPU使用率の低下がみられたものの、Dominoサーバーは7のテンプレートに加えられた新機能を使うために多少リソースを多めに消費していることが分かります。

ベンチマーク結果からお分かりのように、Windows 2003 Enterprise Server上でのDomino 7は6.5と比べて大幅にパフォーマンスが向上していることが分かります。この中にはCPU使用率の低下やメモリー消費の改善や、50%以上増えたユーザー数などがあります。

上に戻る

Linux on zSeries

Domino 7とDomino 6.5のｚSeriesを比較した場合、Notes Mail、R6Mailワークロードでは、CPU使用率が25から30%の低減が確認されました。また、トランザクションロギングでは、10から14%の低減（zSeriesで使用された場合では、ハードウェアによるデータ圧縮支援機能）が確認されました。さらに、Domino 7の様々なクロスプラットフォーム（クイックプールの実装やメモリーのフラグメント）が改善されたことで、別にCPUが10から20%節約されました。Domino 6.5とDomino 7との比較には、SLES 8 SP3を使用しました。しかし、SLES 9の測定値がSLES 8を超えて、CPU使用率の約10%の節約を示したので、Domino 7ではSLES 9を使用することをお薦めします。SLES 9は、64ビットオペレーティングシステムです。そして、複数のDominoパーティション(DPAR)は、シングルLPARにインストール可能です。

これらのCPU使用率の低減は、R6Mail ワークロードを使用して測定されました。Domino 7のメールテンプレートに含まれる追加機能により、R6Mail ワークロードテストの実行時に、5から15%のCPU負荷がかかることがわかりました。このことは、CPU低減の一部を埋め合わせてしまうと思われます。このセクションでは、Domino 6およびDomino 7のメールテンプレートの両方のCPU使用率の低下について述べています。Domino 7メンテナンスリリースを含む、将来のDominoリリースにおいて、CPU使用率を低減することは継続的にフォーカスされています。

すべてのzSeriesパフォーマンステストは、z990 Model 2084-C24の1つの論理区(LPAR)で行いました。z990は、24の有効なCPUを持ち、そして、そのうちの6つがパフォーマンステストLPARに割り当てられます。残りの18のCPUは、他のマシンリソースと同様に、Domino開発とテストアクティビティのために使われた他の13のLPARsとの間で分けられています。このマシンは、z/OS、SLES 8、SLES 9、REL 4といった、Quattroブートを持っています。 NRPC mailテストのため、より高いCPU負荷をもつロードテストを運用するために、6つのうち3つのCPUをDomino 6.5とDomino 7に使いました。Domino 6.5は、SLES 9、REL 4の上では動作しません。パフォーマンステストLPARは、12GBメモリで構成されています。LANは、他のネットワークトラフィックインターフェースの関係のないアクティビティを避けるために、孤立されています。すべてのディスクは、それぞれのディスクが3390 Model 3として構成された Enterprise Storage Server(2105 Model 800)から割り当てられています。Dominoの実行、データ (クライアントメールデータベースは除外)、Dominoアドレス帳(Names.nsf)、トランザクションロギングのための論理ボリュームマネージャー(LVM)ファイルシステムの2ボリュームのために、ひとつのボリューム(ディスク)で割り当てられた別々のファイルシステムがあります。クライアントメールデータベースは、52のLVMファイルシステムを超えて配布されました。ファイルシステムあたり11.5GBの有効スペースを提供しているひとつのLVMで、5つのボリュームにわたってそれぞれ割り当てられています。EXT 3ファイルシステムは、Linux for zSeriesで使用されました。インストールされたオペレーティングシステムは、SLES 8 SP3またはSLES 9 SP1でした。

SLES 8では、31ビットのオペレーティングシステムとスワップスペースへの2GB拡張メモリのため、セントラルメモリーに使用されるのは2GBだけです。SLES 9では、合計で12GB使いました。以下の表に、ハードウェア構成を示します：

テストに先立ち、Domino 6.5と7についてnotes.iniの設定を以下のように変更しました。
TRANSLOG_Status=1
TRANSLOG_MaxSize=3000
TRANSLOG_Performance=1
NSF_Buffer_Pool_Size_MB=256
Server_Pool_Tasks=100
ServerTasks=Router
NSF_DBCache_MaxEntries=10000

図7はDomino 6.5と7でのCPU使用率の改善を示したもので、NRPCでMail6とMail7のテンプレートのいずれかでワークロードをかけた場合の測定結果です。

今回のテスト手順では、1000クライアントの追加ごとに、あるいはスタートから1時間は待つようにしています。これは「安定した状態」を作り出すためです。CPU使用率は1時間後の安定した状態での平均値です。Domino 6.5での最大Notesクライアントユーザー数は10,000で、Domino 7では12,000まで増えました。

図7は、6.5のテンプレートを使った場合Domino 7のCPU使用率が15%から28%の範囲で改善されたことを示しています。また、Mail7のテンプレートの場合は9%から21%の範囲であったことを示しています。Domino 7では明らかに双方のテンプレートでもCPU使用率の改善があったことが分かります。開発陣としては、将来のDominoのリリースにおいて、Mail7テンプレートの最適化に焦点を合わせて開発を進めていく予定です。

図8はSLES 9でのCPU使用率の改善を示したものです。ここではDomino 7+Mail6テンプレートを使用した場合、1%から18%の範囲で改善が見られたことが分かります。6000ユーザーを超えると、SLES 8では実メモリーを使い果たし、スワップページの読み書きが発生しました。しかし、SLES 9ではそのようなことはありませんでした。それは、SLES 9ではメモリーが十分あったためです。したがって、6000ユーザーを超えるとzSeries上のLinux環境ではSLES 8よりSLES 9の方がCPU使用率でより大きな改善があったことになります。

ワークロードはDomino 6.5と7で同じだけの負荷を生成させています。それぞれネットワークの送受バイト数は同一ですし、送信したメール数は同一で、処理したトランザクション数も同一です。Domino 7でのCPU使用率の削減は、高いワークロード時における安定稼働改善につながります。また、単一のDominoサーバーでサポートできるクライアント数の増加にもつながります。さらに重要なことは、CPUの要件が軽くなることで、Domino 6.5と比べてTCOの削減につながることです。

上に戻る

z/OS

zSeries z/OSプラットフォーム上で稼働するDomino 7に関しては、Dominoのサーバーコードの改善に加えて、zSeries専用のハードウェア機能が使用されます。最初に興味があるエリアはトランザクションログのメリットとパフォーマンスへの影響です。トランザクションログは大きなメリットを提供してくれますが、CPUへの負荷が明らかに余計にかかります。最大で使用しているCPUパワーの1/3がデータの圧縮に使われていました。Domino 7ではハードウェアを補助機能として使ったデータ圧縮機能が使われています。今回のベンチマーク測定では、トランザクションログを使用した場合に、全体として10から11%のCPU使用率の改善が見られました。(ハードウェアの圧縮支援機能を利用した場合。Domino 6.5が持つアルゴリズムでソフトウェア的に圧縮した場合の比較)

Domino 7の潜在的なパフォーマンスの可能性を明確化するための一つのテクニックは、ストレステスト中に内部のオペレーションを分析することです。このデータをプラットフォーム間で分析することで、z/OSは他のプラットフォームのいくつかと比較して、各Notesクライアントが読み書きするためのネットワークバッファーメモリーの割り当てが必要であることが分かりました。z/OSでのメモリーアロケーションのアルゴリズムを改善することにより、今回のテストでは7%のCPU使用率の低下につながりました。

その変更単独だけでも、Domino 7では17%から20%のCPU使用率の低下がみられました。加えて、Domino 7での様々なクロスプラットフォームの改善により10%のCPU使用率が改善されました。メールのベンチマークテストでは総合的に25から30%の改善がみられました。(詳細は後述)

このCPU使用率の改善はDomino 6のテンプレートを使用して、R6Mailワークロードを使ってDomino 6.5/7それぞれで測定されました。前に述べたように、Domino 7のメールテンプレートに含まれる機能によりCPU使用率の改善は多少帳消しになっています。

このセクションで記した全てのパフォーマンステストの結果は、z990 model 2084-C24の単一の論理パーティション(LPAR)で測定したものです。z990には24CPUありますが、6つをパフォーマンスでつかうLPARに割り当てています。NRPCのメールテストについては、そのうち3つのCPUだけを使用して高いCPU使用率になるよう負荷をかけてみました。LPARのパフォーマンステストでは12GBのセントラルストレージメモリーを設定し、Gigabit Ethernet Open Systems Architecture (OSA) カードを使用しました。LANはネットワークトラフィックの影響を避けるために、独立したものにしています。ディスクは、Enterprise Storage Server (2105 Model 800) アレイから割り当てており、各ディスクは3390 model 3として設定しています。別個にz/FS のファイルシステムが単一ボリューム(ディスク)に設定されておりDominoの実行ファイル、データ(メールデータベースは除く)、Dominoディレクトリー(Names.nsf)に使われています。ファイルシステムは2つのボリュームをまとめたもので、トランザクションログに割り当てられています。クライアントのメールデータベースは均等に53のz/FSに分散して配置しています。それぞれ5つのボリュームをまとめたもので利用可能な領域は11.5GBあります。OSはz/OS version 1 release 5です。
以下の表は今回のテストで使用したハードウェアの設定内容です。

このテストではDomino 6.5と7についてnotes.iniの設定を以下のように変更しました。

TRANSLOG_Status=1
TRANSLOG_MaxSize=3000
TRANSLOG_Performance=1
NSF_Buffer_Pool_Size_MB=128
Server_Pool_Tasks=100
ServerTasks=Router
NSF_DBCache_MaxEntries=10000

図9はNRPCのメールワークロードでCPU使用率の改善を比較したものです。Mail6のテンプレートかMail7のテンプレートのいずれかを使用して測定しています。

zSeries上のLinuxでのテストでは、1000クライアントの追加ごとに、あるいはスタートから1時間は待つようにしています。これは「安定した状態」を作り出すためです。CPU使用率は1時間後の安定した状態での平均値です。Domino 6.5での最大Notesクライアントユーザー数は9000で共有メモリーを使い果たしましたが、Domino 7では10000を超えて増えやすことができました。

図9はDomino 6.5のテンプレートを使用した場合、CPU使用率の改善が21から29%の範囲であったことを示しています。また、Domino 7のテンプレートをDomino 7で使用して測定した場合には、10から19%の改善かあったことを示しています。空きからに、Domino 7ではMail6.ntf、Mail7.ntfの双方でCPU使用率が改善しています。

図10はDomino 7上でのサーバータスクからくる改善を示しています。ルータータスクのCPU使用率は6.5と7では変化がありません。

Domino 6.5と7では同じ量の負荷をワークロードは生成しています。

上に戻る

まとめ

この記事では、NotesクライアントワークロードによるDomino 7サーバーのパフォーマンスについて解説しました。Notes/Domino 7は、プラットフォームのアーキテクチャーの違いが影響するにもかかわらず、計測した全てのプラットフォーム上でのスケーラビリティに重要な改善がなされています。一般的に、十分なリソースを持つDomino 6.5の構成では10000ユーザーが制限ですが、その制限を超える結果が確認されています。SolarisとiSeriesでは、他のプラットフォームよりいくぶん大きなアドレス空間にアクセスしますので、18000ものベンチマークユーザーという結果が得られました。SuSE Linuxでは、Dominoの他のプラットフォームと類似しており、sys-epollカーネルのスレッドプールを実行することにより有効性を得られます。その結果、3000ユーザーから15000ユーザーへの劇的なスケーラビリティーの増加になりました。これらのスケーラビリティーの改善により、追加ユーザーのためのリソースがあれば、サーバーの統合が可能になります。

この記事は比較的以前に作成されたため、三回シリーズの第一回目にあたります。パート2では、Domino Web Accessユーザーのシミュレーション（R6iNotesワークロードを使用）を計測したDomino HTTPパフォーマンスの結果について論じています。パート3では、Notesクライアントと同様に、クラスタレプリカ、ローカルレプリカ、全文索引を含むワークロードを使用することで、典型的な企業環境において期待される結果が得られました。

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• 今回のテストで使用されたR6Mailワークロードの詳細については次の記事を参照してください。『The New Domino 6 NotesBench workloads: Heavier by request!(US)』
  
  
• server.loadおよびR6MailワークロードについてはDomino Administration Guide(US)をご覧ください。
  
  
• Lotus Notes 7の機能全てについての詳細については、『Lotus Notes と Domino Designer 7.0 の新機能』を参照してください。
  
  
• Lotus Domino 7.0 の新機能については、『Lotus Domino 7.0 の新機能』を参照してください。
  
  
• Lotus Notes/Domino 製品の詳細については、Lotus Notes/Domino 製品ページ（US）を参照してください。
  
  
• developerWorks ブログ（US）に参加してdeveloperWorksのコミュニティーに参加してみてください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• The R6Mail ワークロード (負荷)
• AIX
• SuSE Linux (Intel)
• iSeries
• Solaris 9
• Windows 2003 Enterprise Server
• Linux on zSeries
• z/OS
• まとめ
• 参考文献
• 著者について
• コメント