12.3.客の記述（２）：Quantitative System Performance

「12.3.客の記述（１）」の続きです。（ 目次はこちら）

　個別の客クラスとして表現されるべき個々の作業負荷要素を特定しそのクラスのタイプを決定したのちの次のステップは、個々のクラスの負荷強度を定めることである。トランザクション・クラスについては負荷強度はトランザクション到着レートである。正当に長い観測期間に渡って飽和してないシステム内で、到着レートは元来、完了レートと同じである。よって、クラスの到着レートの見積りは以下のようになる。

• クラスの測定された完了数／測定期間長さ

　バッチ・クラスについては、負荷強度はアクティブなバッチ客の数の平均で与えられる。、クラス客の数、の見積りはいくつかの仕方で得ることが出来る。

• もし、ジョブが固定の数の領域内で処理され、かつ、メモリ待ち時間が高ければ（そうであれば、観測期間の大部分において個々の領域はビジーであることが知られる）、は処理領域の数である。
• もしソフトウェア・モニタがサンプリングによって観測期間に渡ってのクラスの平均マルチプログラミング・レベルの見積もりを提供するならば、はその見積りであると考えることが出来る。
• もしアカウンティング・データが中核サブシステム内の個々のジョブの滞在時間を提供するならば、は以下によって見積もることが出来る。
  • 
  • ただし、は測定されたジョブ滞在時間、は測定期間長さ。
  • （この代替案は、アカウンティング記録からこの情報を自動的に抽出することが出来る縮小パッケージを使用することなしには実行出来ない。）

　端末クラスについては、負荷強度はアクティブな端末の数、、と平均考慮時間、によって指定される。端末クラスのを見積もるために３つの可能なやり方が、バッチ・クラス用に使用される３つの方法に直接対応する。

• もし、端末が限られた数のポートを通してシステムに接続していて、かつ、観測期間の大部分を通して全てのポートがビジーであれば、はポートの数である。
• もしソフトウェア・モニタが観測期間に渡っての平均アクティブ端末数を提供するならば、はその数であると考えることが出来る。
• もしアカウンティング・データがセッション長を含んでいるならば、は（終端効果を制限するために平均セッション長に比べて長い観測期間に渡って）以下によって見積もることが出来る。
  • 
  • ただし、は測定されたセッション長、は測定期間長さ。

　端末クラスの平均考慮時間はしばしば見積ることが最も困難な入力パラメータの１つである。それにはいくつかの理由がある。第１に、考慮時間がいつ開始して終了するかについて異なる見方が存在する。我々は、それはシステムからの応答の最初の文字の到着から始まり、システムへの次の要求の最後の文字が入力された時に終了するという見方を採用する。第２に、若干のシステムは応答を待つことなしにコマンドの流れを入力することを許している。そのようなシステムは（上記で定義したような）考慮時間が負になることを引き起こす可能性がある！　第３に、若干の考慮時間は非常に長くなり、それは実際にはアクティブ端末のロスを表現している。（これは、端末ユーザがログオフすることなく自分の作業を中断する時に起こる。）　第４に、平均考慮時間は性能モニタによってめったに直接測定されることはない。よって、考慮時間の最良の見積もりはしばしば応答時間の法則からの を見積もることによって得られる。

• 

ただしは上記に説明したように見積られ、 とは測定された値である。考慮時間の見積もりは他のパラメータの見積もりに比べて信頼性が低いので、この値のモデルでの感度をテストすることが望ましいだろう。
　トランザクションや端末のクラスにメモリ制約が課せられている場合、セクション９．３のモデル化方法を使用出来るように個々のドメインに関するキャパシティを指定することが必要である。個々のドメインのキャパシティは通常、システム記述から知られる。特定の測定期間内にドメインがキャパシティ一杯であったかどうかはそのドメインに割当てられたクラスのうちでアクティブである数の平均（モニタが報告するように）をドメインのキャパシティと比較することによって明らかになる。

「12.4.センターの記述」に続きます。