ポータルのプロトタイプの開発
ポータルのプロトタイプを開発する
-
プロセッサ、メモリー、ネットワーク、およびディスクの明らかな障害を識別して取り除きます。
-
制御された環境をセットアップして、同一条件での動作変動が 10 パーセント未満に定義されるエラーの許容範囲を最小限に抑えます。
開始データの測定基準が分かれば、サンプル収集動作間のデータパフォーマンスの変動を測定できます。測定値は適切な長さの時間で収集し、これらのテストの結果を捕捉して評価できるようにします。
Portal Server マシンとは別に、負荷シミュレーションデータを収集する専用マシンの使用を計画します。専用マシンは、パフォーマンス問題の原因を突き止めるのに役立ちます。
-
この最初のベンチマークを使用して、短期および長期的に組織がサポートするトランザクションの量を定義します。
現在の物理的なインフラストラクチャーが、定義したトランザクションの量の要件をサポート可能であるかどうかを確認します。
ポータルに対するアクティビティーが増えるにつれ、最初に限度に達するサービスを特定します。これにより、上限までの余裕が示され、また強化すべきところが特定されます。
-
ポータルの提供者、管理者、および開発者が同意する予想生産環境をできるだけ正確にシミュレーションする、プロトタイプワークロードを作成して微調整します。
-
プロトタイプを検証するためにトラフィックを定期的に測定および監視します。
CPU の使用率を一定の期間追跡します。通常、負荷は急に上昇し、上昇が発生する前に対策を講じるためには利用可能な機能の慎重な評価が必要です。
ほとんどの組織はポータルサイトが「スティッキー」な性質を持つことを認識しています。つまり、ユーザーのコミュニティーのサイズが固定されていても、ユーザーがそのサイトに慣れてくると、サイトの使用率が時間の経過とともに増加することを意味します。また、ユーザーのコミュニティーのサイズが時間の経過とともに増加する場合も、成功しているポータルサイトでは短期間に CPU 要件が高まる場合があります。
ポータルサーバーの CPU の使用率を監視する場合、負荷のピーク時における平均 Web ページ待ち時間を確認し、それが平均の待ち時間とどれだけ異なるかを確認します。
ピーク時の負荷は、短期間ではありますが、平均の負荷の 4 〜 8 倍の負荷であると予測します。
-
モデルを使用して、長期のシナリオを計画します。プロトタイプを使用すると、今後数年の総合的な成長予測に対応するために、配備をどれだけ大幅に変更する必要があるかを理解できます。
-
エラーロギングレベルを MESSAGE ではなく ERROR に保ちます。MESSAGE エラーレベルは冗長であり、ファイルシステムのディスク領域がすぐに不足する原因になります。ERROR レベルは、すべてのエラー状態と例外をログに記録します。
-
ポートレットのようなカスタマイズされたポータルアプリケーションを監視します。
-
次の領域を監視します。
-
ポータルデスクトップ
-
チャネルレンダリング時間
-
Sun JavaTM System Access Manager
-
Sun Java System Directory Server
-
Sun Java System 仮想マシン
-
Web コンテナ
次に、ポータルのパフォーマンスにおける可変要素の観点から問題について説明し、ポータルの効率を判断する際の指針を示します。
-
Access Manager のキャッシュとセッション
ポータルシステムのパフォーマンスは、Access Manager キャッシュのキャッシュヒット率の影響をかなり受けます。このキャッシュは高度にチューニング可能ですが、このキャッシュが使用するメモリーとヒープの残りの利用できるメモリーのどちらかを選択する必要があります。
amSDKStats ログを有効にして、サーバー上のアクティブなセッションの数と Directory Server キャッシュの効率を監視できます。それらのログは、デフォルトで /var/opt/SUNWam/stats ディレクトリにあります。ロギング間隔を設定するには、com.iplanet.am.stats.interval パラメータを使用します。5 秒未満の値を使用しないでください。30 〜 60 秒の値を使用すると、パフォーマンスに影響を与えずに良い結果が得られます。
com.iplanet.services.stats.directory パラメータを使用して、ファイルまたは Portal Server 管理コンソールのどちらかのログの場所を指定したり、ログを無効にしたりします。変更を有効にするには、サーバーを再起動する必要があります。ログは、システムがアクティビティーを検出するまで、作成されません。
注 –
複数の Web コンテナインスタンスが、同じファイルにログを書き込みます。
amSDKStats ファイルに表示されるキャッシュヒット率は、サーバーが起動されてからの内部の値と全体的な値の両方を示します。ユーザーがログインすると、ユーザーのセッション情報は、無期限あるいはキャッシュが一杯になるまでキャッシュに残ります。キャッシュが一杯になると、もっとも古いエントリが先に削除されます。サーバーがユーザーのエントリを削除する必要がない場合は、数日後にログインするときに、ユーザーの情報がキャッシュから取得されることがあります。ヒット率が高いと、パフォーマンスがかなり向上します。最低 80 パーセントのヒット率は良い目標ですが、可能であればそれよりも高いヒット率を目標にすることが望まれます。
スレッドの使用
Web コンテナツールを使用して、要求を処理するために使用するスレッドの数を監視します。一般に、実際に使用されるスレッドの数は多くの場合予測した数よりも少なく、特に CPU の使用率が通常 100 パーセントよりもかなり低い本稼働サイトではそのようになります。
ポータルの使用情報
Portal Server には、ポータルのユーザーがポータルの使用情報を監視するための組み込みの報告メカニズムがあります。これには、アクセスされるチャネル、チャネルがアクセスされた期間、またポータルのユーザーの行動様式を作成する能力が含まれます。ポータルの監視は、psconsole または cli psadmin を使用して管理できます。次の監視機能を使用できます。
-
管理対象のデスクトップサービス:
-
コンテンツ要求
-
編集要求
-
プロセス要求
-
ログアウト要求
-
-
サービスの公開
-
累積的
-
チャネルごと
-
-
各サービスには、一連の属性がある
-
サービス属性:
-
名前数
-
最終サービス時間
-
最大サービス時間
-
最小サービス時間
-
平均サービス時間
-
ユーザーベースの追跡 (UBT) も、psconsole または cli psadmin を使用して管理されます。UBT はデフォルトでは無効になっています。ユーザーベースの追跡を有効にするには、ファイル /var/opt/SUNWportal/portals/portal1/config にあるプロパティー com.sun.portal.ubt.enable=true を設定する必要があります。取得されたデータのエクステントは、レベル INFO、FINE、FINER、 FINEST、OFF が制御します。ログは、/var/opt/SUNWportal/portals/portal1/logs/%instance/ubt.%u.%g.log ファイルにルーティングされます。このファイルは設定可能です。
- © 2010, Oracle Corporation and/or its affiliates