ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Sametime >

LDD Today

Sametime Meeting 3.0と2.5のパフォーマンス比較

by Bill MasekおよびBruce Webster
レベル：中級者
対象: Sametime
原文の掲載：2003年4月1日

LDD Todayの原文（US）

インデックス

	テストのセットアップ
	テスト結果
	まとめ

Lotus Sametimeは、市場をリードするインスタント・メッセージおよびWebカンファレンス用のプロダクトです。Sametime機能の中の重要なコンポーネントに、インスタント・メッセージ、ストリーミング・オーディオ/ビデオ、共用ホワイトボード、および共用アプリケーションなどのオンライン・ミーティング実施機能があります。

このPerformance Perspectiveコラムでは、Sametime 3.0 MeetingとSametime 2.5のパフォーマンスを比較するために行ったテストについて検討します。これらのテストでは、ユーザーの作業負荷を小規模サーバー上でシミュレートし、サーバーのパフォーマンスに影響が出るまで徐々に負荷量を増やしました。以下で説明するように、Sametime 3.0サーバーは一定時間内に2.5サーバーより多くのユーザーをミーティングにログインさせることができました。さらに、Sametime 3.0ユーザーの方がSametime 2.5ユーザーよりスピーディーにミーティングに参加できました。

このコラムでは、読者がSametimeの機能および用語に習熟しているということを前提にしています。Sametime 3.0の機能の詳細については、LDD Todayの記事『A preview of Sametime 3.0』を参照してください。

テストのセットアップ

以下のセクションでは、ハードウェア、ソフトウェア、および作業負荷テストのセットアップについて説明します。

ハードウェアおよびソフトウェア
今回の調査では、IBM Lotus Technical Supportから入手できるhotfixの上で動作するSametime 2.5とSametime 3.0を比較しました。テストは小規模の部門サーバーで実行されましたが、これらのローエンド・サーバーがあえて選ばれたのは、「拡張性の低い」パフォーマンスのシナリオを使うためでした。各サーバーとしては、4台のPII 200MHzプロセッサーを備えたIBM 704 PCが使われました。Sametime 2.5のテストは512MBメモリーのサーバーで、またSametime 3.0のテストは512MBメモリーのサーバーおよび1GBメモリーのサーバーで行われました（これは、ラボのハードウェアが使用できるかどうかという状況のためです。メモリーの違いによるパフォーマンスへの影響は無視できる程度のもので、3.0のテストでは、両方のメモリー構成で同じ結果が得られました）。各サーバーはWindows 2000を稼働させ、100MBのネットワーク・カードでネットワークに接続されていました。

テストでは、社内で開発された負荷ツールが使用されました。各シミュレーション・ユーザーはHTTPプロトコルを使ってサーバーに接続し、次いでカスタマイズされたミーティング・ルーム・クライアントを起動しました。カスタム・クライアントは標準Sametime APIを使用しましたが、クライアント・コードについては、テスト・ドライバーへの負荷を軽減するために変更を加えました。ホワイトボード・ページの画像は普通にクライアントにダウンロードされましたが、テスト・ドライバー内のメモリー・フットプリントを最小限に抑えるため直ちに破棄されました。クライアントは、クライアントGUIの構築も表示も行いませんでした。このテストでは、Sametimeのサーバー・コードは変更されませんでした。

作業負荷
テストでは、いくつかの重要な変数が比較されました。第一の変数は、一定期間内にミーティングに参加したユーザー数です。同時ユーザーが300人、600人、750人の場合のパフォーマンスへの影響が測定されました。各ミーティングでは、5人のユーザーがホワイトボード上のプレゼンテーションを共用しました。

Sametime Meetingサーバーの典型的なビジー時間のピークと同様のテスト用作業負荷が計画されました。シミュレーション・ユーザーは2つのグループに分かれてミーティングを開始しました。1つのグループは1時間の会議を行い、もう1つのグループは30分間の会議を行いました。ユーザーは、テスト前20分以内にミーティングに参加し、ミーティングが始まると、テスト・ユーザーの1人は、ミーティングの発表者となってプレゼンテーションのスライドをめくり、それ以外のテスト・ユーザーはミーティングの参加者となって発表者のスライドを見る役目をしました。

このテストのミーティング参加者は、5人のテスト・ユーザー（発表者1人と聞き手4人）です（調査によると、これがIBMでの電子ミーティングの平均的な大きさです）。
作業負荷は、3つの主なステージでタスクを実行します。3つの主なステージとは、ミーティングのスケジュール、バックグラウンド負荷の準備、およびアクティブなサーバーのシミュレーションです。マルチステップのプロセスを取り込めるこの能力は、以前の作業負荷からの進歩を表しています。

