Quantitative System Performance

2. モデル化スタディの実行

2.1. 導入
この章で、我々が特定のコンピュータ・システム解析問題に直面しているとき、どのよ
うに待ち行列ネットワーク・モデル化の一般的「方法論」を適用するかについて広く見て
みる。このスキルは経験を通して発達されなければならない。それを受動的に吸収するこ
とは出来ない。これを認識して、我々は方法論の顕著な側面を示すために選ばれた一群の
ケーススタディを提示し、読者に他の人々の経験を分け与える。
待ち行列ネットワーク・モデル化の成功は、システムの低レベルの詳細はその高レベル
性能特性に概して無関係であるという事実に基づいている。待ち行列ネットワーク・モデ
ルは、コンピュータ・システム解析のための他の方法と比較すると抽象的に見える。待ち
行列ネットワーク・モデル化は本質的にトップダウン過程である。その背後にある哲学は
システムの主なコンポーネントの特定とそれらの相互作用の仕方から始めて、必要である
と分かった任意の詳細内容を支給するというものである。この哲学は、モデル化スタディ
を実行する過程で多くの仮定が導入され評価されることになるということを意味する。３
つの主要な考慮すべき事柄がこれらの仮定の動機となっている。

単純さ
無関係な詳細を特定し除去する強い動機が存在する。事実、スタディの結果に主
要な（副次の対語として）効果を持たない任意のシステム特徴を一般に含むこと
によって、この文脈で我々は「無関係な」のむしろ寛大な定義を採用することに
なる。例として次のようなものがある。
システムは多数の特定可能な作業負荷コンポーネントを持つが、我々はそれ
らのひとつについてだけの性能に興味がある。この場合、我々は２つのクラ
ス（１つは興味のある作業負荷コンポーネントを表し、もう一つは他の全て
の作業負荷コンポーネントの総合効果を表す）だけを持つモデルの採用を選
択するだろう。
ＣＰＵアップグレードの主要効果はＣＰＵサービス要求時間を減少させるだ
ろう。ジョブあたりの平均ページングとスワッピング活動の変化もまた起き
るかもしれないが、もしそうならこれは副次効果である。
測定の適切さ
現代のコンピュータ・システム上で利用可能な測定ツールはしばしば待ち行列ネ
ットワーク・モデルをパラメータ化するのに要求される数量を直接提供出来てい
ない。待ち行列ネットワーク・モデルは注意深く選ばれた少数の入力を要求する。

1
 測定ツールは概して歴史的な理由から大量のデータを提供するが、その大部分は
我々の目的においては限定的にしか使用しない。解析者の側にはかなりの解釈が
必要になる。その例としては、
通常、ＣＰＵ活動のかなりの割合が特定の作業負荷コンポーネントのせいで
はない。ＣＰＵは頻繁に使用されるリソースである傾向があるので、その利
用の正しい帰属は複数クラス・モデルの精度にとって重要である。
驚くことに、バッチ作業負荷のマルチプログラミング・レベルを決定するこ
とでさえ、しばしば難しい。というのは若干のシステム・タスク（
「休止状態
の」あるいは「オペレータの」ジョブ）が測定ツールによってカウントされ
ているかもしれないからである。
評価のし易さ
第１章で述べたように、一般的な待ち行列のネットワークの、効率的に評価出来
る部分集合に限定しなければならない。この部分集合内に留まるために、我々は
コンピュータ・システムの若干の特性の表現において我々は妥協しなければなら
ない。例として次のようなものがある。
特定のリソースでのサービス要求時間の極端に高いばらつきは性能の悪化を
引き起こす可能性がある。しかし、この特性の直接的な表現は待ち行列ネッ
トワーク・モデルの評価の費用を吊り上げ、それが性能の主要決定要因であ
る例はまれである。それはモデルから通常省略される。
メモリ・アドミッション・ポリシーは通常複雑であり、プログラムのメモリ
要求はさまざまである。しかし、もしメモリ・アドミッション・ポリシーが
先着先サービスあるいはクラスに基づく優先度のいずれかであることを、そ
してプログラムが、少なくとも同じクラス内部で、似たようなメモリ要求を
持つことを我々が進んで仮定するならば、モデルの評価はかなり簡単になる。

諸仮定を導入し評価する際のスキルはモデル化スタディを成功させるためのキーである。
一般に、なされた仮定やその導入の動機やそのもっともらしさを支持する議論を明白に気
遣うことは重要である。これは解析者の論拠を検査し、結果の仮定に対する敏感さ（セン
シティビティ）の評価を促進する。
この章の資料はかなり底の浅いものからかなり巧妙なものまでの範囲の解釈のスペクト
ラムを持つ。ほとんど経験を持たない読者は待ち行列ネットワーク・モデルの適用可能性
を示すケーススタディの短い説明の集合を見い出すだろう。中程度の経験を持つ読者は、
待ち行列ネットワーク・モデル化スタディを進める方法について何かを学ぶだろう。かな
りの経験を持つ読者は非常に都合よく用いることの出来る、モデル化スタディの実施のさ
まざまな側面に関する洞察を発見するだろう。この解釈のスペクトラムのために、我々は

2
読者にこの本のパートＶの間この章を復習することをお願いすることになる。

2.2. モデル化サイクル
待ち行列ネットワーク・モデル化の最も普通な応用は、既存システムの構成あるいは作
業負荷の変更の性能への影響を予測することを含む。そのようなスタディには３つのフェ
ーズがある。妥当性確認フェーズでは、既存システムの「ベースライン・モデル」が構築
され、その充分性が確立される。予測フェーズでは、予想される修正の性能への影響を予
測するためにこのモデルが使われる。検証フェーズでは、修正されたシステムの実際の性
能がモデルの予測と比較される。これらを一緒にして、これらの３フェーズは図２．１に
示すようにモデル化サイクルと呼ばれる。

