Watchit ツールを使用した IBM Lotus Sametime 実稼働環境のパフォーマンス測定

この記事では、Watchitツールを使って、管理者がユーザー・エクスペリエンスがどのようなものであるかをしっかりと理解するのに不可欠な情報や、変更がお客様のソリューションに及ぼす影響をさらに深く理解するのに役立つチャートを作成する方法について説明しています。 (この記事は2011年4月28日時点でのWikiを翻訳したものです。)

Jim Dewan, IBM Lotus Accelerated Value Leader, IBM Global Business Services (GBS)

Jim Dewan は、IBM Lotus の Accelerated Value Leader です。現在は、一連のツールおよびボットの設計に携わり、お客様が自社の Lotus 製品の展開をモニターしたり、デバッグしたりできるよう支援しています。Lotus Domino サーバー開発については 10 年にも及ぶ経験があり、前役職は Lotus Domino 管理チームの Project Lead でした。また、System Z の Lotus Domino Linux の取り組みにおいては Technical Lead として、アプリケーション開発、ツールキット、および企業のデータ・アクセシビリティを専門としていました。



2011年 10月 14日

はじめに

IBM Lotus Sametime のユーザー・エクスペリエンスにおいて、パフォーマンスの把握が重要なのはいつでしょうか。また、パフォーマンスを把握するためにはどうすればよいでしょうか。

最初の質問の答えは、簡単に言えば「常に」です。エンタープライズ・デプロイメントに関する経験から、ある一時点の状況やパフォーマンスを把握するだけでは不十分であり、むしろ、もっと全体的な状況やパフォーマンスを把握する必要があるということを学びました。日々、変化したり、パフォーマンスに影響を及ぼしたりする部分が多数あります。

見落としがちなのが、クライアントからサーバーへのパス全体での測定と把握です。私たちのチームはユーザー・エクスペリエンスで評価が決まるので、そのパフォーマンスを測定する必要があります。

クライアントとサーバーの両方に対応するソフトウェア環境内で大きな変化が見られるときがありますが、この場合は、初めの変化によって生じる差を把握することが重要です。一例を挙げると、パフォーマンスの問題対応に適用される修正プログラムや、パフォーマンスに悪影響を及ぼす可能性があるが導入が必要な修正プログラムなどです。

いずれの状況においても、何が得られ何が失われるかなど、その結果を把握し、その変更が完了したのか、あるいは、その問題解決の前に他に焦点を当てる必要があるのかについて最適な評価を下す必要があります。

サーバーのコード・レベルでの変更以外にも、ユーザーの Sametime ソリューションとのやりとりに関する環境設定の変更や、システムが生産性タスクを処理するうえで不可欠な変更が影響を及ぼす場合があります。環境のパフォーマンスが許容範囲内かどうかを判断するため重要と考えられるサーバー/クライアント・ソフトウェアの更新以外にもネットワーク・パスの変更、ファイアウォールの更新、および OS レベルのパッチの更新なども影響する場合があります。

このような変更は、常に会社全体に十分伝えられるわけではなく、一部の地域のみであったり、変更が生じた場所やネットワーク・トポロジーによって異なります。

要するに、数千人、数十万人ものユーザーをサポートするエンタープライズ・ソリューションに取り組むときには、対象ユーザーがそのソリューションでどういう体験をするかを事前に理解することが最善策です。それはつまり、ユーザー・エクスペリエンスを絶えずモニターし、その情報を明確に表示したり、比較したりでき、さらにその情報を有効活用できるツールを作成する、あるいは購入するということです。この記事では、まさにこうした機能を備えた、無償で提供されている Watchit ツールについて説明します。


ユーザー・パフォーマンスの理解が重要な理由

先日仕事をさせていただいたお客様は、同社の Lotus Sametime 環境に変更を加えている最中で、その変更について、実際に効果をどう測定すればいいのか困っていました。取り組んでいた構成変更は、お客様が当時運用していた実稼働環境とまったく新しい環境の構築に関するものでした。

そのため、100,000 人を超えるユーザーをサポートするのに、当時、お客様が運用していたシステムのパフォーマンスを十分に理解し、また、新設計のアップグレードした環境のパフォーマンスが、同じような負荷条件下でどうなるかについても十分理解する必要がありました。大半は新たな環境における変更で、ディレクトリ、クラスター構成、サーバーやクライアントのバージョンなどの変更でした。

