13.2.1.負荷強度の変更：Quantitative System Performance

「13.2.作業負荷の変更」の続きです。（ 目次はこちら）

13.2.1. 負荷強度の変更

　もっとも頻繁に研究されている作業負荷の変更は強度の変更である。自然に、そのような変更の主要効果は、適切な負荷強度入力パラメータを修正することで反映される。
　トランザクション・クラスについては、通常の作業負荷予測は「トランザクション量の３０％増加」といったものである。これはモデルでとすることによって表すことが出来る。
　端末クラスについては、通常の作業負荷予測は「アクティブ・ユーザ数の５０％増加」といったものである。これはモデルでとすることによって表すことが出来る。（反対する証拠がないので、平均考慮時間は変化しないと仮定するのが適切である。）
　トランザクションと端末の両方のクラスの場合、主メモリを巡る競合の増加が、負荷強度の増加からもたらされることになる。もしベースライン・モデルがメモリ制約（「最大でも２０要求しか同時にアクティブでない」）を含んでいたならば、我々は同じ制約がやはり適用されると仮定するだろう。もしそのような制約がベースライン・モデルに存在になかったならば、解析者は、パラメータの修正からもたらされる中核サブシステムの個体数の増加量が使用可能なメモリ量を考慮すると現実的であるかどうか決めなければならない。もし、そうでなければ、適切なメモリ制約が課せられるべきである。いずれの場合も、オーバヘッドの可変要素（例えば、ページングとスワッピングのサービス要求時間）は増加するだろう。これはセクション１３．５で議論される。
　バッチ・クラスについては、作業負荷予測がマルチプログラミング・レベルに関して言及されることは普通ではない。（もっとありそうなのは、そのような言い回しはメモリの追加や再配置を記述するために用いられるだろう。）　ベースライン・モデルでのこのパラメータの値はいくつかの要因のせいであり得るという事実からさらに複雑さが増す。ひとつの極端では、バッチ・ジョブの持続するバックログが存在するので、はメモリ制約を反映している。この場合、バッチ・ジョブの使用可能性の増加はバックログの増加をもたらすだけだろう。別の極端では、もしバッチ・ジョブが到着した時にそのほとんどが即座にアクティブになるに充分なメモリが使用可能であれば、の値はメモリ制約に関係しない。この場合、バッチ・ジョブの使用可能性の増加はの増加を可能にする。通常、バッチ・クラスの作業負荷の予測はスループットに関して述べられる。解析者は予測スループットを達成するようにを調整し、次に中核サブシステムの個体数の増加が使用可能なメモリに関して現実的かどうかを考察しなければならない。

「13.2.2.作業負荷要素の特性の変更」に続きます。