既存システム

測定 測定
妥当性確認

既存システム
既存システム
作業負荷尺度
能力尺度
パラメータ化 モデル 比較
定義
元々の 元々の
モデル入力 モデル出力

評価
モデル
予測

改造解析 比較
評価

修正した 修正した
モデル入力 モデル出力

比較 比較
検証

修正したシステムの 修正したシステムの
作業負荷尺度 能力尺度

測定 測定
修正したシステム

図２．１ モデル化サイクル

3
 妥当性確認フェーズはモデルの定義からはじめ、それは表現されるそれらのシステム・
リソースと作業負荷コンポーネントの選択や特別な注意を要するであろういかなるシステ
ムの特徴（例、プライオリティ・スケジューリング、ページング）の特定、モデル構成（例、
分離可能、ハイブリッド）の選択、使用可能な測定データから必要なパラメータを得るた
めの手順を含んでいる。
次に、作業負荷尺度（それらからモデルの入力が計算される）と性能尺度（それらはモ
デルの出力と比較される）を得るためにシステムを測定する。場合によってはこれらは同
じである。例えば、デバイス稼動率は作業負荷尺度（サービス要求時間を計算するために
それらを用いる）でありまた性能尺度（モデルの精度を評価するためにそれらを用いる）
でもある。他方、バッチ作業負荷のマルチプログラミング・レベルは完全に作業負荷尺度
であり、システム応答時間は完全に性能尺度である。
次に作業負荷尺度は、モデルをパラメータ化するのに用いられ、パラメータ化はさまざ
まな変形が必要となるかもしれないステップである。モデルは評価され、出力を生みだす。
これらはシステムの性能尺度と比較される。食い違いは、無視されたあるいは不適切に表
現されたシステム特徴や、間違って値を設定したモデル入力といった過程における不備を
示している。あいにく、そのような食い違いがないことが、システムあるいは作業負荷の
変更の影響をモデルが正しく予測することを保障しない。モデルの予測能力への信頼は２
つの源から来るだろう。第１は、たぶん選ばれた修正を含む、多くの測定期間にわたって
繰り返す妥当性確認である。例えば、もしモデル化スタディの目的がメモリ追加のメリッ
トの評価であるならば、既存メモリのさまざまな量をディセーブルにしながら妥当性確認
フェーズを繰り返すことが可能だろう。２番目はのちに検討する検証フェーズの完了であ
る。
予測フェーズでは、システムあるいは作業負荷に対する予測される変更を反映するため
にモデル入力が修正される。これは複雑な過程で、それについて我々はかなりの注意をこ
の本のあとのほう（第１３章）で払うことになる。次にモデルは評価される。修正したモ
デルの出力と元々のモデルの出力の間の差が修正の予測される影響である。
最後に検証フェーズでは、修正したシステムが測定され２つの比較が行われる。１番目
に、その性能尺度がモデル出力と比較される。２番目に、その作業負荷尺度がモデル入力
と比較される。モデルの予測とシステムの性能の間の食い違いは２つの原因から発生する
可能性がある。すなわち、
（過去にさかのぼって）顕著なシステム特徴の、省略か間違った
表現、と、予想していたのとは異なる仕方でのシステムの発展、である。これらの食い違
いの原因を理解し評価することは、コンピュータ・システム解析技術としての待ち行列ネ
ットワーク・モデル化における信頼を得るのに極めて重要である。モデル性能予測の精度
は、入力として供給された作業負荷予測の精度よりよくなり得ない。
モデル化サイクルを示すために多くの IBM 370/168 と 370/168-AP（デュアル・プロセ
ッサ）とＭＶＳオペレーティング・システムで動いていた 3033 で、ＴＳＯ（会話型処理）
、

4
ＩＭＳ（データベース管理）
、ＪＥＳ（スプーリング）
、ＴＣＡＭ／ＶＴＡＭ（端末管理）
といったアプリケーションと一緒に動作していたものからなる複合計算環境で行われた２
つのケーススタディを説明する。各々のスタディの目的はかなりの作業負荷修正の影響を
決定することであった。
１番目のスタディで考察された質問は「２つの別々の 370/168 ユニプロセッサ上で現在
走っている作業負荷は単一の 3033 上にまとめることが出来るか？」というものだった。
（１
台の 3033 は 168 の処理能力の 1.6 から 1.8 倍を持つと考えられる。
） 各々の元々のシス
テム上では、主要なアプリケーションはＩＭＳ作業負荷であった。さらに、システムの１
つはバックグラウンド・バッチ作業負荷をもっており、両方はさまざまなシステム・タス
クを持っていた。
妥当性確認フェーズで、元々の各々のシステムは測定されモデル化された。ＩＭＳ応答
時間の悪化は修正の予想効果であったので、応答速度は最も関心のある性能尺度であった。
予測フェーズでは、元々の作業負荷（ＩＭＳ−１、ＩＭＳ−２、バッチ）の各々がが個
別に表現され、ＣＰＵのスピードの差を考慮して調整されたＣＰＵサージス要求時間を持
つ単一モデルが定義された。3033 のＩ／Ｏサブシステムは複数の 168 のＩ／Ｏサブシステ
ムの組合せであると仮定したので、Ｉ／Ｏサブシステムのパラメータはけっして変更しな
かった。
作業負荷
性能尺度 モデル出力 測定データ
コンポーネント
IMS-1 43% 40%
IMS-2 31% 32%
ＣＰＵ稼動率
バッチ 3% 3%
計 77% 75%
IMS-1 0.84sec 1.3sec
応答時間
IMS-2 0.79sec 0.89sec
スループット バッチ 2ジョブ/hr 1.7ジョブ/hr
表２．１ モデル化サイクル。ケーススタディ１