常に変化していて個別の測定が難しい部分も多数ありましたが、基本的なニーズは、新しい環境への切り替え時点でエンド・ユーザーがどういったパフォーマンスを期待しているかを理解することでした。

新しい構成でのパフォーマンスがどのようなものになるかを予測するには、各地域でユーザーが現在、どう思っているかを正確に把握することが重要でした。既存のお客様の環境は世界各地のビジネス・ユニットで構成され、米国内に複数のサーバー・クラスターが配置されていました。

お客様の視点からパフォーマンスを観察する必要があるというのは、以下の点からです。

  1. ソフトウェアの測定は、サーバー・パフォーマンスではなく、エンド・ユーザーのプロダクティビティーによって判断される。
  2. エンド・ユーザーの満足度に影響を及ぼす要因は、ハードウェアにもソフトウェアにも多数存在する。
  3. ある地域のユーザーがさまざまな度合いのパフォーマンスを経験するかもしれないが、サーバーで示されるのは、各種サービスがユーザーのタスク支援にいかに貢献しているかを示す一元的なビューだけである。

だからと言って、サーバーの統計データがこの問題において重要ではないというわけではありませんが、全体像を示していないことは確かです。サーバーの統計データは、構造全体の各部がどう機能しているかについての貴重な知見を提供することはできても、ユーザーがそのソリューションについて実際にどう考えているかを示すことはできません。

下記のような Sametime サーバーの統計データはサーバーで簡単に確認することができ、現行ソリューションの作業負荷が適切に表示されます。

  • コミュニティへのログインの合計。これはモニター対象の Sametime サーバー上のコミュニティサービスへのログイン総数です。「コミュニティへのログインの合計数」チャートには、同一ユーザーの複数ログインも含まれています。たとえば、あるユーザーが Sametime Connect クライアントと Meeting Room の Participant List コンポーネントの両方からログインした場合、チャートには、このユーザーについて 2 回のログインが記録されます。
  • ユニークログイン合計。あるユーザーが複数のコミュニティサービス・クライアントから同時にログインした場合、「ユニークログイン合計」チャートには、そのユーザーのログインは 1 回だけ記録されます。複数のクライアントからログインしたユーザーは、ひとつのログインと見なされます。コミュニティサービス・ユーザーの現在の数を調べるには、このチャートを使用します。
  • 2-Way チャットの合計。Sametime サーバー上で行われた 2 者間チャットの総数。このチャートには、お客様のモニター対象である Sametime サーバーから開始されたチャットだけが含まれます。たとえば、Sametime サーバー A がモニター対象の場合、Sametime サーバー A を自分のホーム・サーバーとして指定しているユーザーが、別のユーザーとのチャットを開始すると、このチャットは 2-way チャット数チャートにカウントされます。Sametime サーバー A 以外のサーバーを自分のホーム・サーバーに指定しているユーザーが開始したチャットは、カウントされません。
  • n-Way チャットの合計。Sametime サーバー上で、3 者間またはそれ以上の人数のユーザー間で行われたチャットの総数。このチャートには、モニター対象の Sametime サーバーから開始されたチャットだけが含まれます。たとえば、Sametime サーバー A がお客様のモニター対象の場合、Sametime サーバー A を自分のホーム・サーバーとして指定しているユーザーが、別の 2 人のユーザーとのチャットを開始すると、このチャットは 「n-Way チャットの合計」チャートにカウントされます。Sametime サーバー A 以外のサーバーを自分のホーム・サーバーに指定しているユーザーが開始したチャットは、カウントされません。
  • アクティブプレイス数の合計。「アクティブプレイス数の合計」チャートには、グループチャットとアクティブな会議の合計数が示されます。グループチャットとオンライン会議は両方とも「アクティブ・プレイス」としてカウントされます。2-Way チャットはこのチャートにはカウントされません。

