ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > IBM Workplace Collaboration Services >

LDD Today

初期導入の経験から得たWorkplace Messagingの最適化の実際

by マイケル・ガズダ、タイタス・カオ、ジョー・ウィスマン
レベル：中級者
対象: Lotus Workplace Messaging
原文の掲載：2003年7月1日

LDD Todayの原文（US）

インデックス

	サンプル・テスト構成
	発見事項
	まとめ

IBM Lotus Workplace Messaging 1.0は、個人専用のデスクやメール・アカウントを持っていないユーザーへのエンタープライズ・メールの展開を可能にする低コストのメッセージングを実現します。Lotus Workplace Messagingは、IBMのWebSphere Application Server、WebSphere Portal、およびDB2テクノロジーを基礎とする、J2EEベースの電子メールおよび個人連絡用Webクライアントを提供します。さらに、LDAPを利用してディレクトリー・サービスを提供するため、既存のディレクトリーを使用することが可能です。

Lotus Workplace Messagingの開発時の主な目標の1つは、優れたスケーラビリティーでした。この目標を達成するために、Lotus Product Introduction Engineeringチームと開発チームが緊密に協力して、膨大な量のコードの検証とストレス分析を実施しました。その結果は、開発サイクルのなるべく早い段階でボトルネックを特定し、解消するために、絶えず開発者の元に届けられました。

また、Lotus Workplace MessagingにIBMのさまざまなテクノロジーが組み込まれて以来、我々はIBMのHigh Volume Web Site（現在リンク切れ）チームとDB2 performanceチームに、チューニングに関するいっそうの専門知識の提供を求めることにしました。High Volume Web Siteチームは、WebSphere Application Serverを効果的にスケールする方法に関するノウハウと展望をもたらしてくれました。DB2 performanceチームは、Lotus Workplace MessagingのDB2バックエンドのスムーズな動作の保証に貢献してくれました。Lotusのメールや機能に関する我々自身の専門知識に加えて、WebSphereのエキスパートとDB2のエキスパートの連係によって、Lotus Workplace Messaging 1.0は我々の高い期待に応えることができました。

これまでに、Lotus Workplace Messagingのオペレーション全般の改善に役に立つさまざまなヒントや手法が得られており、本稿ではそれらについて概説します。まず、ハードウェア／ソフトウェア構成、ユーザーのエミュレートに使用したワークロードなど、分析で使用した典型的なセットアップについて見ていきます。その後、読者の皆さんがご自分のサイトでLotus Workplace Messagingを最適化するのに役立つ発見事項について、システム・キュー管理に重点を置いて説明します。本稿の対象読者は、Lotus Workplace Messaging、WebSphere Application Server、およびDB2に精通した、実務経験のあるシステム・アドミニストレーターです。

サンプル・テスト構成

さまざまなお客様の観点からLotus Workplace Messagingを考察できるように、数種類のハードウェア構成とワークロードでテストを実施しました。ワークロードは、テスト・ユーザー1人当たりのトランザクション・レートが高く、ストレスの多いシナリオから、ユーザー1人当たりのトランザクションは少ないが、多数のテスト・ユーザーがサーバーを使用する、より「バランスのとれた」シナリオに至るまで、さまざまなものを用意しました。また、HTTPインターフェースのみのワークロード、SMTPメール配信のみのワークロード、および両者を組み合わせたワークロードも作成しました。

例として、皆さんのサイトでも使用されていると思われるハードウェア・セットアップとHTTPワークロードを使用した、バランスのとれた構成のサンプルを示します。このサンプルのLotus Workplace Messaging環境に以下のサーバーをインストールし、100Base-Tネットワークで稼働しました。

WebSphere Application Server 5.0＋IBM HTTP Server 1.3.26：4ウェイの1.5GHz Xeonプロセッサー（ハイパー・スレッディングは無効）、3.5GBのRAM、3台の36GB Ultra 160 SCSI内蔵ディスク・ドライブを搭載したIBM xSeries 360サーバーとWindows 2000 Server（SP3）の組み合わせで稼働
DB2 Enterprise Edition 7.2 Server（FixPack 7）：2ウェイの1.26GHz Xeonプロセッサー、2.5GBのRAM、2台の36GB Ultra160 SCSI内蔵ディスク・ドライブを搭載し、RAID 5構成の2つの69.5GBアレイを備えたSSAコントローラーが接続されたIBM xSeries 330サーバーとWindows 2000 Server（SP3）の組み合わせで稼働
IBM Directory Server 4.1：2ウェイの1.26GHz Xeonプロセッサー、2.5GBのRAM、および1台の36GB Ultra160 SCSI内蔵ディスク・ドライブを搭載したマシンとWindows 2000 Server（SP3）の組み合わせで稼働