検証フェーズでは作業付加は 3033 上にまとめられた。性能尺度はモデル出力と比較され

た。表２．１に結果を示す。それはこのようなスタディで期待出来る結果のうちの典型的
なものである。つまり、モデルの予測は計画に大変有用な程度に正確であり、稼動率の食
い違いは応答時間の食い違いより少ない。
２番目のスタディは下に記述する５つの疎結合システムを含んでいた。
システム ＣＰＵタイプ 作業負荷
1 3033 全てのシステムについてJES
2 370/168-AP 会話型グラフィクス、バッチ
3 370/168-AP バッチ
4 3033 TSO, IMS, バッチ
5 3033 バッチ

5
考慮している質問は「システム５の作業負荷を、性能に関する大きな悪影響なしに他の４
つのシステムに分散し、コスト削減のためにシステム５を解放することが出来るか？」で
あった。
妥当性確認フェーズで、システム２から５までが測定されモデル化された。
（システム１
はスタディから除外された。
）
予測フェーズで、システム２，３，４のモデルにおけるマルチプログラミング・レベル
がシステム５の作業負荷の２７％の追加に対応して増加された。
（管理者はシステム５の作
業負荷の１９％をシステム１に、２７％をシステム２，３，４のそれぞれに配置したいと
考えていた。
） この単純な方法は、さまざまなシステム上でのバッチ作業負荷の類似性の
ために可能であった。
検証フェーズで、システム５の作業負荷は残りのシステムに分散された。各々のシステ
ムについてそれぞれ、性能尺度がモデル出力と比較された。各々の場合で、修正の予測し
た影響は、バッチ作業負荷のリソース消費の増大（そのマルチプログラミング・レベルは
増やされていた）、と他の作業負荷コンポーネントの性能の悪化であった。表２．２、２．
３、２．４はそれぞれシステム２，３，４の結果を示している。やはり、この結果は期待
される結果のうちの典型的なものである。システム修正を含むスタディで使用する場合、
待ち行列ネットワーク・モデルは性能の絶対値よりもよい精度で相対的性能を予測するだ
ろう。表２．２の会話型グラフィクス作業付加の応答時間について考えてみよう。5.2 秒と
元々のモデルは 4.2 秒をはじき出した。
測定されたが、 修正されたモデルは 5.0 秒を示した。
5.0 4.8
これを、応答時間の悪化は 4%、 、であると解釈するのは理にかなっている。
4.8
実際、測定された応答時間の悪化は 7.5%であった。

作業負荷 元々の 元々の 修正した 修正した

性能尺度
コンポーネント システム モデル モデル システム
グラフィクス 76% 74% 74% 72%
ＣＰＵ稼動率 バッチ 11% 10% 13% 13%
計 87% 84% 87% 85%
応答時間 グラフィクス 5.2秒 4.8秒 5.0秒 5.6秒
スループット バッチ 28/hr 27/hr 35/hr 30/hr
表２．２ モデル化サイクル。ケーススタディ２、システム２

作業負荷 元々の 元々の 修正した 修正した

性能尺度
コンポーネント システム モデル モデル システム
ＣＰＵ稼動率 バッチ 63% 64% 76% 73%
スループット バッチ 101/hr 104/hr 130/hr 120/hr

6
 表２．３ モデル化サイクル。ケーススタディ２、システム３

作業負荷 元々の 元々の 修正した 修正した

性能尺度
コンポーネント システム モデル モデル システム
TSO 63% 64% 76% 73%
IMS 3% 2% 2% 2%
ＣＰＵ稼動率
バッチ 15% 15% 21% 20%
計 83% 84% 88% 85%
応答時間 TSO 4.3秒 4.4秒 5.0秒 5.9秒
表２．４ モデル化サイクル。ケーススタディ２、システム４

我々はモデル化サイクルを順序正しい仕方で提示したが、モデル化スタディを実施する
ことはけっして厳密に逐次的な過程ではない。妥当性確認と予測のフェーズのさまざまな
コンポーネントの間には強い依存関係がある。モデルの定義と、モデルをパラメータ化す
るのに用いる測定と、モデルを評価するのに用いる技術との間で整合性を確立しなければ
ならない。この整合性を確立することと、それを特定のモデル化スタディの諸目的と調和
させることは、本質的に繰り返しの性質を持つ。

2.3. スタディの目的の理解
モデル化スタディの妥当性確認フェーズが考察中のコンピュータ・システムの綿密な理
解を要求することは明らかである。そのスタディの諸目的の綿密な理解が同じくらい重要
であることは、たぶん、それほど明らかではない。しかしながら実際、後者の理解は待ち
行列ネットワーク・モデル化のトップダウン哲学の主要要素である。完全に一般的なモデ
ル内で表現される必要があるであろう多くのシステム特徴は特定のスタディにおいては無
関係である。これらの特徴を特定することはより単純なモデルとより単純なモデル化スタ
ディをもたらす。
この現象の典型的な例は、まさにミニコンピュータ・アーキテクチュラル・ファミリー
に新しいＣＰＵをアナウンスしようとするコンピュータ・メーカーを巻き込んだ。このＣ
ＰＵの設計の間、広範囲な低レベル性能スタディが実行され、さまざまな命令ミックスに
ついての平均実行レートのような尺度をもたらした。しかし予想される顧客は、
「特定の構
成において、それがサポート出来る多くのユーザに関して、そのアーキテクチュラル・フ
ァミリーの既存ＣＰＵとそれをどのように比較するか？」というようなより高いレベルの
特徴に興味があるだろう。
メーカはこの種の特徴づけについて過去に用いてきた１５件のベンチマークのセットを
持っていた。各々のベンチマークは４つの作業負荷コンポーネント、つまり、エディティ