サーバーのトランザクション数、CPU 使用率、クラスターのトランザクション数などのサーバー統計データは、概して個々のサーバーまたはクラスターがユーザーに受け入れられるパフォーマンスかを測定する際には、どれも有用です。しかし、展開が成功かどうかのみでインフラストラクチャー全体を考慮していないような視点よりも、クライアントが満足するかどうかを判断するほうに、さらに多くの関心があります。

トータル・ソリューション、つまりネットワーク、OS、クライアント・コード、サーバー・コード、サーバー構成、およびエンド・ユーザーの地理的ロケーションすべてを考慮する唯一の方法は、各エンド・ユーザーがいる場所からユーザーによって実行された重要タスクをシミュレートすることです。

シミュレーションだけでは十分ではありません。各インスタンスからパフォーマンス統計を簡単に収集でき、統計を意味あるものにするためには、事前に収集または同時に収集した関連データを比較できる機能がなければなりません。最初はただのデータにすぎませんが、データを建設的に使用できるようになると、それが有効な知識になります。

これから説明する Watchit ツールを使用すると、管理者はログインの応答時間のメトリクス、Sametime ユーザー解決のパフォーマンス・メトリクス、およびインスタント・メッセージング (IM) 配信の応答時間を把握できるようになります。この情報は、ユーザー・エクスペリエンスがどのようなものであるかをしっかりと理解するのに不可欠であり、この情報によって、変更がお客様のソリューションに及ぼす影響をさらに深く理解するのに役立つチャートを簡単に作成できるようになります。


Watchit を使用した重要なパフォーマンス情報の取得

まず Watchit で収集できる情報の種類について簡単に説明します。考え方は単純です。

重要なタスクをシミュレートし、生成されたログ情報を使用して、記述形式の比較チャートを作成することで、ユーザーが対象ソリューションをどのように感じているかについて、事前事後または期間指定でのイメージを提供します。

それにはまず、Watchit ツールのセットアップ方法や使用する状況、実行後に必要となる、お客様の使用環境に関して効率的な判断を下すためのレポート生成方法について説明します。Watchit は Sametime Community Server ソリューションの機能およびパフォーマンスのモニター・ツールとして有用ですが、ここでは、Watchit を使用してパフォーマンス情報を収集し、作成されたデータから有用なレポートやチャートを簡単に生成する方法に焦点を当てて説明します。

Watchit ツールの全体像は、developerWorks の記事「IBM Lotus Sametime を使用した可用性、パフォーマンス、インフラストラクチャーなどのモニター」に記載されています。

Watchit を使用して重要なパフォーマンス・メトリクスを収集するのは簡単で、ツールの在席確認プラグインを実行して、以下のタスクを実行する 2 人のユーザーをシミュレートするだけです。

  1. Sametime にログインし、定義された間隔でログアウトを行います。
  2. バックエンド・ディレクトリのパフォーマンスをテストのために、ユーザー解決を実行します。
  3. 対象ユーザー間でインスタント・メッセージ (IM) を送信し、パフォーマンスと配信を測定します。

各タスクを staware.properties ファイルの構成に基づいて繰り返します (staware.properties ファイルについては、後ほど説明します)。ディレクトリ内に Watchit ツールをインストール後、2 つのファイルを編集してから、このパフォーマンス・データ収集を始める必要があります。

1つ目のファイル (watchit.properties) は、実行するプラグインを Watchit に指示するもので、この場合は図 1 のようにします。この watchit.properties ファイルは Watchit に対して、実行したいのは Sametime ユーザー・シミュレーション・プラグインのみであることを伝えます。

図 1. watchit.properties ファイルの例
watchit.properties ファイルの例

他のプラグインを同時に実行しても競合することはありませんが、ここではできる限り単純化しています。

watchit.properties ファイルが準備できたら、次に、在席確認のプラグインを構成します。このプラグインには staware.properties ファイルを使用します。図 2 はこのファイルの例を示しています。

図 2. staware.properties ファイルの例
staware.properties ファイルの例

Sametime のユーザー 1 とユーザー 2 の情報は、developerWorks の記事「IBM Lotus Sametime を使用した可用性、パフォーマンス、インフラストラクチャーなどのモニター」に記載されていますが、ここでは特に、最初のセクションと、これらの変数が実行内容に与える影響に焦点を当てます。特に、Check_Interval、Logout_Timeout、および IM_Interval を見ていきます。表 1 には、これらの変数の説明が記載されています。