3,000人の登録ユーザーをシミュレートし、そのうちの1,500人をテストの間、同時にアクティブとしました。平均サイズが32 KBの約95件のメールを含むメール・ファイルごとにテストを開始しました。これは、1～100 KBの10種類のメッセージ本文サイズを含み、メッセージの30%には50 KBのテキスト・ファイルが添付されています。

このテストの間、アクティブ・ユーザーが送信したすべてのメッセージの宛先はローカルとしました。受信者は、サーバーに登録された3,000人のユーザー（1,500人のアクティブ・ユーザーを含む）のプールからランダムに生成しました。テストの間に送信される各メッセージは、メール・ファイル内の既存のメッセージとは別のものになるようにしました。サイズと配分は、以下の表のとおりです。

本文のサイズ（KB）	添付ファイルのサイズ（KB）	メッセージの合計サイズ（KB）	使用率
0.5	0	0.5	10
10	0	10	30
50	0	50	40
50	50	100	10
150	0	150	9.5
1	10	10	0.5

ユーザー・アクティビティーのシミュレートには、次の操作を実行するスクリプト化されたワークロードを使用しました。まず、テスト開始から50分をかけて、1,500人のアクティブ・ユーザーが徐々にLotus Workplace Messagingサーバーにログインします。各ユーザーは、システムにログインした後、ちょうど15分続くアクションのループを開始し、それを連続的に繰り返します。このループの間、各ユーザーは以下の操作を実行します。

新着メールを確認する。
1～3分間待つ。
最初のメールを読む。
1分間待つ。
2番目のメールを読む。
1分間待つ。
3番目のメールを読む。
1分間待つ。
4番目のメールを読む。
1分間待つ。
5番目のメールを読む。
1分間待つ。
メールをランダムに削除する。
6回の繰り返しごとに（つまり90分おきに）［Compose Message］ウィンドウを開き、40～80秒でメッセージを作成し、そのメッセージを3人のランダムな受信者に送信する（送信者自身を4人目の受信者としてcc: に指定する）。
ループの開始から15分が経過するのを待つ（したがって、各繰り返しの長さはちょうど15分となります）。

ユーザーが全員システムにログインした後、3時間10分にわたってテストを実施したので、テスト時間は全体で4時間に及びました。

複数のユーザー・ロード処理中の接続プール・サイズ、サーバーのスレッド使用率、およびJavaメモリー・サイズ（後述）は、Tivoli Performance Viewerを使用して調査しました。また、Tivoli Performance Viewerを使用して、メモリー・リークもチェックしました（幸い、メモリー・リークは皆無でした）。さらに、InfoCenter for WebSphere Deployment Managerで提供されている非常に多くのパフォーマンス・チューニング情報も参考にしました。読者の皆さんも、Lotus Workplace Messagingの展開に役立つ情報をお探しの場合は、このサイトにアクセスすることをお勧めします。

上に戻る

発見事項

前述のとおり、我々の作業の目的は、Lotus Workplace Messaging開発チームが潜在的なボトルネックやスケーラビリティーの障害要因となる部分を特定しやすくすることでした。得られたデータは貴重なものとなり、ビルドが進むにつれてレスポンスとキャパシティーに大きな改善が見られました。また、WebSphere Application Serverの設定をチューニングすることによって、特にシステム・キュー管理の部分について、Lotus Workplace Messagingのパフォーマンスを改善するさまざまな方法の検討も行いました。

システム・キューの概要
Webアプリケーションに対する各要求は、WebSphere Application Serverの複数のレイヤーでキューに入れられます。これらの要求は、アプリケーション・サービス・プラットフォームのさまざまなコンポーネントによって扱われます。これらのコンポーネントには、ネットワーク、Webサーバー、Webコンテナー、Enterprise JavaBean（EJB）コンテナー、バックエンドのデータベースやその他のエンタープライズ・システムへのデータ・ソースがあります。各リソースは、そのリソースの使用を待つ要求のキューを扱います。キューは、負荷に依存するリソースであり、要求の平均サービス時間は、同時クライアントの数と要求の平均処理時間に依存します。したがって、キューはユーザーに対するシステムの応答時間における重要な要素といえます。