ステージ1：ミーティングのスケジュール
サーバーの作業負荷がテストの前に実行され、ミーティングをスケジュールします。ミーティングの半数は、テストの開始時に始まるようスケジュールされており、残りは55分後に開始されます。ミーティングは、通常、実際のミーティングのかなり前にスケジュールされたため、作業負荷はテストの前にすべてのミーティングをスケジュールしました。
ミーティングがスケジュールされると、21枚のスライドが含まれる5MBのフリーランス・プレゼンテーションもサーバーにアップロードされました。各ミーティングで同じプレゼンテーションを使いましたが、毎回固有のプレゼンテーションのコピーが受信されました。

ステージ2：バックグラウンド負荷の準備
このステージで、実際のテストが開始されました。このステージは次のステップで構成されていました。

20分間のランプ・アップ・タイムでテスト・ユーザーの半分をスタート
5分間待つ（数人のテスト・ユーザーは、ランプ・アップ・タイム終了直前にスタートしました。こうすることで、開始時間とテスト時間をはっきりと区別できました）
ホワイトボードの作業負荷を30分間加える。この期間が純粋なミーティング関係の負荷を表します。発表者は、プレゼンテーションの全ページを1分間1枚の速度でめくります。実際のホワイトボードでのプレゼンテーションは、発表者がミーティングに参加すると直ちに始まります

ステージ3：アクティブなミーティング・サーバーのシミュレーション
このステージは、テスト開始の55分後にスタートしました。サーバーは、残りのテスト・ユーザーを20分間隔でスタートし、ステージ2のステップ2と3を実行しました。テストのこのステージでは、ミーティングはすべて開始されており、ユーザーはミーティング中かミーティングに追加済みの状態でした。

サーバーのテストは、複数のドライバーを使って行われました。各ドライバーは、ユーザーを20分間のランプ・アップ・タイムで均等にスタートさせました。

各テスト・ユーザーは次のタスクを実行しました。

サーバーに接続
サーバーにログイン
アクティブなミーティングのリストを表示。1ページにおさめるにはミーティングの数が多すぎる場合は、ミーティングの次のページをダウンロード
ミーティングへのリンクを開く
ミーティング・アプレットをダウンロード
ミーティング・クライアントをドライバーでスタート（標準アプレットがダウンロードされましたが、テストではカスタム・クライアントが実行されました）
（発表者が）ホワイトボードのページをめくり始める

ユーザーの考慮時間をシミュレートするために、ステップ間には3～15秒間のポーズがありました。

上に戻る

テスト結果

8つのテストを、300人、600人、750人のテスト・ユーザーを使って、小規模テスト・サーバー上のSametime 3.0およびSametime 2.5の両方で実行しました。両サーバーとも、300人のテスト・ユーザーのサポートは容易でした。Sametime 3.0のサーバーは、600人のテスト・ユーザーも効果的にサポートしました。重い負荷にもかかわらず、両サーバーともすべてのテストの間動作し続けました。

CPU使用量
次の表は、Sametime 2.5のテストで得られたCPU使用量の割合を示しています。

ユーザー	ミーティングの作成 (ステージ1)	ミーティングへの参加 (ステージ2)	ミーティングの実行 (ステージ2)	ミーティングへの参加 (ステージ3)	ミーティングの実行 (ステージ3)
300	39.5	65.0	32.6	62.0	31.4
600	54.6	95.6	55.0	95.2	37.4

上の表の「ユーザー」の列は、各テストにおけるシミュレーション・ユーザーの人数です。表中の他の数字はすべて、CPU時間の割合を表しています。たとえば、300人のユーザーが使われたテストでの作業負荷は、ミーティング作成時に使用可能CPUの39.5%、300人のユーザーの最初の半分がミーティングに参加したときに65%、次の半分が参加したときに62%を使用しています。この表が示すように、ユーザーが600人になると、ミーティング参加時にCPUは「飽和状態」（95%以上の使用率）になります。

次の表は、Sametime 3.0でのCPU使用量を表しています。

ユーザー	ミーティングの作成 (ステージ1)	ミーティングへの参加 (ステージ2)	ミーティングの実行 (ステージ2)	ミーティングへの参加 (ステージ3)	ミーティングの実行 (ステージ3)
300	20.0	61.7	4.0	49.0	5.7
600	28.4	76.3	31.4	85.7	24.0
750	44.9	99.2	33.8	95.4	35.0

