バージョン 8.1.3
 —  DBA タスク  —

システム設計におけるパフォーマンス制御

システムのパフォーマンスの判断基準は、実行に必要な時間とコンピュータリソースです。 これらは次のような理由から重要です。

しかし、パフォーマンスが最も重要な目標であるとは限りません。 パフォーマンスと次の項目のどちらを優先するかについてよく考える必要があります。

パフォーマンスが、最適化すべき目標ではなく制約になる場合もあります。 システムは時間やボリュームの問題が生じたとき、パフォーマンスよりは他の項目に注意を向けるべき場合もあり得ます。

このドキュメントでは、次のトピックについて説明します。


システム設計におけるパフォーマンス制御方法

満足のいくパフォーマンスを達成するためには次の事柄に影響を与えます。

どの程度のパフォーマンスが必要かはシステム設計段階の早い時期に考慮しなければなりません。 パフォーマンスを制御するうえでの基本要件として、次の事項を確認します。

  1. 主なシステム機能について、ユーザーに時間の制約を聞きます。 これら要求事項は絶対的と思われます。すなわちこの制限が満たされないとシステムは使いものになりません。

  2. ユーザーおよびオペレーション担当者からコンピュータリソースに関する制約を聞き、最も厳しいものを使用します。

  3. 次の内容を指定して、論理的な設計モデルにおける各機能を説明します。

  4. 最もパフォーマンスがクリティカルであるプログラムを判断します。 他のシステムのスケジューリングやパフォーマンスに関する影響、量、頻度、期限等を考慮し、選択します。 他のプログラムにも、クリティカルな機能を最適化できるようその範囲を制約する可能がある最小のパフォーマンス要件があることも考えられます。

  5. クリティカルな各機能について、アクセスパスを短くし、そのロジックを改良し、オーバーヘッドを増加するようなデータベース機能を削除して、パフォーマンスを最適化します。 第 1 のパスでは、柔軟性、情報の取り出し易さ、あるいはシステムの他機能要求を犠牲にすることなく、パフォーマンスを最適化する努力をしなければなりません。

  6. クリティカルな各機能のパフォーマンスを推定します。 この推定値では満足できる結果にはならない場合、時間の制約か機能要求を少しゆるめるよう調整するか、ハードウェアを向上させる必要があります。

  7. その他のシステム機能のパフォーマンスを推定します。 総費用を計算し、金銭上の制約と、費用やリソース要求のピーク期間とを比較します。 この推定値が制約を満たさないと、ユーザー、オペレーション部門あるいはシニアマネージメントと調整を行い、解決しなければなりません。

  8. できれば、テストデータベースをロードし、各機能の時間を計測して、推定値を検証します。 テストデータベースのファイル内のレコード数やディスクリプタの値の数は、本番データベースと類似しているべきです。 各レコードサイズは順次処理のテスト以外ではあまり重要ではありません。レコードを物理順に近い形で処理するときのみ重要です。

Top of page