2.2. モデル化サイクル（２）：Quantitative System Performance

待ち行列ネットワークへの助走

「2.2. モデル化サイクル（１）」の続きです。

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


　検証フェーズでは作業付加は3033上にまとめられた。性能尺度はモデル出力と比較された。表２．１に結果を示す。それはこのようなスタディで期待出来る結果のうちの典型的なものである。つまり、モデルの予測は計画に大変有用な程度に正確であり、稼動率の食い違いは応答時間の食い違いより少ない。
　２番目のスタディは下に記述する５つの疎結合システムを含んでいた。


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

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


「2.3. スタディの目的の理解」に続きます。