表からわかるように、Sametime 2.5では600人でCPUが飽和状態になるのに対して、Sametime 3.0ではユーザーが750人のときにCPUが飽和状態に達します。飽和状態に達するまで、Sametime 3.0は、テスト実行のほとんどのステージでSametime 2.5に比べてかなり少ないCPUしか必要としません。

ページ・トランザクション
パフォーマンスの別の評価手段として、ページ・トランザクションの数があります。次のグラフでは、ユーザー数が300人、600人、750人の場合のSametime 3.0と2.5のページ・トランザクションを比較しています。

このデータを見ると、ミーティングが一度開始されると、Sametime 3.0のテスト・サーバーはテスト・ユーザーが750人でもミーティングを実行できることがわかります。

ミーティングへの参加
現実の環境では、ミーティングに参加するユーザーはミーティング・サーバーに接続し、ミーティングを見つけ、ミーティングを開き、ミーティング・ルームのアプレットを起動します。今回のテスト・ユーザーは、これと同じステップを同じ手順で実行しました。このセクションでは、ユーザーがミーティングに参加している間のサーバーのパフォーマンスについて考えてみます。

ミーティングへの接続
テスト・ユーザーはまずSametimeサーバーに接続します。ブラウザーでは、これによりSametimeサーバーがSametime開始画面として表示されます。様々なテストの接続時間のグラフを下に示します。

（テスト・ユーザーが150～375人の場合）ステージ2では、Sametime 3.0サーバーの動作の方が高速ではあるものの、両方のサーバーが妥当なパフォーマンスを維持しています。（テスト・ユーザーが300～750人の場合）ステージ2では、Sametime 3.0が適度な応答時間でより多くのユーザーをサポートしています。

ミーティングを見つける
次に、テスト・ユーザーはサーバー上のアクティブなミーティングをリストし、適切なミーティングのURLを見つけます。ミーティング表示をリストするのに必要な時間のグラフを下に示します。

これらの結果は、接続時間の結果と似ています。つまり、シミュレーション・ユーザーが600人のとき、Sametime 3.0はSametime 2.5より優れたパフォーマンスを発揮します。

ミーティングへの参加
最後に、シミュレーション・ユーザーがミーティングに参加します。次のグラフはその結果を示したものです。

上の3つのグラフはすべて同じことを表しています。つまり、Sametime 3.0は、600人のテスト・ユーザーを妥当なパフォーマンスでサポートするということです。Sametime 2.5サーバーではユーザーが300人の時点からパフォーマンス上の問題が見られます。次の表は、ユーザーが300人の場合のパフォーマンス時間の違いを示したものです。

トランザクション	Sametime 3.0（秒）	Sametime 2.5（秒）	差（秒）	パーセントで表した差
接続	0.9	1.4	0.5	39
ミーティングを表示	1.4	1.4	0	0
ミーティングを開く	3.5	3.3	-0.2	-6

次の表は、ユーザーが600人の場合のデータです。

トランザクション	Sametime 3.0（秒）	Sametime 2.5（秒）	差（秒）	パーセントで表した差
接続	1.3	5.8	4.5	446
ミーティングを表示	3.0	7.6	4.6	253
ミーティングを開く	6.5	14.4	7.9	222

テスト・ユーザーが300人の場合、ミーティングを表示したり開いたりするトランザクションの速さはほとんど同じですが、接続速度はSametime 3.0の方がSametime 2.5より約40%速くなります。テスト・ユーザーが600人の場合には、Sametime 3.0サーバーの方がはるかに速くなります。Sametime 3.0サーバーは、キャパシティーが大きいだけでなく、パフォーマンスもより優れています。

ミーティングのパフォーマンス
シミュレーション・ミーティング終了後、サーバーがページをクライアントに届けるのにかかった時間を測定しました。次の表に結果が示されています。時間の単位はすべて秒です。

ユーザー	Sametime 3.0 (ステージ2)	Sametime 3.0 (ステージ3)	Sametime 2.5 (ステージ2)	Sametime 2.5 (ステージ3)
175	1.79	2.86	1.53	13.19
300	1.71	2.84	1.60
375	1.66	2.74	1.56

平均時間はSametime 3.0の方が少し長くなっています。

パフォーマンスについての考慮事項
このセクションでは、読者が自分のSametime環境のパフォーマンスを予想する手助けとなるベスト・プラクティスを提供できそうな結果について説明します。

CPUのプロファイル
テスト完了後、私たちは各ステージの終了時にCPU使用量があるパターンを描いていることに気付きました。そこで別のテストを実行し、次の結果を得ました。