7
ングとファイル作成、ファイル修正、コンパイル・リンク・実行シーケンス、を持ってい
た。ベンチマークでは、各々の作業負荷コンポーネントの「ユーザ」数が異なっていた。
これらの「ユーザ」は、リモート・ターミナル・エミュレーション（ＲＴＥ）を用いて生
成された。これは、問題のシステムが、対話するユーザをシミュレートし性能データを収
集する第２のシステムとつながっているような技術である。
あいにく、ＲＴＥ実験を実施する目的で新しいＣＰＵと興味あるＩ／Ｏサブシステムの
プロトタイプを構成することが不可能であった。その代わり、以下の戦略が考え出された。
アークテクチュラル・ファミリー内の既存のより速いＣＰＵを興味のあるＩ／Ｏサブ
システムと構成する。
１５件のベンチマークの各々についてこの構成上でＲＴＥ実験を実施する。
新しい、より遅いＣＰＵに置き換えた場合これらのベンチマークの各々の性能を予測
するために待ち行列ネットワーク・モデルを用いる。２つのＣＰＵの命令実行レート
の比を考慮することによってモデル内のＣＰＵサービス要求時間を確立する。

この戦略を前提すると、明白な方法はシステムのどちらかといえば一般的なモデルを定
義することであることになった。このモデルへの入力は４つの作業負荷コンポーネントの
各々の負荷強度とサービス要求時間である。入力への適切な調整によってモデルは１５件
のベンチマークのさまざまな特徴を反映することが出来る。このモデルの妥当性が確認さ
れたのち、各々の作業負荷コンポーネントについてＣＰＵサービス要求時間が適切に拡大
され、次に新しいシステム上でのベンチマークの能力を予測するために、やはりモデル入
力への適切な調整によってこのモデルが用いられることになった。
この方法はかなりの複雑さを隠し持っている。考慮しているシステムはページングとス
ワッピングの両方を使用する洗練されたメモリ管理方針を含んでいる。ページングとスワ
ッピングのデバイスで各々のユーザが要求するサービスの量は固有のものではなく、むし
ろ、それは各々のベンチマーク内の作業負荷コンポーネントの特定のミックスに依存して
いる。よって、単に負荷強度を調整するだけでは１５件のベンチマークのさまざまな特徴
をモデルに反映することが出来ない。代わりに、作業コンポーネントのミックスの関数と
してページングとスワッピングのサービス要求時間における変動を評価するための手続き
を、システムの一般的な待ち行列ネットワーク・モデルは、モデルの定義の一部として含
む必要があることになった。
そのような手続きを考え出すこと確かに実行可能であるが、それはモデル化スタディを
かなり複雑にし、それは必要でないレベルの一般性を提供する。このスタディの目的が２
つの構成上での１５件のベンチマークの各々の相対能力を評価することに限られていたこ
とを念頭に置けば、各々のユーザのページングとスワッピングの活動は、作業負荷コンポ
ーネントのミックスの変化には反応するが、ＣＰＵ速度の変化には反応しないと仮定する
ことにより我々は顕著な単純化を達成できる。この仮定は、各々の作業負荷コンポーネン

8
トのページングとスワッピングのサービス要求時間を、待ち行列ネットワーク・モデル定
義の一部として提供された手続きを用いて評価するのではなく、ＲＴＥ実験の間に各々の
ベンチマークについて測定することと、モデルへの入力として提供することを可能にする。
このコンピュータ・システム解析問題に対する２つの方法は図２．２に対比されている。
単純化された方法が基盤としている仮定は普遍的に有効というわけではないが、その結果
起こるどんな不正確さも厳密に副次的なものであり、実際、作業負荷コンポーネントのミ
ックスの関数としてページングとスワッピングのサービス要求時間における変動を評価し
ようとした時に必然的に発生する不正確さよりもたぶん小さい。
（セクション２．５でこの
スタディに戻り、さらに詳細をつけ加えることになる。
）

元々のシステム 元々のシステム

パラメータは「固有」な
パラメータは「固有な」 ・・・ ものプラス、ページン
サービス要求時間のみ グとスワッピングの
を含む （×15） サービス要求時間を
含む

元々のモデルの定 元々のモデルの定
義とパラメータ化 義とパラメータ化

・・・
ＣＰＵサービス要 ＣＰＵサービス要
求時間の調整 （×15） 求時間の調整

修正したモデルの定 修正したモデルの定
義とパラメータ化 義とパラメータ化

評価、負荷強度
や、ページングと
スワッピングの ・・・
評価
サービス要求時 ・・・ （×15）
間の調整
（×15）

出力 出力

明白な方法 単純化された方法

図２．２ ＣＰＵ置き換えのモデル化の２つの方法

