2.1. 導入：Quantitative System Performance
「1.7. 参考文献」の続きです。
2.1. 導入
この章で、我々が特定のコンピュータ・システム解析問題に直面しているとき、どのように待ち行列ネットワーク・モデル化の一般的「方法論」を適用するかについて広く見てみる。このスキルは経験を通して発達されなければならない。それを受動的に吸収することは出来ない。これを認識して、我々は方法論の顕著な側面を示すために選ばれた一群のケーススタディを提示し、読者に他の人々の経験を分け与える。
待ち行列ネットワーク・モデル化の成功は、システムの低レベルの詳細はその高レベル性能特性に概して無関係であるという事実に基づいている。待ち行列ネットワーク・モデルは、コンピュータ・システム解析のための他の方法と比較すると抽象的に見える。待ち行列ネットワーク・モデル化は本質的にトップダウン過程である。その背後にある哲学はシステムの主なコンポーネントの特定とそれらの相互作用の仕方から始めて、必要であると分かった任意の詳細内容を支給するというものである。この哲学は、モデル化スタディを実行する過程で多くの仮定が導入され評価されることになるということを意味する。３つの主要な考慮すべき事柄がこれらの仮定の動機となっている。
- 単純さ
- 無関係な詳細を特定し除去する強い動機が存在する。事実、スタディの結果に主要な（副次の対語として）効果を持たない任意のシステム特徴を一般に含むことによって、この文脈で我々は「無関係な」のむしろ寛大な定義を採用することになる。例として次のようなものがある。
- 測定の適切さ
- 現代のコンピュータ・システム上で利用可能な測定ツールはしばしば待ち行列ネットワーク・モデルのパラメータ値を決定するのに要求される数量を直接提供出来ていない。待ち行列ネットワーク・モデルは注意深く選ばれた少数の入力を要求する。測定ツールは概して歴史的な理由から大量のデータを提供するが、その大部分は我々の目的においては限定的にしか使用しない。解析者の側にはかなりの解釈が必要になる。その例としては、
- 通常、ＣＰＵ活動のかなりの割合が特定の作業負荷コンポーネントのせいではない。ＣＰＵは頻繁に使用されるリソースである傾向があるので、その利用の正しい帰属は複数クラス・モデルの精度にとって重要である。
- 驚くことに、バッチ作業負荷のマルチプログラミング・レベルを決定することでさえ、しばしば難しい。というのは若干のシステム・タスク（「休止状態の」あるいは「オペレータの」ジョブ）が測定ツールによってカウントされているかもしれないからである。
- 評価のし易さ
- 第１章で述べたように、一般的な待ち行列のネットワークの、効率的に評価出来る部分集合に限定しなければならない。この部分集合内に留まるために、我々はコンピュータ・システムの若干の特性の表現において我々は妥協しなければならない。例として次のようなものがある。
- 特定のリソースでのサービス要求時間の極端に高いばらつきは性能の悪化を引き起こす可能性がある。しかし、この特性の直接的な表現は待ち行列ネットワーク・モデルの評価の費用を吊り上げ、それが性能の主要決定要因である例はまれである。それはモデルから通常省略される。
- メモリ・アドミッション・ポリシーは通常複雑であり、プログラムのメモリ要求はさまざまである。しかし、もしメモリ・アドミッション・ポリシーが先着先サービスあるいはクラスに基づく優先度のいずれかであることを、そしてプログラムが、少なくとも同じクラス内部で、似たようなメモリ要求を持つことを我々が進んで仮定するならば、モデルの評価はかなり簡単になる。
諸仮定を導入し評価する際のスキルはモデル化スタディを成功させるためのキーである。一般に、なされた仮定やその導入の動機やそのもっともらしさを支持する議論を明白に気遣うことは重要である。これは解析者の論拠を検査し、結果の仮定に対する敏感さ（センシティビティ）の評価を促進する。
この章の資料はかなり底の浅いものからかなり巧妙なものまでの範囲の解釈のスペクトラムを持つ。ほとんど経験を持たない読者は待ち行列ネットワーク・モデルの適用可能性を示すケーススタディの短い説明の集合を見い出すだろう。中程度の経験を持つ読者は、待ち行列ネットワーク・モデル化スタディを進める方法について何かを学ぶだろう。かなりの経験を持つ読者は非常に都合よく用いることの出来る、モデル化スタディの実施のさまざまな側面に関する洞察を発見するだろう。この解釈のスペクトラムのために、我々は読者にこの本のパートＶの間この章を復習することをお願いすることになる。
「2.2. モデル化サイクル（１）」に続きます。
