(これは我々の経験上の予測です)この結論は、予測を策定するための基本となります。シートにまとめてみます。これらの初期データに対して必要な計算をあてはめます。データベースのサイズおよび、モニタリングに必要となる一秒間あたりのモジュール実行数、その他パラメータを予測できます。(秒あたりのモジュール実行数)、アラートの数、日ごとのモジュール実行数、月ごとの容量がわかったら、本番に近いシステムで実際にサーバの負荷テストを行います。(ここでのテストは、本番に近いシステムでは実行できていません。処理能力がわかり、どの程度で性能劣化するかがわかります。これは、次のような目的において便利です。対象のハードウエアで最大どれくらいの規模まで対応できるかを推定する場合。情報を移すポイントを知りたい場合。サービス停止や計画停止により、処理する情報がたまった場合の最大処理量に対する余裕を知りたい場合。モニタ対象の情報の変化率が変わった場合のパフォーマンスに与える影響を知りたい場合。大量のアラート処理の影響を知りたい場合。環境のテストに使っています。プロジェクトに似たエージェント設定で実施しました。似たパフォーマンスの影響および大量のデータを扱うことによるその他問題(主に利便性)を評価できる環境です。得られた結果はとても良く、システムは非常に過負荷にもかかわらず、非常に興味深い情報量を処理することができました(180,000モジュール、6000エージェント、120,000アラート)。これから得られた結論は次の通りです。15日間でヒストリーデータベースへ移動させるべきである。一週間より古いデータを動かすことがベストです。これにより、より早い動作が保障されます。システムを構築する場合のパフォーマンスと必要な容量を決定するには、データの細分化の割合がとても重要である。pandorafms.org。