ポータルのプロトタイプを開発する

1. プロセッサ、メモリー、ネットワーク、およびディスクの明らかな障害を識別して取り除きます。

2. 制御された環境をセットアップして、同一条件での動作変動が 10 パーセント未満に定義されるエラーの許容範囲を最小限に抑えます。

   開始データの測定基準が分かれば、サンプル収集動作間のデータパフォーマンスの変動を測定できます。測定値は適切な長さの時間で収集し、これらのテストの結果を捕捉して評価できるようにします。

   Portal Server マシンとは別に、負荷シミュレーションデータを収集する専用マシンの使用を計画します。専用マシンは、パフォーマンス問題の原因を突き止めるのに役立ちます。

3. 配備のパフォーマンスの基準を定義してから、プロジェクトの複雑な部分を追加していきます。

4. この最初のベンチマークを使用して、短期および長期的に組織がサポートするトランザクションの量を定義します。

   現在の物理的なインフラストラクチャーが、定義したトランザクションの量の要件をサポート可能であるかどうかを確認します。

   ポータルに対するアクティビティーが増えるにつれ、最初に限度に達するサービスを特定します。これにより、上限までの余裕が示され、また強化すべきところが特定されます。

5. ポータルの提供者、管理者、および開発者が同意する予想生産環境をできるだけ正確にシミュレーションする、プロトタイプワークロードを作成して微調整します。

6. プロトタイプを検証するためにトラフィックを定期的に測定および監視します。

   CPU の使用率を一定の期間追跡します。通常、負荷は急に上昇し、上昇が発生する前に対策を講じるためには利用可能な機能の慎重な評価が必要です。

   ほとんどの組織はポータルサイトが「スティッキー」な性質を持つことを認識しています。つまり、ユーザーのコミュニティーのサイズが固定されていても、ユーザーがそのサイトに慣れてくると、サイトの使用率が時間の経過とともに増加することを意味します。また、ユーザーのコミュニティーのサイズが時間の経過とともに増加する場合も、成功しているポータルサイトでは短期間に CPU 要件が高まる場合があります。

   ポータルサーバーの CPU の使用率を監視する場合、負荷のピーク時における平均 Web ページ待ち時間を確認し、それが平均の待ち時間とどれだけ異なるかを確認します。

   ピーク時の負荷は、短期間ではありますが、平均の負荷の 4 〜 8 倍の負荷であると予測します。

7. モデルを使用して、長期のシナリオを計画します。プロトタイプを使用すると、今後数年の総合的な成長予測に対応するために、配備をどれだけ大幅に変更する必要があるかを理解できます。

8. エラーロギングレベルを MESSAGE ではなく ERROR に保ちます。MESSAGE エラーレベルは冗長であり、ファイルシステムのディスク領域がすぐに不足する原因になります。ERROR レベルは、すべてのエラー状態と例外をログに記録します。

9. ポートレットのようなカスタマイズされたポータルアプリケーションを監視します。

10. 次の領域を監視します。

    • ポータルデスクトップ

    • チャネルレンダリング時間

    • Sun Java^TM System Access Manager

    • Sun Java System Directory Server

    • Sun Java System 仮想マシン

    • Web コンテナ

    次に、ポータルのパフォーマンスにおける可変要素の観点から問題について説明し、ポータルの効率を判断する際の指針を示します。