表 1. 在席確認プラグインのパフォーマンスしきい値
関数しきい値
Check_Interval=xユーザーがインスタント・メッセージを交換する時間 (分)
Logout_Timeout= xユーザーの再ログインが必要になるまでの時間 (分)
IM_Interval=x次のインスタント・メッセージを送信するまで待機する時間 (秒)

Check_Internal は重要です。シミュレートされたユーザーが IM 機能を実行する時間を制御するもので、結果的にログイン回数や解決頻度にも関係するためです。ユーザーが最初にログインしたときには、ユーザー解決も実行されます。

これらが完了すると、在席確認プラグインは所定の間隔が経過するまで IM タスクを実行します。つまり、間隔の値が小さいほど、パフォーマンス・メトリクスのテスト・サンプルにおけるログインとユーザー解決の数値が増えるということです。間隔が長い場合は、IM テストの数が増えますが、ログインおよびユーザー解決の数は減ります。

必要に応じて、これを活用して特定の機能のテスト回数を増やすこともできます。たとえば、環境内にウィーク・リンクの可能性を疑っている管理者は、ログインやユーザー解決の数を増やしたいと考えている場合などです。

あるいは、IM の待ち時間がある場合は、IM に焦点を当てるために間隔の長い設定が好まれます。それぞれのニーズに応じて調整できるところが、このツールの柔軟性の高さでもあります。ユーザーによる切断の場合も、Check_Interval を長くして、ログイン中にユーザーの接続が失われるかどうかを確認します。

Logout_Timeout は、Check_Interval の完了からテスト再開までの時間です。所定の時間内でサイクルを繰り返すことが目的である場合は、この値を小さくしてください。ユーザー・シミュレーションを実施する場合は、すぐにログインしなおすのではなく、十分に長い時間を設定するほうがよいでしょう。ここの考え方も柔軟性です。

IM_Interval は標準的な応答時間になるように設計されています。標準的なユーザー応答の場合、応答するまでに数秒間かかるため、送信者へのIM を瞬時に送ることはありません。この値にはそのような機能がありますが、サンプル・テストの間にできるだけ多くの IM を実行することが目的であれば、この値をかなり低い値にする必要があります。

Debug: この設定は、レポート・ジェネレーターへの適切なロギングを生成するために必要となります。適切なロギングが得られるように、staware.properties ファイルで "Debug=true" を使用してください。含まれていない場合は、基本情報のみがログに記録され、レポートは生成されません。


パフォーマンス測定を実行するタイミングと場所

意外にも、平均ログイン回数、平均ユーザー解決回数、および IM 件数を把握していない管理者が少なくありません。では、重要なことから片付けましょう。現行の期待値を決定するには基準値を得る必要があります。

これは簡単です。Watchit ツールを毎日、営業時間内の間、実行するだけです。実行するたびに所定の形式でログが生成されます。

	watchit_YYYYMMDD_HH_MM_SS.log.

サンプルのログ・ファイルを図 4 に示します。

図 4. Watchit の実行により生成されたサンプルのログ・ファイル
Watchit の実行により生成されたサンプルのログ・ファイル

このログ・ファイルには、ログイン回数、ユーザー解決回数、IM 配信回数に関する必要なパフォーマンス・データを収集するために、管理者が必要とする情報がすべて含まれています。1、2 週間にわたってこれらのログを収集すれば、パフォーマンスの現状を把握できます。それでは、環境に変更が加えられたときはどうすればよいでしょうか。

基本的には、変更を加えた状態で同じことを実行します。新しい環境の場合は、以前の環境で行っていたものとまったく同じテストを再現するために、従来の間隔で同じテストを実行する必要があります。対象の Sametime チームが環境に施された変更に気が付いていない場合でも、基準値を把握しているお客様からパフォーマンスに関する苦情の電話が寄せられるようになった場合は、お客様のパフォーマンスと現在の Watchit データが問題の根本的原因を特定するうえで重要となります。


有益な応答時間レポートの作成

実行によりログが作成されると、レポート生成の選択肢が増えます。ログを単独で、または結合して処理すれば、任意の期間のパフォーマンスについてイメージがつかめます。

