12.2.情報のタイプと源泉（２）：Quantitative System Performance
「12.2.情報のタイプと源泉（１）」の続きです。（ 目次はこちら）
- 表１２．１ 情報の源泉
表１２．１はさまざまな源泉から普通利用可能な情報をまとめている。異なる源泉（アカウンティングとソフトウェアのモニタ、あるいは２つの異なるソフトウェア・モニタであっても）からの情報は異なる内在する仮定に基づいているだろう。このため、そして終端効果例外のために、異なる源泉からの情報は矛盾するように見えるかもしれない。例えば、モニタが３０分観測期間でモニタするような小さな会話型システムを考察しよう。
するとその観測期間でのスループットは
であったと我々は結論するだろう。観測期間が平均応答時間に比べて長いので、終端効果がスループットや応答時間の見積もりにそれほど誤差を与えないことに我々は確信が持てることだろう。しかし、リトルの法則を考慮すると、スループット（４トランザクション／秒）と応答時間（３秒）の積から期待されるより待ち行列長の合計（１８）がずっと大きいことに気づくであろう。このような状況についての１つの可能な説明は、待ち行列長は、スループットと応答時間の計算のいずれかにカウントされていないようなシステム・タスクを含んでいるというものである。反対に仮に、待ち行列長の合計が８であると（そして他の値は同じままであると）報告されたのであれば、リトルの法則は他の方向で矛盾をあばくであろう。２番目の場合についての可能な説明は、要求はメモリへの入場を求めてキューイングされており、よってそれらの応答時間のかなりの部分がいかなるデバイスの待ち行列長に含まれないような場所で費やされているというものである。第３章で提示した基礎法則はそのような明らかな矛盾を検出するのに用いることが出来る。それらを解決するためにはシステムの直感と注意深い考察が要求される。
構成の管理とキャパシティ計画の問題の認識の向上は、システム測定データの使用と管理において若干の心強い進歩を最近もたらしてきた。まず、若干のシステムのために、待ち行列ネットワーク・モデル化の要求にあててあつらえた特殊な報告ルーチンが開発された。これらのルーチンは既存のアカウンティングとソフトウェアのモニタが生成した記録を解析する。いくつかは、特定の待ち行列ネットワーク・モデル化ソフトウェア・パッケージに直接受け入れ可能なフォーマットで待ち行列ネットワークを定義することが出来る。これらのルーチンは大きな助けになるが、有効性を確認されたモデルを得るためには大部分の場合やはり解析者の介入が必要である。これは測定データの不適切さと、解析者のシステムについての知識が自動化されたルーチンでは使用不可能であることから真実である。（このようなルーチンについてのさらなる議論は第１６章に現れる。）
２番目に、若干のより新しいレポーティング・ルーチンは性能データベースを使用しそれに貢献する能力を持つように一般化されてきた。さまざまなモニタが書いた記録は初歩の性能データベースを構成する。単にタイプや源泉によって記録を整理することはそれらの利用をより容易にする。しかしもしデータベースが、レポーティング・ルーチンによって生成された総体の情報を含むように拡張されるならば、データベースの有用性はさらに高められる。そのような性能データベースを維持することにはいくつかのメリットがある。ひとつには、もしデータベースに月毎にまとめられた情報が含まれているならば、長期傾向を調査することが出来る。また、管理計画ように意図された情報を、システム・チューニングのためのより技術指向の情報から分離することが出来る。最後に、１つのデータベースに利用可能なモニタリング情報のさまざまなまとめを持つことにより、通常のプリントアウトされたレポートの必要性はかなり減少する。
「12.3.客の記述（１）」に続きます。