9
2.4. 作業負荷の特徴づけ
モデル化サイクルの妥当性確認フェーズを検討する際、測定を興味のあるコンピュー
タ・システムの作業負荷尺度を得る過程として、パラメータ化をそれらの作業負荷尺度を
待ち行列ネットワーク・モデルの入力に変換する過程として特定した。これらの活動は、
必ずしも簡単というわけではないが、しばしば作業負荷の特徴づけ、すなわち、性能スタ
ディをその上に基礎付けるところの作業負荷を選択する過程、よりもかなり容易である。
既存のコンピュティング環境を考察する際でさえ困難な質問が発生する。
「典型的な」作
業負荷を構成するのは何か？
測定期間をどのように選ぶべきか？ 数個の測定期間からのデータを平均すべきか？
これらの不確かさは直接測定出来ない環境を考察する際に混入する。
（例えば、既存作業負
荷の新しいシステムへの移行を、あるいは新しい作業負荷の既存システムへの導入を、熟
慮する際に）
。
コンピュータ・システム解析の各々の方法、直感と傾向外挿、選択肢の実験評価、モデ
ル化、は作業負荷の特徴づけを要求する。奇妙なことに、作業負荷の特徴づけに固有の不
確かさは待ち行列ネットワーク・モデルの使用を支持する。原理上は、実験によって、あ
るいはシミュレーション・モデル化によって（顕著に多くの費用で）より大きな正確さが
得られるだろう。しかし実際的には、誤差の支配的な発生源は、待ち行列ネットワーク・
モデルを使用する場合でさえ、作業負荷の特徴づけにある傾向がある。
以下のケーススタディは３つの目的について役に立つ。１番目はベンチマーキングが従
来の方法である状況での待ち行列ネットワーク・モデル化の使用法を示すことである。２
番目は、柔軟性を達成するための方法として階層的作業負荷特徴づけを示すことである。
これによって、我々は高レベル特徴（作業負荷コンポーネントの特定）から中間レベル（コ
ンポーネントの各々の装置独立特徴）を通って低レベル（サービス要求時間）への順序正
しい進行を意味する。３番目は作業負荷の特徴づけにおける重大な不正確さにもかかわら
ず有用な洞察を得られることを示すことである。
1979 年、教育目的用に中規模会話型コンピュータ・システムを取得する計画を始めた。
提案要求（RFP: Request For Proposal）の応答として、だいたい２０件の入札を受け、そ
の大部分が複数システムを含んでいた。候補システムの相対能力は取得決定における主要
要因であるべきであった。この相対能力を評価する２つの方法が考察された。１番目は予
想される作業負荷の複数ユーザ・ベンチマーク特徴を構築し、次にリモート・ターミナル・
エミュレータを用いて各々の候補システム上でベンチマークを走らせることであった。２
番目は候補システム上での限定された測定を実施し、そして待ち行列ネットワーク・モデ
ル化を用いて性能を比較することであった。スタディに利用可能な時間と工数が限られて
おり、そして候補システムが多数であり、予想される作業負荷に関して高度の不確実さが
存在するために、後者の方法は適切であった。

10
 スタディにおける第１ステップは、予想される作業負荷を高レベルの言葉で特徴づける
ことであった。すなわち、特定可能な作業負荷コンポーネントは何か？ 各々のコンポー
ネントの相対量はいくつなのか？ 各々のコンポーネントに属する典型的な処理の顕著な
特徴は何か？ である。
教育目的のコンピュータ環境は以前はバッチモードで運用されていた。この機能の対話
的ファシリティへの移行と、それに続く拡張は、複数の取得を含む数年に渡る過程であっ
た。初期の対話的作業負荷は既存の教育目的バッチ作業負荷とエディティング・コンポー
ネントを足したものと同じ組成であろうと仮定した。
既存作業負荷は顕著なコンポーネントが２つだけであることを測定結果は示していた。
全てのトランザクションのほぼ８０％は Fortran のコンパイル処理であった。全てのトラ
ンザクションのほぼ２０％は学生が作成したデータセットを処理するためのプリコンパイ
ル済ライブラリ・ルーチンの実行であった。コンパイル処理の単純な特徴づけは、ソース
コードの行数の平均であり、だいたい１００行であった。実行の単純な特徴づけは既存シ
ステム上でのそれらの平均サービス要求時間であり、ＣＰＵサービスが 4.55 秒でディス
ク・サービスが 5.35 秒であった。
（これらのトランザクションによって処理される学生が作
成したデータセットの平均サイズは１００行であった。
）
エディティング・セッションは各々のコンパイルあるいは実行に先行すると仮定したの
で、作業負荷コンポーネントの全体の割合は４０％がコンパイル処理、１０％が実行。
、５
０％がエディティング・セッションであろうとした。大部分のエディティングは経験の浅
いタイピストがライン指向エディタを用いてファイルに少数の変更を加えるだろうから、
支配的なリソース要求はファイルのアクセスとセーブの時に発生するだろうと仮定した。
よって、エディトされるファイルの平均サイズ、１００行はエディティング・セッション
の単純な特徴付けであった。
スタディの第２ステップはこの高レベル作業負荷特徴づけを候補システムの各々のモデ
ルについて諸パラメータに翻訳することであった。負荷強度を決定することは問題ではな
かった。３つの作業負荷コンポーネントの各々は、総到着レートの確立された割合に等し
い到着レートを持つトランザクション作業負荷として扱われた。モデル出力は総到着レー
トの範囲について表にされた。各々のシステム上での各々の作業負荷コンポーネントにつ
いてのサービス要求時間（つまり、各々の作業負荷コンポーネントに属するトランザクシ
ョンによって各々のデバイスで要求される平均サービス時間）を決めることは、各々のシ
ステム上で３つの極めて単純な実験を走らせることを含んだ。コンパイル処理については、
１００行のプログラムが他のアイドルのシステム上でコンパイルされ、ＣＰＵとディスク
のビジー時間が測定された。この実験は、ハードウェアの影響や、コンパイラの効率や、
コンパイル処理の開始時と終了時のオーバヘッドを捕捉した。実行については、既存バッ
チ・システム上で測定されたＣＰＵとディスクのサービス要求を縮小拡大した。ＣＰＵサ
ービス用の倍率は、単一の計算処理ベンチマークを既存システム上と各々の候補システム