キューには、オープン・キューとクローズ・キューがあります。キューイング・ネットワーク内のほとんどのキューは、クローズ・キューです。オープン・キューとは対照的に、クローズ・キューではキュー内に存在する要求の最大数に制限が設定されます。WebSphere Application ServerがサポートするWebサーバーはすべて、クローズ・キューです。Webコンテナーは、オープン・キューとクローズ・キューのどちらにも構成できますが、一般にはクローズ・キューとして構成することをお勧めします。

一般に、WebSphere Application Server内ではなく、ネットワーク内で要求を待機させるほうがよい結果が得られます。キューのサイズは、要求がWebSphere Application Serverの中を流れるにつれて徐々に小さくする必要があります。つまり、クライアントから遠いキューよりも、近いほうのキューのサイズを大きく設定すべきということです。この仕組みを下図に示します。

リクエスト・キューの流れ

以下のセクションでは、次に示す、Lotus Workplace Messagingでモニターすべきいくつかの重要なキューとログ・ファイル設定について説明します。

IBM HTTP Serverキュー：並行スレッドおよびHTTPサーバー・ロギング
Webコンテナー・キュー：サーバー・スレッドおよびHTTPセッション
データベース・キュー：接続プール・サイズ、DB2への接続数、およびステートメント・キャッシュ・サイズ
Javaメモリー

なお、本稿でご紹介する推奨事項はLotus Workplace Messaging 1.0に限定したものであり、将来のリリースに適用されない情報が含まれている可能性があります。また、今後のリリースで新しいチューニング機能やヒントが提供される可能性があります。詳細については、Lotus Workplace Messaging documentationをご覧ください。

IBM HTTP Serverキュー
IBM HTTP Serverキューのパフォーマンスには、並行スレッドとHTTPサーバー・ロギングの2つの設定が影響する可能性があります。

並行スレッド
まず、IBM HTTP Server内で同時に実行される並行スレッドの数が最大値以下であることを確認してください。この値は、HTTP Serverでのボトルネックを回避するのに十分な大きさに設定しながら、アプリケーション・サーバーへの接続が適度な数となるようになるべく小さく抑える必要があります。Lotus Workplace Messagingメール・アプリケーション・サーバーが1つの場合の推奨値は「60」です。並行スレッドは、IBM HTTP ServerのMaxClients（AIXの場合）およびThreadsPerChild（Windowsの場合）の設定によって制御されます。

HTTPサーバー・ロギング
HTTPロギングは、無効にすればパフォーマンスへの影響をなくすことができます（これは、一般的なスケーラビリティーの最適化手法です）。
Webコンテナー・キュー
Webコンテナー・キューの場合、サーバー・スレッドとHTTPセッションの設定に注目します。

サーバー・スレッド
WebSphereは、要求を扱うスレッドを割り当てることによって、コンテナー要求数を制御します。WebSphereのデフォルト設定は次のとおりです。

最小スレッド・プール・サイズ： 10
最大スレッド・プール・サイズ： 50

テストの結果、上記の設定で十分であることがわかっていますが、Tivoli Performance Viewerで定期的にモニターすることをお勧めします。

HTTPセッション
HTTPセッションのタイムアウトは、できる限り低く設定します。HTTPセッションは、アイドル状態でもサーバーのリソースを消費するため、それによってアクティブなユーザー・セッションに消費されるリソースが少なくなる可能性があります。

データベース・キュー
問題となるデータベース・キュー設定は、接続プール・サイズ、DB2との接続、およびステートメント・キャッシュ・サイズです。

接続プール・サイズ
接続プールは、Lotus Workplace Messaging内でJDBCを直接呼び出す場合に使用されます。アプリケーション・サーバーの追加によってLotus Workplace Messagingを展開した場合、ノードごとにデータ・ソース・プールが存在します。これは、データベース・サーバーの最大接続数を設定する際に重要な要素となります。デフォルト値は次のとおりです。

最小接続プール・サイズ： 1
最大接続プール・サイズ： 10

データベースの接続数を多くするとパフォーマンスを改善できますが、必要以上に多くしてはなりません。最初は最小値「10」／最大値「30」から始めて、徐々に値を大きくしてみてください。複数のWebアプリケーションを水平的に展開している場合は、割り当てられた接続の合計数が、割り当てられたDB2への接続数（次のセクションを参照）を超えないように注意が必要です。

