Sametime Linksツールキットを使うと、Lotus Instant Messaging (Sametime)の機能をWebページやアプリケーションに組み込むことができます。例えば、ユーザー名が表示される場所すべてについて在席確認機能を付加するといったことです。これで、そのユーザーがオンラインか否かを確認でき、チャットができるかどうかの判断ができます。これを実現するにはちょっとしたHTMLコードをWebページに組み込むだけで実現できます(Webページの全体的なレイアウトを変更する必要はありません)。ツールキット自体は20KB程度と小さく、IBMの試用ページ、trials and betas page（US）からダウンロードできます。最新のバージョンをもっと学ぶには、Sametime Links 3.1 Toolkit documentation（PDFファイル 357KB）をご覧ください。

Lotus Engineering Test (LET)チームは、BoulderにあるCross-Application Performance Reliability Stress (XPRS) Test Centerと共にパフォーマンス評価を行い、Sametime LinksによるLotus Instant Messagingへのインパクトの見極めを行いました。その結果、Sametime Linksアプリケーションは極めて小さなインパクトしかチャットのパフォーマンスに対して影響を与えないことがわかりました。この記事では、この結果に至る過程を紹介します。また、テスト環境や結果の詳細も紹介します。この記事は、読者が、Lotus Instant Messagingをよく知っており、管理者としての経験があることを前提としています。

テストの準備

Sametime Linksのパフォーマンステストの目的は以下の通りです。

• Sametime Linksのパフォーマンスとスケーラビリティーの特長を掴み、リソースの利用とリスポンス・タイムについて理解すること。
• Sametime Linksの使用によるLotus Instant Messagingインフラへのインパクトを見極める。
• リソース利用に関するデータの収集を行い、キャパシティー・サイジングを行う際のガイドとする。

ワークロード
私たちが行ったテストでは、Sametime Links機能を使い、在席確認とその他のインスタント・メッセージングの機能を加えた社員名簿のアプリケーションを走らせました。調査の一部として、巨大なLotus Instant Messaging Communityについてもシミュレーションを行いました。このテストでは、現在あるLotus Instant Messagingの環境においてSametime Linksアプリケーションを走らせた場合のパフォーマンスを計測することができます。これにより、実験の結果が現実的なものであり、実際のLotus Instant Messaging 環境で現れる典型的な結果に近くなるように、実験結果を補強してくれています。

実験では一般に公開していない内部的なツールを使用して、Sametime Linksアプリケーションの負荷を作り出し、エンドユーザーのリスポンス・タイムを計測できます。またこれとは別に、最大6万人のLotus Instant Messagingユーザーの負荷を擬似的に作り出せるツールもしようしました。Sametime LinksサーバーとLotus Instant Messaging Communityサーバーはどちらとも実験室に置いて実験を行いました。

エンドユーザーの視点から、トランザクションのリスポンスタイムエンドを計測することでエンド・トゥー・エンドのパフォーマンスを計測しました。実際には3種類、4000、8000、16000のユーザー負荷を擬似的にかけてのテストをそれぞれ1時間連続でおこないました。また、長時間のテストをおこなうために、8000ユーザーで12時間連続のテストも行いました(この実験はうまくいき、リスポンス・タイムは他のテストと同じかそれ以下に収まりました)。

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

• Lotus Instant Messagingのインスタント・メッセージングの負荷を擬似的に発生させるためのサーバーが一台。一般的なインスタント・メッセージングの状況を60000ユーザー分、発生させることができます。
• 3台のLotus Instant Messaging MUXサーバー。Lotus Instant Messaging Communityの疑似環境の一部となります。
• 2台のLotus Instant Messaging Communityサーバー。
• Sametime Linksアプリケーションの負荷を擬似的に発生するサーバーが1台。これは、WebSphere Application Server上で動作しています。
• ネットワーク・ディスパッチャー1台。
• 2台のSametime Linksサーバー。Lotus Instant Messaging MUXサーバーであり、Sametime Linksに必要なモジュールが含まれています。モジュールにはIBM HTTPプロセス、Sametime Linksツールキット、実行可能なSTLinkプロセスが含まれています。
• 1台のSametime Links Communityサーバー。

サーバーは全て2.4GHz のCPUひとつと1GBのメモリー、100MBのネットワーク・カードを積んだIBM xSeries 345を使いました。以下の図では、各サーバーの相関関係を示しています。

上の図では、以下のことが分かります。

• 疑似Sametime Linksのユーザーはネットワーク・ディスパッチャーへ接続する。
• ネットワーク・ディスパッチャーはユーザーのリクエストを平準化して2台のSametime Linksサーバーへ割り振る。