11
上で走らせることによって得た。ディスク・サービス用の倍率は単一 Fortran I/O ベンチマ
ークを用いて得られた。エディティング・セッションについては、各々の候補システム上
で利用可能なデフォルト・エディタを他のアイドルなシステム上で用い、１００行のファ
イルをアクセスし１行を修正し、ファイルをセーブした。ＣＰＵとディスクのビジー時間
が測定された。
表２．５は３つの候補システム、VAX-11/780 と Prime 750 と Prime 550 についてのこ
れらの実験の結果を示している。両方の Prime 上で利用可能な２つの Fortran コンパイラ
について劇的に異なる効率が観測されたことに注意しよう。また、VAX 上のエディタとフ
ァイル・システム間のインタフェースが相対的に非効率であることにも注意しよう。

サービス要求時間、秒
システム 作業負荷コンポーネント
ＣＰＵ ディスク
コンパイル処理 2 1
Digital VAX-11/780 実行 11.9 10.7
エディティング・セッション 0.5 0.8
コンパイル処理
コンパイラＡ 0.8 0.2
Prime 750 コンパイラＢ 7.0 1.0
実行 13.7 7.1
エディティング・セッション 0.15 0.05
コンパイル処理
コンパイラＡ 1.3 0.75
Prime 550 コンパイラＢ 11.3 3.75
実行 27.9 21.4
エディティング・セッション 0.3 0.1
表２．５ ３システムのサービス要求時間

これらの値に基づいて、候補システムの待ち行列ネットワーク・モデルがパラメータ化
され評価された。
（複数ディスクを表現することは計算されたディスク・サービス要求時間
を数台のサービス・センターの間に分配することを含んだ。パラメータ化は、メモリ・コ
ンテンションによるオーバヘッドを考慮する必要がなかったという事実によって単純化さ
れた。メモリ・コンテンションは通常負荷強度とともに増加する。メモリについて過度に
配備されたシステムは RFP の条項であった。
） 図２．３と２．４はこのスタディの典型
的な結果を示している。すなわち、VAX-11/780 と、コンパイラ A つき Prime 750 と、コ
ンパイラ B つき Prime 750 についてそれぞれのコンパイル処理と実行についての平均応答
時間と総トランザクション到着レートの関係である。Prime の性能はコンパイラの選択に
極度に左右されることと、この選択がコンパイルをしているユーザだけではなく全てのユ
ーザに影響を与えていることに注意しよう。
（注意。これらの結果は考察している特定の構
成と作業負荷についてのみ意味がある。
）

12
 40

Prime 7 50 VAX 78 0
コンパイラＢ
Prime 7 5 0
応答時間（秒）

コンパイラＡ
20

0
0 1000 2000
総到着レート（ﾄﾗﾝｻﾞｸｼｮﾝ／hr）

図２．３ コンパイル処理応答時間と総到着レート

200

VAX 78 0
Prime 75 0
応答時間（秒）

コンパイラＢ
100 Prime 7 50
コンパイラＡ

0
0 1000 2000
総到着レート（ﾄﾗﾝｻﾞｸｼｮﾝ／hr）

図２．４ 実行応答時間と総到着レート

これの変形を簡単に調査することが出来る。ディスク負荷の偏りの影響は、各々のサー
ビス・センターに割当てられるサービス要求時間の割合を変えることによって調査するこ
とが出来る。作業負荷特徴づけの結果への感度をスタディすることが出来る。例えば、３
つの作業負荷の相対到着レートを変えることが出来るだろう。

13
2.5. 感度分析
コンピュータ・システム解析者は皆、問題の多い仮定を導入しなければならないような
状況に遭遇する。感度分析はそのような仮定がスタディの結論に疑いを投げかける程度を
決定するために使用することが出来る。感度分析は多くの形式をとることが出来る。最も
普通なもののうち２つは、以下のものである。
解析者は問題の仮定についての結果のゆるぎなさをテストするだろう。それを行うこ
とは仮定のさまざまな変形について何回もモデルを評価することを含む。
解析者は期待する性能についての境界を、仮定の極端な値についてモデルを評価して
得るだろう。

不正確な測定データはしばしば感度分析を促す原因である。この状況に立ち向かう感度
分析の役割を示すためにセクション２．３で紹介したＣＰＵ置き換えのケーススタディに
戻ろう。図２．２に示すように、この方法は必要とする１５件の別々の実験を１ベンチマ
ークあたり一つ、採用した。個々の実験は３つのフェーズからなっていた。すなわち、既
存システムはベンチマークのうちの１つを実行している間に測定され、待ち行列ネットワ
ーク・モデルが構築され妥当性を確認され、このモデルは、各々の作業負荷コンポーネン
トのＣＰＵサービス要求時間パラメータを操作することによって、新しいＣＰＵでのベン
チマーク性能を予測するために用いられた。
システムのＩ／Ｏ活動のかなりの割合が使用可能な測定ツールによって特定の作業負荷
コンポーネントに帰着されなかったので、妥当性確認フェーズの間、困難に遭遇した。例
えば、測定期間の間の総スワップ数と、１スワップあたりの平均ディスク・サービス要求
時間を決定することは可能であったが、どのユーザあるいは作業負荷コンポーネントがス
ワップの「犠牲者」であるかを決定することは不可能であった。仮にこのスタディが単一
クラス・モデルに基づいていたならば、これは問題ではなかったであろう。しかし目的は
４つの作業負荷コンポーネントそれぞれへのＣＰＵ置き換えの影響を評価することであっ
たので、複数クラス・モデルが要求された。
この測定されたＩ／Ｏ活動を４つの作業負荷コンポーネントの間で割当てるさまざまな
方法は若干のモデルの入力パラメータについてさまざまな値をもたらした。驚くことでは
ないが、モデルからさまざまな応答時間の予測がもたらされた。例として、ベンチマーク
の１つにおいて、ファイル修正トランザクションについて測定された応答時間は１０秒で、
一方、測定されたＩ／Ｏ活動を４つの作業負荷コンポーネントの間で割当てる、異なるし
かし同程度に根拠のある、方法について、モデルは応答時間を６、７、１１秒と予測した。
（同様に、他の３つの作業負荷コンポーネントの応答時間についてこのモデルからまこと
しやかな諸結果が得られた。
）
モデルが応答時間を６秒と予測した場合における入力の集合について考えよう。より遅
いＣＰＵに置き換えることを反映するためにＣＰＵサービス要求時間が調整された時、こ

