2.4. 作業負荷の特徴づけ（１）：Quantitative System Performance

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

2.4. 作業負荷の特徴づけ

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

「2.4. 作業負荷の特徴づけ（２）」に続きます。