たとえば、Watchit ツールを毎日実行した場合、週 5 日分のログを結合し、レポート・ジェネレーターを実行することで、データ表示を週単位で生成することができます。ただ、それだけです。特定の曜日におけるソリューションの実行状況 (例: 月曜にだけ問題が発生する場合) がわかると、特定の曜日における容量のニーズを把握するのに役立ちます。また週単位の表示により、ログイン回数、ユーザー解決回数、または IM 配信回数のデータ (平均、最小、最大、および中央値) について、より大きな規模のサンプルが得られます。

生成されるレポートは 2 種類あります。1 つは一般的なテキスト・レポートで、もう 1 つは、スプレッドシートに組み込んで有益なチャートを生成するのに使用されます。レポート生成スクリプトは UNIX シェル・ベースの解析ツールで、どの UNIX シェルまたは Cygwin Microsoft Windows 環境でも実行できます。

テキスト・レポート

最初に、Watchit ツールの実行により、またはログの結合により生成できる単純なテキスト・レポートから説明します。図 5 はテキスト・レポートの例を示しています。テキスト・レポート、または .csv レポートのどちらを生成する場合も、表示されるデータは同じです。

  • ログイン、ユーザー解決、および IM 配信の最大応答時間
  • ログイン、ユーザー解決、および IM の最小応答時間
  • ログイン、ユーザー解決、および IM 送信の総数
  • ログイン、ユーザー解決、および IM 配信の平均応答時間
図 5. ログイン、ユーザー解決、および IM 配信の応答時間の中央値
ログイン、ユーザー解決、および IM 配信の応答時間の中央値

図 5 のレポートを生成するのに必要なコマンドはたったの 1 つです。

	./process_bot_output.sh <logfile.log>

これらのテキスト・レポートは、お客様が使用している環境について、ユーザー応答時間をすばやく簡単に評価するための手段です。Watchit ツールを実行中のコンピューター上でもレポートを実行できるため、システムの現状に関する受容性について、リアルタイム・データをいつでも得ることができます。

こうした個々の実行に関する応答時間レポートは、特定ユーザー間の対話を理解するのに役立ちますが、通常は応答時間の変化を詳しく調べたり、比較対照の環境を調査したりするために、複数の環境を対比させたレポートの生成に適しています。

この記事の冒頭で、環境を比較することについて、お客様の環境における、週単位の変更、または構成後もしくはソフトウェア変更後の変更を把握したり、既存の本番環境と新しい環境を比較したりすることなど、さまざまな理由を説明しました。

パフォーマンスの差分を理解し、適切なパフォーマンスの目標値を設定することは、変更の実装や新しい環境のデプロイメントの成功において重要となる場合が多いです。デバッグの観点からすると、お客様からパフォーマンスの低下について報告を受けた場合に、シミュレーションで報告される内容は非常に役立ちます。これにより、問題の特定と、より迅速な解決が可能になります。

グラフィカル・レポート

Watchit ツールでは、簡単な方法でグラフィカル・レポートを生成でき、結果の比較が簡単にできます。Watchit インスタンスを新しい環境と以前の環境の両方で実行して過去の週の結果と最新の結果を比較するか、仕様構成変更の実施前と実施後で比較するか、どちらか一方を行うことが目標です。

ユーザーからパフォーマンスの問題が報告された場合は、過去の週の Watchit の結果を調べ、ログとレポートについて差分の有無を確認するのも役立ちます。Watchit によって提供される情報が多ければ多いほど、パフォーマンスの問題に対応する際に、エンド・ユーザーに与える影響が小さくなります。

これらのグラフィカル・レポートを生成するのは簡単です。ほんの少し手順を追加すれば、テキスト・レポート作成用の Watchit ツールで生成された同じログを、グラフィカルな Microsoft Excel ベースのチャート (または任意のスプレッドシート製品) の生成にも使用することができます。

この機能を有効にするために、Watchit に追加構成オプションを設定する必要はありません。代わりに、“process_bot_output_xls.sh” というスクリプトが Watchit パッケージには含まれています。このスクリプトは、スプレッドシートにインポートされるカンマ区切りのファイルを生成します。この例では、 Microsoft Excel を使用して目的としてのトラブルシューティングを実演・活用します。これが、管理チームに提示される最も一般的なタスクだからです。ただし、構成変更のテストや異なるクラスターや環境の比較の際にも、同じ方法を適用できる点にご留意ください。

