test

Sun Java System Portal Server 7.1 配備計画ガイド

Portal Server の使用分析

論理設計、アーキテクチャー設計および配備設計で使用できる基本サイズを確立する必要があります。 技術担当者は、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 の使い方によって変化します。たとえば、対話型のアプリケーションが関係するユーザーセッションの場合は、情報のみのユーザーセッションの場合よりも、セッション時間が長くなるのが一般的です。

検索サービスの要素

ポータルサイトで検索チャネルを提供する場合は、検索エンジンのサイジング要素をサイジングの計算に含める必要があります。検索エンジンのサイジング要件は、次の要素によって決まります。

ページ設定

認証されたポータルを使用する場合は、自動サイジングツールのページ設定セクションにある「Login Type」と「Desktop Type」の両方を指定する必要があります。

ログインタイプとデスクトップタイプの両方の場合に、次の適切なコンテンツ設定を選択します。

ヒント –

ここまでで、上述の数値を技術担当者に伝え、サイジングツールを実行して 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 処理が完了するまでの遅延時間で、送信時間、処理時間、および応答時間を合計した時間です。

トランザクション時間に影響する要素について計画する必要があります。これには、次の要素があります。

トランザクション時間を計算する場合は、Portal Server のサイジングを行なって、通常またはピーク時の負荷状態がパフォーマンス要件のしきい値を超えないように、また時間が経過しても処理時間を維持できるようにします。

ワークロード条件

ワークロード条件は、システムにおいてもっとも集中的に使用される、システムリソースと JVM ソフトウェアリソースです。これらの条件は、大部分がユーザーの動作と配備するポータルのタイプによって決まります。

Portal Server ソフトウェアで一般的に発生するワークロード条件は、次の要素に影響を与えます。