ソフトウェアの構成
全てのサーバーは、Windows 2000 Service Pack 4で動作しています。Lotus Instant Messaging (Sametime) 3.0をインスタント・メッセージングMUXとCommunity Server (CS) マシンとして使いました。Lotus Instant Messaging 3.1をSametime LinksとSametime Links Communityサーバー・マシンとして使用しました。Sametime Linksサーバー上でLotus Instant Messaging MUX 3.1とIBM HTTPサーバー、バージョン1.3.26.2が動作しています。

上に戻る

テスト結果

このセクションでは、CPUとメモリー使用量、トランザクション・リスポンス・タイムを含めて結果を示していきます。

CPUとメモリーの使用率/使用量
以下に示す表は、4000/8000/16000ユーザーの負荷を擬似的に加えた場合のCPUとメモリーの平均使用率/使用量を示したものです。CPUの使用率は予想した通りの結果が見られました。負荷が増えると、若干CPUの使用率が高まります。このことは、Sametime Links Communityサーバーや2台のSametime Linksサーバーに当てはまります。

表 1. 平均CPU使用率(%)

メモリー使用量(アクティブな仮想メモリー)が動作中を通じて増えていきました。

表 2. 平均メモリー使用量(MB)

CPUもメモリー使用量のいずれも、実験中のどの時点でも急上昇することはありませんでした。実験中に見られた上昇は相対的に控えめなもので、負荷の規模とクライアントからの操作内容から想定されるものの範囲内に収まっています。

平均リスポンス・タイム
以下の表は、各負荷での平均リスポンス・タイムを比較したものです。

表 3. 平均リスポンス・タイム(秒)

表に見られるとおり、平均リスポンス・ タイムはユーザーの負荷にかかわらず一貫した値を示しています。更に、8000ユーザーで12時間連続の擬似的な負荷をかけた拡張実験においてもリスポンス・ タイムが増えることはありませんでした。 以下の表は、負荷による処理されたトランザクション数を示したものです。

表4. 完了トランザクション数

これとは別に気づいたことですが、4000ユーザーでのテストの結論から10分ほどで、2台のLotus Instant Messaging MUXサーバーで約400MBの仮想メモリー急激に減りました(全体の数値はこの記事では関係ないので、上の表では示されていません)。1,2分経過すると、Sametime Links Communityサーバーのアクティブ・メモリーは40MB程度増加します。これは、4000ユーザーのテスト時のみ発生しました。この現象は異常なものでなぜそうなるのかは分かっていません。

最後の特記事項ですが、テストの最中にSametime Linksマシンがハング状態になることがありました。ローカル・コンソールでは、タスク・マネージャーが動作し画面の更新を続けていて、マウスでカーソルの位置を動かすことはできましたが、新規プロセスを起動させることはできませんでした。Sametime Links自体は動作していましたが、HTTPは動作していませんでした。このハングの問題は、httpd.confファイルのAFPエントリーをコメント・アウトして再起動すれば起きなくなることが分かりました。

上に戻る

結論と推奨内容

我々の調査の結果、Sametime Linksアプリケーションは、4000、8000、16000の疑似エンドユーザーのピークの負荷をかけてもうまく動作しました。また、リスポンス・タイムは負荷が増えても一貫した状態に保たれました。リスポンス・タイムは相対的に各負荷においても相対的に一定しており、動作している最中はどの時点でも大きく上下することはありませんでした。

CPU利用率は、実験すべてにわたって合理的な範囲で低いレベルに留まっていました。またインスタント・メッセージング・インフラに対するインパクトは最小に抑えられました。メモリー使用量(アクティブな仮想メモリー)はSametime Links Communityサーバーと2台のSametime Linksサーバーで増え続けました。そのため、メモリーの必要量はこの実験からは判断できませんでした。

これらの結果を踏まえ、典型的なSametime Linksアプリケーションは不合理なほどネガティブなインパクトをパフォーマンスやLotus Instant Messaging Communityに与えることがないと結論づけました。

参考文献

• Sametime LinksツールキットはIBM trials and betas page（US）からダウンロードできます。
  
  
• Sametime Linksについてもっと学びたい場合はSametime Links 3.1 Toolkit documentation（PDFファイル 357KB）をご覧ください。
  
  
• A tour of Sametime toolkits"（US）では、Sametime Linksやその他のLotus Instant Messaging (Sametime)プログラマー・ツールキットについて深いことを学べます。
  
  
• 「Sametime Linkにポップアップ・メニューを追加する方法」では、Sametime Linksツールキットを使って、アプリケーションにLotus Instant Messaging (Sametime) linksの機能を備えたグラフィカルなインターフェースを加える方法を解説しています。
  
  
• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• テストの準備
• テスト結果
• 結論と推奨内容
• 参考文献
• 著者について
• コメント