論理設計、アーキテクチャー設計および配備設計で使用できる基本サイズを確立する必要があります。 技術担当者は、Portal Server の配備で必要になる CPU の数の見積もりを算出する自動サイジングツールを提供します。
Sun JavaTM System Secure Remote Access ソフトウェアを使用した安全性の高いポータル配備のサイジング要件は、「Secure Remote Access の使用状況分析」で説明されています。
サイジングツールへの入力値として、次のメトリクスを収集する必要があります。
Portal Server の配備で必要になる CPU の数に影響を与えても、サイジングツールでは使用されないその他のパフォーマンスメトリクスは次のとおりです。
ポータルデスクトップ設定
ハードウェアとアプリケーション
バックエンドサーバー
トランザクション時間
ワークロード条件
これらのパフォーマンス要因については、続くセクションで説明します。
最大並行セッション数は、配備される Portal Server で処理可能な接続ユーザー数を定義します。
最大並行セッション数を計算するには、次の計算式を使用します。
最大並行セッション数 = オンラインユーザーの予想割合 * ユーザーベース
企業ポータルの見込みユーザーのユーザーベースサイズまたはプールサイズを特定するには、次の提案を参考にしてください。
アクティブなユーザーのみを識別します。たとえば、休暇や休日をとっているユーザーは対象にしません。
ユーザーベースには有限数を使用します。匿名ポータルの場合は、この数字を控えめに見積もります。
アクセスログを調べます。
ユーザーベースの地理的な場所を識別します。
ビジネス計画の中でユーザーについて記述した内容について忘れないでいてください。
ページ要求間の平均時間は、Portal Server からユーザーがページを要求する頻度の平均です。ページには、ポータルにログインしたときの最初のログインページや、ポータルデスクトップからアクセスする Web サイトや Web ページなどがあります。1 ページの表示とは、ページに配置されているアイテム数に関係なく、1 回の呼び出しで表示される 1 つの情報ページを指します。
Web サーバーのログにはページ要求が記録されますが、ログを使用して要求から要求までの平均時間をユーザー単位で計算することはできません。ページ要求間の平均時間を計算するには、WebLoad パフォーマンステストツールのような市販の統計ツールが必要です。ツールを使用して得られた数値を基にして、並行処理ユーザー数を判断できます。
ストレステストを実行する場合は、SLAMD Distributed Load Generation Engine を使用できます。SLAMD の詳細については、http://slamd2.dev.java.net/ を参照してください。
ページ要求を基準にすると、「ヒット数」を基準にするよりも Web サーバーのトラフィックを正確に測定できます。Web サーバーからのファイル要求は、1 ヒットとして毎回計上されます。ページにあるすべてのアイテムが登録されているので、1 回のページ呼び出しで何度もヒットが記録されます。たとえば、10 個のグラフィックファイルが組み込まれているページの場合は、HTML ページ自体で 1 回、および 10 個のグラフィックファイルそれぞれが 1 回ずつカウントされ、合計 11「ヒット」が記録されます。したがって、ページ要求を基準にしたほうが Web サーバーのトラフィックをより正確に判断できます。
並行処理ユーザーは、実行中の Web ブラウザプロセスに接続し、Portal Server に要求を送信するか、要求の結果を受信しているユーザーです。最大並行処理ユーザー数は、あらかじめ定義された時間内に接続可能な並行処理ユーザーの最大数です。最大並行処理ユーザー数は、最大並行セッション数を算出してから計算します。最大並行処理ユーザー数を計算するには、次の計算式を使用します。
並行処理ユーザー = 並行セッション数 / ヒット間の平均時間
たとえば、ユーザーが 50,000 人のイントラネット Portal Server の例について考えます。負荷ピーク時に接続されているセッション数を、登録されたユーザーベースの 80% と見積もります。ユーザーは、平均で 10 分に 1 回の割合でポータルデスクトップにアクセスします。
この例の場合の計算方法は次のようになります。
40000 / 10 = 4000
したがって、この Portal Server の負荷ピーク時に接続できる最大並行処理ユーザー数は 4,000 人になります。
平均セッション時間は、多くのユーザーを対象に算出した、ログインからログアウトまでの平均時間です。セッション時間の長さは、発生するログイン数に反比例します。つまり、セッション期間が長くなると、同じ並行処理ユーザーベースでの Portal Server に対する毎秒のログイン数が少なくなります。セッション時間は、ユーザーのログインからログアウトまでの時間です。
平均セッション時間は、多くの場合、ユーザーの Portal Server の使い方によって変化します。たとえば、対話型のアプリケーションが関係するユーザーセッションの場合は、情報のみのユーザーセッションの場合よりも、セッション時間が長くなるのが一般的です。
ポータルサイトで検索チャネルを提供する場合は、検索エンジンのサイジング要素をサイジングの計算に含める必要があります。検索エンジンのサイジング要件は、次の要素によって決まります。
インデックスディレクトリのアクティブリストにあるインデックスパーティーションのサイズ
パーティーションサイズは、インデックス付きの検索可能な用語のサイズと数に正比例します。
リソース記述 (RD) に必要な平均ディスクスペース
次の式を使用して計算します。
必要な平均ディスクスペース = データベースサイズ / データベース内の RD 数
平均サイズは、RD サイズの変動に合わせて調整されます。多くのインデックス付き用語を使用した長くて複雑な RD の集合と、少数のインデックス付き用語による短い RD のリストでは、複雑な RD に同じ数の RD があっても、必要な検索時間が異なります。
RD は階層型データベース形式で保存されます。この形式では、RD が保存されていなくても、データベースの組み込みサイズを考慮する必要があります。
検索関連のアクティビティーを実行する並行処理ユーザーの数
次の式を使用して計算します。
並行処理ユーザー数 / 検索ヒット間の平均時間
「並行処理ユーザー」で計算される並行処理ユーザー数の値を使用します。
検索関数のタイプには、基本、結合、近接、パッセージとフィールド演算子、およびワイルドカードスキャンなどがあります。それぞれの検索関数では、異なる検索アルゴリズムとデータ構造を使用します。検索アルゴリズムとデータ構造の違いは、検索用語数とインデックス付き用語数が増加するのにつれて大きくなるので、検索関数のタイプは検索結果が返されるまでの時間に影響します。
認証されたポータルを使用する場合は、自動サイジングツールのページ設定セクションにある「Login Type」と「Desktop Type」の両方を指定する必要があります。
Login Type。エンドユーザーがユーザー名とパスワードを入力したときに、エンドユーザーに最初に表示されるポータルページ (コンテンツ設定と配信方法) のタイプを記述します。このプロセスでは、資格の確認、セッションの初期化、および初期コンテンツの配信などが行われるので、システムにかかる負担が大きくなるのが一般的です。
ログインタイプに関連する測定された CPU パフォーマンスの特性は、Initial Desktop Display 変数です。
Desktop Type。最初のポータルページのあとにエンドユーザーに表示されるポータルページ (コンテンツ設定と配信方法) のタイプを記述します。これらのページは、そのあとに続くポータルとの対話型操作のたびに、またはデスクトップを更新したときに表示されます。セッションがすでに確立され、キャッシュされたコンテンツを利用できるので、通常必要とするシステムリソースが少なくて済み、ページがより短時間で配信されます。
デスクトップタイプに関連する測定された CPU パフォーマンスの特性は、Desktop Reload 変数です。
ログインタイプとデスクトップタイプの両方の場合に、次の適切なコンテンツ設定を選択します。
Light-JSP。それぞれ 5 個のチャネルを持つ、2 つのタブの設定を記述します。
Regular-JSP。それぞれ 7 個のチャネルを持つ、2 つのタブの設定を記述します。
Heavy-JSP。それぞれ 17 個のチャネルを持つ、3 つのタブの設定を記述します。
ここまでで、上述の数値を技術担当者に伝え、サイジングツールを実行して CPU の見積もり数を算出するように依頼できます。
ポータルデスクトップの設定によって、セッション単位でメモリーに保持するデータ量が明確に決定されます。
ポータルデスクトップのチャネルが多くなるほど、データのセッションサイズは大きくなり、Portal Server のスループットが低下します。
もう 1 つの要素は、ポータルデスクトップで提供される対話機能の性能です。たとえば、チャネルをクリックすると、Portal Server または他の外部サーバーに負荷が発生します。チャネルの選択によって Portal Server に負荷が発生すると、ポータルデスクトップをホストするノードのユーザークティビティープロファイルと CPU オーバーヘッドは、他の外部サーバーをホストするノードの場合より高くなります。
CPU 速度と、Java プラットフォーム (Java 仮想マシンまたは JVMTM ソフトウェア) のメモリーヒープにおける仮想マシンのサイズは、Portal Server のパフォーマンスに影響を与えます。
CPU 速度が速くなれば、スループットも高くなります。ヒープ生成チューニングパラメータとともに、JVM メモリーヒープのサイズも Portal Server のパフォーマンスを左右します。
Portal Server は外部ソースからコンテンツを集約します。外部のコンテンツプロバイダが、最大速度で動作する Portal Server に必要な帯域を確保できない場合、ポータルデスクトップのレンダリングとスループットの要求時間は最適化されません。ポータルデスクトップは、ブラウザに要求応答を返す前に、すべてのチャネル動作が完了するかタイムアウトになるまで待機します。
次のチャネルを使用する場合は、バックエンドのインフラストラクチャーを慎重に計画してください。
外部ソースからコンテンツを収集する
一般に応答時間の遅い企業データベースにアクセスする
電子メールコンテンツを提供する
カレンダコンテンツを提供する
トランザクション時間は、HTTP または HTTPS 処理が完了するまでの遅延時間で、送信時間、処理時間、および応答時間を合計した時間です。
トランザクション時間に影響する要素について計画する必要があります。これには、次の要素があります。
ネットワーク速度と待ち時間。ワイドエリアネットワーク (WAN) の場合は、待ち時間について検討する必要があります。大量のデータの場合には、待ち時間により取得時間が著しく長くなる可能性があります。
ポータルデスクトップの複雑さ。
ブラウザの接続速度。
たとえば、接続速度が 33.6 kbps の場合は、LAN 接続の場合よりも応答時間の遅延が長くなります。ただし、処理時間は一定です。ダイヤルアップ接続によるトランザクション時間は、データ圧縮を実行するロード生成ツールによって表示されるトランザクション時間よりも短くなります。
トランザクション時間を計算する場合は、Portal Server のサイジングを行なって、通常またはピーク時の負荷状態がパフォーマンス要件のしきい値を超えないように、また時間が経過しても処理時間を維持できるようにします。
ワークロード条件は、システムにおいてもっとも集中的に使用される、システムリソースと JVM ソフトウェアリソースです。これらの条件は、大部分がユーザーの動作と配備するポータルのタイプによって決まります。
Portal Server ソフトウェアで一般的に発生するワークロード条件は、次の要素に影響を与えます。
Portal Server のパフォーマンスは、アクティビティープロファイルが高い場合など、大量の並行要求が処理される場合に影響を受けます。たとえば、企業対企業ポータルの負荷ピーク時には、同時に大勢の社員がポータルに接続します。そうした状況では、CPU にワークロードが集中します。また、接続されたユーザーに対する並行処理ユーザーの割合も高くなります。
Portal Server の処理能力は、大勢のユーザーがログインすると影響を受け始めます。ログインするユーザーが多くなると、ユーザーがより多くのメモリー領域を使用するので、サーバーで要求を処理するために使用可能なメモリーが少なくなります。たとえば、企業対顧客 Web ポータルでは、ポータルデスクトップの初期表示がロードされるとすぐ、大勢のログインユーザーが外部の Web サイトにリダイレクトされます。しかし、さらに多くのユーザーがログインすると、Portal Server に要求を送信しているユーザーと単にログインしているだけのユーザーの割合が低くても、より多くのメモリー領域が必要になります。
日、週、または月の特定の時間帯におけるユーザーの動作に応じて、Portal Server は、CPU 集中のワークロードとメモリー集中のワークロードを切り替えることができます。ポータルのサイト管理者は、最重要なワークロード条件を定めて、企業のビジネス目標に合ったサイトのサイジングとチューニングを実行する必要があります。