5.3.1.ケーススタディ:Quantitative System Performance

5.3.漸近的境界の利用」の続きです。(目次はこちら

5.3.1.ケーススタディ


 漸近的境界解析はセクション2.6で紹介したケーススタディで啓発的であった。(そのセクションは追加の背景のために見直されるだろう。)
 保険会社はIBM 3790で装備された12の地理的に分散したサイトを持っていたが、受入れ不可能な応答時間を提供していた。その会社は3年間の選択、購入、移行のサイクルに入ることを決意したが、中間のアップグレードが必要であった。IBM 8130と1IBM 8140の両方が既存アプリケーションソフトの実行が出来、よって3年間の移行期間の間使用することが考慮された。ベンダとの検討ののち、会社は8130の使用は3790に比べて性能が1.5〜2のファクタの改善をもたらす一方、8140の使用は2〜3.6のファクタの性能改善をもたらすだろうと確信した。(「性能改善ファクタ」の意味の精密な陳述は定式化されなかった。)
 より安価な8130システムで充分なサイトを決定するためにモデル化スタディが開始された。8130と8140の両方のシステムが3790のものより大幅に速いディスクを含んでいることが知られていた。CPUスピードに関しては、8130プロセッサは3790より若干遅いが、8140は約1.5倍速かった。この情報や既存3790システムの「生の」測定や2つのシステム(3790と8140)上でのベンチマーク実験の組合せにより、以下の処理要求時間が決定された。


 処理要求時間が規定されたので、3つのシステムのそれぞれから期待される性能を評価するために境界モデルが使用された。図5.2に待ち行列ネットワークを示す。(若干のサイトは物理的に2つのディスク・ドライブを持っていたが、ディスク・コントローラはそれらを同時にアクティブにすることを許していなかった。このため、モデルで1つのディスク・サービスセンターを持っていることは適切である。) パラメータは、以下の通りである。

  • K、サービスセンターの数 (2)
  • D_{max}、最大の処理要求時間(3790は4.6秒、8130は5.1秒、8140は3.1秒)
  • D、処理要求時間の合計(それぞれ8.6、7.0、5.0)
  • 客クラスのタイプ(端末)
  • Z、平均考慮時間(60秒という見積りが使用された)。

 
 アルゴリズム5.1を3つのシステムの各々のモデルに適用することによって図5.3にグラフ化された楽観的漸近的境界が導かれた。(明確さのために悲観的境界は省略された。) これらは、重負荷では、8130の能力は3790の能力よりも劣ることを明らかにしている。これは8130がより遅いCPUを持っていて、それがボトルネック・デバイスであるという事実の結果である。よって、3790から8130への移行において、アクティブな端末の数があるしきい値を超えた時はいつでも、1.5から2倍の性能向上よりもむしろ、性能悪化が予想される。図5.3は3790から8140への移行における性能向上を示しているが、2以上の予想したファクタではない。
 移行計画に8130を含めることの推奨度を再評価するために、スタディを元にして追加のベンチマーク・テストが行われた。これらのスタディは、端末数が約15以上になる時、8130の性能は3790の性能より悪くなることと、より負荷が軽い場合、8130の3790に対する性能向上は取るに足りないことを確認した。よって、どのサイトにおいても8130に投資する性能的な理由はなかった。結局、会社は移行期間の間に全てのサイトで8140を実装することを決心した。単純なモデル化スタディなしでは、会社はそれらについてのベンチマーク・テストを行うことなく8130を注文して、がっかりするような結果を得たことだろう。(注意書き。このスタディで到達した結論は異なる作業負荷を含む状況では必ずしも成立しない。)

5.3.2.ボトルネック除去の効果」に続きます。