このグラフは、「CPUのプロファイル」を表現しています。CPU使用量はステージ1でミーティングがスケジュールされるときに増加します。ステージ2では、最初のミーティングの一団が実際に開始されたときに、CPU使用量がかなり急激に上昇します。ミーティングが開始されると使用量は下がりますが、最初のユーザーの一団がミーティングに参加するときには、まだかなりの負荷がサーバーにかかっています。ミーティングを表示するには、CPU時間はほとんど必要ありません。次にCPU使用量が急激に上昇するのは、ステージ3で残りのミーティングが開始されたときです。

このプロファイルは、読者のSametimeサイトにおけるCPU使用量の良い目安になるでしょう。ミーティングのスケジュールと参加が一般的にSametime使用中最もCPUを必要とする部分であり、そうしたときにユーザーがパフォーマンス上の問題に気付く可能性が高いということに注意してください。

その他のヒント
他のパフォーマンス・テストと同様、実世界の環境のシミュレーションが試みられました。しかし、どれほど注意深くテストを行おうと、考えられるすべての顧客のコンフィギュレーションに完全にマッチさせるのは不可能です。たとえば、今回のテストには、Sametimeのパフォーマンスに大きな影響を与える可能性のある次の要素は含まれていません。

ネットワーク
Sametime Meetingは、ネットワーク主体です。長い待ち時間と狭い帯域幅での接続は、パフォーマンスに影響します。今回のテストは、接続速度100MBで待ち時間のないラボ環境で行われました。

AppShare
この作業負荷がかかるのはホワイトボードだけです。ホワイトボードの場合、サーバーは必要に応じて各ページをダウンロードします。AppShare環境では、発表者が画面とマウスのアップデートを絶えずサーバーに返送します。するとサーバーは、残りのクライアントにそのデータをリレーします。AppShareでは、サーバーにより負荷がかかります。

オーディオ/ビデオ
オーディオ/ビデオによるミーティングには、さらに帯域幅が必要です。

小さなローカル・ユーザー・ディレクトリー
ユーザーはローカル・サーバーで認証されます。ディレクトリー内の名前は10,000未満です。今回のテストでは、ディレクトリーのパフォーマンスは問題となりませんでした。

サーバー
前述のとおり、テストはエンタープライズ・サーバーではなく小規模の部門サーバー上で実行されました。サーバーのCPUが飽和状態になると、パフォーマンスは低下し始めました。他のテストでは、容量の大きいサーバーならより多くのユーザーをサポートできることがわかりました。

上に戻る

まとめ

Sametime 3.0と2.5を比較して、主に次のことがわかりました。

Sametimeでの主要なパフォーマンス制約はミーティングへの参加です。この面では、Sametime 3.0のパフォーマンスはSametime 2.5より大幅に優れています。
Sametime 3.0では、一定の時間内にSametime 2.5より多くのユーザーをミーティングにログインさせました。
ユーザー全員がミーティングに参加した後は、各サーバーへの負荷が大幅に減少しました。
Sametime 3.0では、プレゼンテーションでページをめくる平均時間が若干遅くなりました。

最後のメモ：このシミュレーションでローエンドのSametime 3.0サーバーがサポートする最大同時ユーザー数は750人でしたが、別の作業負荷モデル（たとえば、「ユーザー参加」の密度が低いモデル）またはより強力なハードウェア構成の場合は、これよりかなり多くのユーザー数をサポートできたでしょう。
このPerformance Perspectiveコラムが読者の役に立てば幸いです。ご意見・ご感想をお待ちしています。

著者について
Bill MasekはIBM Lotus Product Engineeringチームの一員で、ツールを開発し、パフォーマンス・テスト・プロジェクトの指揮をとるソフトウェア設計者です。開発の経験もあるので、パフォーマンスをプログラマーの視点から見ることができます。化学者向けの「スマートな」サンプル準備システムなどを構築した実績があり、MITでコンピューター・サイエンスの修士号を取得しています。出身はカリフォルニアで、合唱団で歌うこととボードゲームが大好きです。

Bruce WebsterはIBM Lotus Product Engineeringチームのアドバイザリー・ソフトウェア・エンジニアで、このグループの創設以来、パフォーマンス関連の業務に携わっています。Notesアプリケーションの開発者でもあり、フリーのコンサルタントとして、またLotus Consulting Groupの一員として仕事をしています。Bruceのキャリアはもともと1984年にLotusで始まりましたが、現在は、Domino、Sametime、およびQuickPlaceのパフォーマンス・シミュレーションと分析が専門です。余暇は、少年野球とバスケットボールのコーチとして過ごしています。

上に戻る