14
のモデルは、応答時間が７．２秒であると予測した。新しいシステム上でファイル修正ト
ランザクションの応答時間が７．２秒であると主張するのは理に合わない。というのは既
存のより速いシステム上で測定された応答時間は１０秒だったからである。また、応答時
7.2 6.0
間は２０％ 増加すると主張するのも理に合わない。というのは、ＣＰＵ置き
6.0
換えの予想効果が、作業負荷コンポーネントの間で測定されたＩ／Ｏ活動を割り付けるの
に使用した方法にについて鈍感であると信じる理由がないからである。しかし、我々はそ
のような鈍感さを仮定し、次にこの仮定をテストすることが出来る。表２．６は既存ＣＰ
Ｕと新ＣＰＵを持つシステムについてＩ／Ｏ活動割付の３つの方法についての予想応答時
間を示している。３つの方法について応答時間の絶対値は異なっているが、予想変化率は
そうではない。よって、ＣＰＵ置き換えの影響は、ファイル修正トランザクションの応答
時間において大体２０％の増加になる、つまり１０秒（測定された値）から１２秒になる、
と結論することが出来る。
（他の３つの作業負荷コンポーネントについて同様の結果が得ら
れた。
）
Ｉ／Ｏ活動を割り 作業負荷コン 応答時間（秒）
付ける方法 ポーネント 元のＣＰＵのモデル 新ＣＰＵのモデル 予想変化
エディティング ・・・ ・・・ ・・・
ファイル作成 ・・・ ・・・ ・・・
Ａ ファイル修正 6 7.2 ＋20%
コンパイル・リン
・・・ ・・・ ・・・
ク・実行
エディティング ・・・ ・・・ ・・・
ファイル作成 ・・・ ・・・ ・・・
Ｂ ファイル修正 7 8.3 ＋18%
コンパイル・リン
・・・ ・・・ ・・・
ク・実行
エディティング ・・・ ・・・ ・・・
ファイル作成 ・・・ ・・・ ・・・
Ｃ ファイル修正 11 13.1 ＋19%
コンパイル・リン
・・・ ・・・ ・・・
ク・実行
表２．６ ３つの仮定の応答時間

2.6. 洞察の源
待ち行列ネットワーク・モデル化の主要な長所は、モデル化サイクルがスタディ中のコ
ンピュータ・システムについての多くの洞察を生みだすことである。これらの洞察は作業
負荷特徴づけや、モデル定義や、システム測定や、モデルのパラメータ化や修正解析の最
中に発生する。モデル化サイクルの予測フェーズの間に得られたモデル出力は洞察の多く
の源のうちの１つでしかないということを心に留めることは重要である。以下のケースス
タディを考察しよう。
ある保険会社がそのクレーム処理を、２０の地理的に分かれたサイトに同一のミニコン

15
ピュータ・システムを設置することにより分散化した。作業負荷が増えるにつれて、これ
らのシステムは適切な応答を提供することを止め、２段階のキャパシティ拡張プログラム
が始まった。すなわち、全てのサイトでの、元々のベンダから２つの利用可能なソフトウ
ェア・コンパチブルなシステムのうちの１つへの即座のアップグレードと、それに続く「制
約のない」システムの購入とソフトウェアのコンバージョンの３年に渡る過程とである。
両方の段階の選択肢を評価するために待ち行列ネットワーク・モデル化が用いられた。こ
のセクションでは、各々のサイトの「移行用システム」の選択について考慮する。
一緒に作業をして、ベンダ（ＩＢＭ）とその保険会社は、仮に既存システム（どちらの
場合も 3790）はより安価な２つの移行用システム（8130）に置き換えられたならば性能は
「１．５から２．０倍に向上し」
、仮により高価な移行用システム（8140）に置き換えられ
たならば「２．０から３．５倍に向上し」たであろうと評価していた。
（これらの文章には
かなりの曖昧さがあることに注意しよう。
） モデル化スタディの趣意書は、３年間の移行
期間の間、受入れ可能な性能を達成するためにより高価なシステムを２０サイトのうちの
どこで要求されるかを決定することであった。
このスタディをサポートするために提供された情報は、
「生の」作業負荷のもとでいくつ
かのサイトで行われた既存 3790 システムの測定や、さまざまな数の事務員がスクリプトか
らトランザクションを入れたベンチマーク試行の間の 3790 とより高価な移行用システム
（8140）の測定や、３システムのＣＰＵとディスクのスピードを比較したベンダからの情
報を含んでいた。
「生の」作業負荷テストは、３つのはっきり分かれた作業負荷コンポーネ
ントが存在しているが、これらの１つで、主要な興味があるものとして予め特定されてい
たものが、トランザクションの約７５％とリソース消費の約９０％を占めていることを明
らかにした。それゆえ単一クラス・モデルがふさわしいと判断された。相対ハードウェア
速度のベンダによる評価は（考えられる負荷強度の範囲に関して）制約がありすぎて全体
性能についていかなる洞察も生み出さなかったが、ベンチマーク・テストはそれらを確認
した。利用可能な情報の全てを考察することによって、以下に示すサービス要求時間を計
算することは可能であった。

サービス要求時間（秒）
システム
ＣＰＵ ディスク
3790（既存） 4.6 4.0
8130 5.1 1.9
8140 3.1 1.9