DB2への接続数
データベースに接続するアプリケーション数の上限は、データベース構成パラメーター「MaxAppls」によって設定します。DB2 MaxAppls設定は、必ずLotus Workplace Messagingデータ・ソースに設定された接続数よりも大きく設定してください。また、フェイルオーバー構成をとっている場合は、セッション管理だけでなく、展開に含まれるすべてのノードに対する考慮が必要です。

また、DB2 MaxAgents設定もアプリケーションの接続数に影響します。MaxAgentsは、MaxApplsとともに、アプリケーションへのメモリーの割り当てを決定します。一般的な経験則として、MaxAgentsはMaxAppls以上に設定します。

ステートメント・キャッシュ・サイズ
WebSphere Application Serverデータ・ソースは、準備済みステートメントの処理を最適化します。準備済みステートメントとは、準備済みステートメント・オブジェクトに保管されているコンパイル済みSQLステートメントです。このオブジェクトは、特定のSQLステートメントを複数回、効率的に実行するために使用されます。推奨値は次のとおりです。

メール・サービスおよびメッセージング・クライアントが同じマシンに配置されている場合：200
メッセージング・クライアントが別のマシンに配置されている場合：150
メール・サービスが別のマシンに配置されている場合：50

Javaメモリー
Javaヒープ・サイズは、ガーベッジ・コレクションをはじめとするアプリケーションの実行が効率化されるように設定する必要があります。通常、ガーベッジ・コレクションは、正常に動作するアプリケーションの合計実行時間の5～20%を消費します。管理されていない場合、ガーベッジ・コレクションは、特にLotus Workplace Messaging SMTPサーバー・マシン上での実行時に、アプリケーションの最も大きなボトルネックの1つとなる可能性があります。デフォルトのヒープ・サイズは「0」です。WebSphere Application Serverによって動的にメモリーが割り振られるのは好ましくないため、ヒープ・サイズを目標のサイズに設定したほうがよいでしょう。我々のテストでは、以下の設定でよい結果が得られました。

メール・サービスおよびメッセージング・クライアントが同じマシンに配置されている場合：578MB
メッセージング・クライアントが別のマシンに配置されている場合：512MB
メール・サービスが別のマシンに配置されている場合：512MB

上に戻る

まとめ

Lotus Workplace Messaging 1.0の理解とチューニングの出発点として、本稿がお役に立てば幸いです。欲を言えば、読者の皆さんがご自分のサイトでLotus Workplace Messagingのキャパシティーやレスポンスのテストを実施することを決めた場合に、我々のテストのセットアップがお役に立てばさらにうれしく思います（多くのアドミニストレーターの皆さんから、こうしたテストは企業規模の展開のプランニングや構成を行う際に非常に役立つとのコメントを頂いております）。また、本稿でざっとご紹介したシステム・チューニングのヒントと手法は、きっとLotus Workplace Messaging環境を円滑に運用する上で一助になると思います。

著者について
マイケル・ガズダは、2001年からProduct Introduction Engineering部門において、ネットワーク圧縮、IMAP、iNotes Web Access、Lotus Workplace Messagingに関するプロジェクトに従事しています。それ以前の3年間は、Lotus Notes/Dominoテクニカル・サポートのシニア・テクニカル・サポート・アナリストとして、データベース設計、メール配信、サーバーなど、さまざまな問題のサポート業務を担当していました。勤務のないときにはボストン大学に聴講生として通い、情報工学で文学士号の取得を目指しています。
タイタス・カオは、1992年のIBM入社以来、SmartSuite、Notes/Domino、eSuiteなどの各種Lotusアプリケーションに携わっています。彼は、あるときは品質エンジニアとして、またあるときにはソフトウェア開発者として、さまざまな立場で働いてきましたが、最近はK-stationやWebSphere Portal Serverなどのポータル製品のパフォーマンス・エンジニアを務めています。最近の功績としては、Lotus Workplace Messaging 1.0のパフォーマンス改善が挙げられます。彼は、レンセラー工科大学でコンピューターおよびシステム・エンジニアリングの理学士号を取得しています。
ジョー・ウィスマンは、Lotus Workplace Messagingサーバー開発担当のシニア・エンジニアです。Lotusに入社する前は、IBM AIM Servicesでシニア・ソリューション・アーキテクトとして、またAribaでアーキテクトとして働いていました。彼は、メリーランド大学で数学博士号を取得しています。

上に戻る