ユーザーがいる場所で Watchit インスタンスを実行することが目的です。この例では、単一クラスターが米国に配置され、米国と米国以外の国や地域の両方にユーザー・ポピュレーションがあるというシナリオを活用します。2 つの Watchit インスタンスを比較するために、大規模な環境内にある 2 つのクラスター間のメトリクスを比較したいと思います。

2 つの Watchit インスタンスを作成して、1 つは米国のデータ・センターに、もう 1 つはアジアに配置します。両方の環境で 1 週間にわたって Watchit を実行したら、次に管理者は、さまざまな Sametime タスクについてエンド・ユーザーのパフォーマンスを比較したいと考えます。こうすることで、米国ユーザーと比較した場合に、アジアのリモート・クライアントのサポートにおいて、どの程度のパフォーマンス損失が (クライアント側で) 発生するかが明らかになります。

以下の手順でレポートを生成します。

1. ./process_bot_output_xls.sh スクリプトをボット・ログ・ファイルに実行します (ボットを停止する必要はありません)。

syntax: ./process_bot_output_xls.sh watchit_010101:12:00:00.log series1 > series1.out
First parameter = Watchit log name; Second parm is series name for charting
Do this for each Watchit instance you want to compare

2. 次のコマンドを使用して、すべての seriesX.out ファイルを 1 つのファイルにまとめます。

cat series*.out > total_series.out

3. ここで Excel レポートを生成します。付属のエージェント・コードを使用して、結合された出力ファイルからレポートを自動生成します。この記事には “Watchit_Report_Generator.nsf” データベースとエージェントが付属しており、任意の Notes クライアントで実行すると、ログイン、解決、および IM パフォーマンスの各レポートが自動生成されます。

4. 図 6 に示すように 「作成 (Create)」、「Watchit データの処理 (Process Watchit Data)」の順に選択して、レポート・ジェネレーターを実行します。

図 6. レポート・ジェネレーターの実行
レポート・ジェネレーターの実行

サンプルの自動レポートは、別の Excel インスタンスに表示されます。図 7 は、各シリーズ間のログイン比較を、図 8 は解決の比較を示しています。

図 7. Watchit のログイン・レポートのサンプル
Watchit のログイン・レポートのサンプル
図 8. 解決レポートのサンプル
解決レポートのサンプル

図 9 は 複数のシリーズ (ボット・インスタンス) の IM 配信の比較として、各シリーズの process_bot_output_xls.sh スクリプトの出力を結合して生成したものを示しています。ここでは上記に示すように、2 つの出力を使用しました。

図 9. IM 配信のレポートのサンプル
IM 配信のレポートのサンプル

結論

ユーザー・エクスペリエンスを理解し、それを迅速に測定できることが、展開の状況をより正確に把握するうえで強力なツールとなります。変更がパフォーマンスに及ぼす影響の測定、傾向の追跡、およびトラブルシューティングは、Watchit ツールといくつかの簡単なスクリプトを使用するだけで、ずっと簡単になります。ご使用の環境におけるパフォーマンスのスナップショットをただちに取得することで、問題を探し出し、傾向を特定し、損失を抑えるのに役立つ貴重な情報が得られます。

Watchit は柔軟性に優れているため、どのワークステーションからでも実行でき、構成にも時間がかかりません。さまざまな方法 (問題の再現とアラート、週 7 日 24 時間体制のモニター、および構成変更に及ぼすパフォーマンスの影響) で活用される Watchit を適用することで、どのような状況でも問題やユーザー・エクスペリエンスの状態をすばやく把握できます。

パフォーマンスとは、単なるサーバー統計データではありません。ユーザーのワークステーションからサーバーまでパス全体が、お客様の展開のパフォーマンスや機能を示す全体像なのです。Watchit を使用すれば、ソリューションを維持するうえで、可能な限り多くの情報に基づいて判断を下せるようになります。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=764894
ArticleTitle=Watchit ツールを使用した IBM Lotus Sametime 実稼働環境のパフォーマンス測定
publish-date=10142011