2008_11_11－性能見積りと事前対応。

２００８年１１月１１日発行

分割ラインです

　《　予算・実績管理編　》

　　
　性能見積りと事前対応。
　　
　　
　　性能見積りを詳細に見積ることは、困難な作業です。
　　
　　ＣＰＵ性能だけでなく、ネットワークや、ＤＢ性能などに
　　大きく左右されるからです。
　　
　　中でも、大きく影響するのがＣＰＵ処理性能とＤＢ性能です。
　　算出式は存在するもの、
　　　　条件によって大きく異なるからです。
　　　ＣＰＵの場合は、マルチタスクや常駐タスクの同時処理状況
　　　ＤＢの場合は構造によって大きく変ります。　
　　
　　ハードウェア構成も多様になっており、
　　　　性能見積りを行うことは、ますます困難になってきております。
　　市販ソフトウェアでさえ、開発会社自身のソフトしかサポートしません。
　　　　マルチ構成であれば、性能見積りなんて使用者自身の責任となります。
　　
　　
　　じゃ、どうすればいいのでしょう。
　　
　　　　各業務ごとに、オンラインデマンド処理などの場合は、
　　　　　　要求依頼から、回答表示までの平均時間、最大時間の
　　　　　　　　努力目標と最低必達目標値を決めるのです。
　　　　　　バッチ処理などは、目標スループットや最低必達終了時間の
　　　　　　　　目標処理時間を決めることです。
　　
　　
　　特に、照会よりも更新業務処理の処理時間を中心にして見積ることです。
　　ただし正確ではないので、ＤＢのアクセス時間や件数当たりの処理時間など
　　　　　を見積り実測値と少ない件数（1件）で時間を計ることです。
　　
　　
　　
　　１．少ない件数で目標に差が大きければ、原因を探ります。
　　　　設計段階におけるデモテストなど早い工程段階から性能確認を行えば、
　　　　対応方法もいろいろ考えられます。
　　
　　２．仕様変更に気をつけましょう。知らない間に性能が大きく落ちています。
　　　　思わぬ原因で性能が落ちるのです。
　　
　　３．故障対応や横展開方法にも気をつけましょう。横展開も一律同じでは
　　　　性能に影響がでることもあります。
　　
　　４．少ない件数で問題が無くても、ラッシュテストでは問題が続出します。
　　　　ネットワークの混み具合（ネットワーク構成見直し）
　　　　ハードウェアの競合アクセス
　　　　メモリーの使用状況（枯渇していないか）
　　
　　５．実際の業務内容にも着目しましょう。
　　　　限られた業務やＤＢアクセスパターンなど頻度が必ず偏っています。
　　
　　６．他のプロジェクトにも注意しましょう。以外にも接点が大きかったり
　　　　します。
　　
　　７．バッチ処理は、クリティカルパスに気をつけましょう。
　　　　夜間バッチが遅れると、翌朝のオンライン起動が遅れることもあります。
　　
　　８．他の優先順位の高い処理と同じ時間に実行する可能性に注意しましょう。
　　
　　９．保守などのイベント時間にも注意しましょう。
　　
　　１０．セキュリティ対策による負荷増も考慮しましょう。
　　
　　
　　
　　
　　まだまだ、性能劣化リスクは多々あります。
　　　　しかし、事前に考えているのと、いないのでは、大きく違ってきます。
　　　　　　後工程になるほど、対応する選択肢は少なくなってきます。