前述のように、２つの移行用システムは、既存システム上のディスクに比べて約２倍速い
同一のディスクを装備されていた。移行用システムはそのＣＰＵが異なっていた。8130Ｃ
ＰＵは実際、既存 3790 のＣＰＵより若干遅いが、一方 8140ＣＰＵは約５０％速かった。
さてキーとなる観察をしよう。既存システム上では作業負荷はＣＰＵ制約である。さら

16
に、応答時間が受入れ不可能なので、ＣＰＵがほぼ飽和しているのに充分なくらい作業負
荷が高いと仮定することが出来る。これらの環境のもとでは 8130 のより速いディスクはど
うでもいいが、一方そのより遅いＣＰＵはかなりの重荷である。さらに調査することなく
3790 を 8130 で置き換えることは応答時間の悪化を引き起こすことを結論出来る。
我々は、
この解析を元にして、保険会社は 8130 上でベンチマーク・テストを実行した。これらの
テストは解析を支持し、全てのサイトは 8140 にアップグレードされるという結果を得た。
（このスタディは第５章でさらに考察される。
）

2.7. まとめ
待ち行列ネットワーク・モデルを用いたコンピュータ・システム解析の最も挑戦的な側
面はモデルの定義やパラメータ化、評価の技術的詳細ではない。むしろ、待ち行列ネット
ワーク・モデル化の一般的「方法論」を特定のコンピュータ・システム解析の状況に合わ
せて調整する過程である。前者は教えるが簡単だが、あいにく後者は経験を通して最もよ
く学ばれる。この章で我々は、この方法論の顕著な側面を示すために選ばれた一群のケー
ススタディを提示することによって、読者に他の人々の経験を共有することを試みた。我々
が強調した点の中には以下のことがある。

待ち行列ネットワーク・モデル化は本質的にトップダウン過程であり、そこではシス
テムの低レベルの詳細はその高レベルの性能特徴と無関係であると仮定されている。

待ち行列ネットワーク・モデルは抽象物なので、モデル化スタディを実施する際、多
くの仮定がなされる。これらの仮定は簡便さや、測定値の妥当性や、評価のし易さが
動機になっている。なされた仮定や、それらの導入の動機や、それらのもっともらし
さについての議論が明白であることは重要である。

モデル化スタディを実施することは、モデルの定義やモデルをパラメータ化するため
に用いる測定やモデルを評価するのに用いられる技術や特定のモデル化スタディの目
的の間に存在する依存性のために繰り返し過程である。

モデルの予測能力についての核心は、たぶん選ばれたマイナーな修正を含む、多くの
測定期間に渡る繰り返しの妥当性確認によって得ることが出来る。

システム修正を含むスタディで用いる場合、待ち行列ネットワーク・モデルは性能の
絶対値よりずっと正確に相対性能を予測する。

17
 モデル化スタディの目的の明確な理解はモデルにおける、そしてモデル化作業におけ
る単純さに寄与することが出来る。

システムあるいは作業負荷の修正の主要効果を表現することに集中することも単純さ
に寄与することが出来る。

作業負荷の特徴づけは挑戦的な、本質的に不明確な過程である。有用な洞察はこの不
明確さにかかわらず得ることが出来る。階層的に作業負荷を特徴づけることは柔軟性
を達成するのに役立つ。

感度分析は、疑わしい仮定がスタディの結論に疑いを投げかける程度を決定するため
に用いることが出来る。感度分析の２つの普通な形式は仮定のさまざまな変形に関す
るモデル出力の安定性をテストすることと、仮定の極端な値についてモデル出力の境
界を得ることである。

価値のある洞察は、単に予測フェーズにおいてだけでなく、モデル化サイクルの全体
から得られる。

2.8. 参考文献
仮定を導入することの動機としての単純さの特定や測定の妥当性や評価のし易さは
Kienzle と Sevcik [1979]に負っており、彼らはまたモデル化サイクルを妥当性確認、予測、
検証のフェーズに分けることを提案してくれた。
セクション２．２で述べられたＭＶＳケーススタディは Lo [1980]によって実行された。
セクション２．３と２．５で述べられたＣＰＵ性能比較は Myhre [1979]によって実行され
た。セクション２．４で述べられたシステム取得ケーススタディは Lazowska [1980]によ
って実行された。（図２．３と２．４はこの論文から採られた。
） セクション２．６で述
べられた保険クレーム処理ケーススタディは Sevcik と Graham と Zahorjan [1980]によっ
て実行された。

[Kienzle と Sevcik 1979]

M.G. Kienzle と K.C. Sevcik。コンピュータ・システムの性能モデル化の体系的方
法。Proc. IFIP W.G.7.3. International Symposium on Computer Performance
Modelling, Measurement and Evaluation (1979), 3-27.
[Lazowska 1980]

18
 Edward D. Lazowska。システム選択の際の解析的モデル化の使用。Proc. CMG XI
International Conference (1980), 63-69.
[Lo 1980]
T.L. Lo。待ち行列ネットワーク・モデルを用いたコンピュータ・キャパシティ計
画。Proc. IFIP W.G.7.3 International Symposium on Computer Performance
Modelling, Measurement and Evaluation (1980), 145-152. Copyright (c)1980 by
Association for Computing Machinery.
[Myhre 1979]
Scott A. Myhre。平均値解析に基づいた待ち行列ネットワーク求解パッケージ。
M.Sc. Thesis, Department of Computer Science, University of Washington,
February 1979.
[Sevcik 他 1980]
K.C. Sevcik と G.S. Graham と J. Zahorjan。分散処理システムにおける構成とキ
ャパシティの計画。Proc. 16th CPEUG Meeting (1980), 165-171。

19