運用ノウハウを学ぶ

具体的な改善項目は、大小合わせて20を超えています。
　前回２．３で紹介したプログラム（xxx0001）のロジック改善では、データベースの不要な排他待ちが削減され、デッドロックも起きにくくなり、システム全体の性能が大幅に改善される結果となりました。

【第４フェーズ】

　重要なプログラムについては性能モデルを作成します。例えば、上記プログラムの性能改善の前後だと図６のようになります。データベースのメモリ常駐化も行っているためCPU/IO頻度は20→42に上昇しています。

図６　性能モデル

本題である「売上が1.5倍になったときシステムが業務に影響を与えない」ことを検証すためには様々な考慮が必要です。

① 売上の伸びとシステムの資源使用量の関係
 CPUは第１回の図１に示したとおり十分に余裕があるので、売上との厳密な関係を導く必要はありませんでした。I/Oやメモリについても検証をします。

② システムで最初にボトルネックとなる資源は何か
 CPUだけとは限りません。本件では、ほとんどのプログラムが参照しているデータベースがあり、できるだけ排他待ちが起きないようにする必要がありました。お客様にはデータベースの構造や排他制御の仕組みを十分に理解して頂き、自ら考え、チューニングを実施して頂きました。

③ 多重処理が可能か
 入力端末やバッチジョブの実行多重度を増やすために、タスク数や優先度の調整を行います。

④ どこまで遅くなってよいのか
 ハードの性能を上げない限り処理時間は遅延します（図６の待ち時間が延びる）。現実的なサービスレベルを合意することが重要です。

更に、想定されるリスクについてもお客様と意識を合わせることが重要です。例えば、処理時間が予想以上に遅延してしまったときの対処方法など具体的に提示します。

３．２　改善結果

　表２に示した状況から２週間後の改善結果を表３に示します。遅かった処理が短期間で改善している様子がわかると思います。