[投稿}Webアプリケーション・サーバの応答時間近似式を求む（by expmlさん）
わたくしのブログに・・・・。なんと投稿依頼が来ました！ こんなブログでよかったら、どうぞ使って下さい。
ということでexpmlさんからの投稿を載せます。これは、９／１９にアップした「助言を求む（expmlさんの質問）」の背景を示した論文です。私の興味とも重なる部分が多いので、これについて、これから勉強します。今まで私は工場の生産管理のことしか念頭においていませんでしたが、コンピュータ・システムの応答時間という世界もおもしろそうですね。ちょうど今、待ち行列ネットワークを用いたコンピュータ・システムの性能解析の教科書を和訳しているところですし・・・。
では、ここからがexpmlさんの投稿です。
Webアプリケーション・サーバの応答時間近似式を求む（by expmlさん）
＜Webサーバのチューニング例：単一URL＞
- Webサーバのハードウェア増強もソフトウェア改修もしないで、Webサーバの流量制御パラメタチューニングだけで、Webサーバの応答時間を最小化できれば、コスト低減になります。
- そこで、Webサーバの流量制御パラメタだけを変えて、高負荷を発生するツールを用いて同一負荷をかけた時の応答時間を比較すると、下記のようなグラフを得ることはできます。
- しかしながら、上記グラフ中の”実測値”の１本のグラフのデータを収集するコストは、マシン増設費用と比べて無視できない程度に大きなものです。
- そこで、上記グラフ中から統一比較用の負荷量（例えば４０多重）の応答時間の値を“同時実行件数”の値毎にプロットした下図のようなグラフ、および、そのグラフの近似式から“応答時間が最小になるような最大同時実行件数設定値”を推定できることが望まれます。
- しかしながら、上記３点の実測値をつないだ舟形曲線から、その後の検証で確認できた「最大同時実行件数設定値(処理窓口数)は8多重」という最適値をしたり、「最大同時実行件数設定値(処理窓口数)を５多重からに増やすと、６秒だった応答時間を５秒程度まで速くできる」という改善効果を推定手法は、確立されていません。
- 「５台のWebサーバを６台に増やさないで、応答時間を２０％速くできる」ということを、マシン１台増設する費用より圧倒的に低コストで算定できれば、かなり価値があります。
＜Webサーバのチューニング例：２種のURL＞
- 小生が経験的に得たデータでは、Webアプリケーション・サーバの負荷量毎URL毎の応答時間は、下の式でも そこそこ近似できています。
：最大同時実行件数（処理窓口数)が
個のWebアプリケーション・サーバに、L個のURLリクエストが内部保留（実行中け件数＋処理待ち件数）された場合の、特定の１種類のURLがWebアプリケーションサーバに受け付けられてから応答されるまでの時間。
- ただし、Webアプリケーション・サーバ内のURLが１種類の応答時間特性であれば、上記式のPの値は１でソコソコ近似でききていた経験データもありますが、同時期にアクセスされるURLの種類が何種類かあって、その応答時間特性が異なる場合は、
の値が１ではありません。しかも、
- 従って、
- Webアプリケーション・サーバの最大同時実行件数（maxThreads)（処理窓口数）の最適値選定ポリシーは、そのシステムの用途によって変わりますが、下記の何れかが好かろうと考えられます。
- 特定の１種類のURLが高負荷時に最も速くなる設定
- 全種URLの平均応答時間が、最も速くなる設定（スループット最大化）
- “Webサプリケーションサーバのスループットは、単位時間当たりのURL処理件数で計られます。
- 例えば、下図に示したf1(最大同時実行件数が15が最速）のURLと、従って、スループットは同時期にアクセスされうる何種類かのURLが混在したアクセスでの計測値で、Webサーバにアクセスするクライアント端末から途中の通信路の通信時間も無視できない計測値です。従って、単一URLの応答時間の逆数では決して近似できませんが、全種URLの平均応答時間の逆数であれば、相関関係が高い値は算定できますので、「全種URLの平均応答時間を最小化」と「スループット最大化」とは、概ね同じチューニング結果となります。"
- 例えば、下図に示した{f1とf2}の性能特性のURLが1対1の比率でアクセスされる場合、その全種URL平均応答時間{avg(f1,f2)}は、最大実行件数設定値（処理窓口数）を6に設定にした{avg(f1(6,x),f2(6,x)}が最速くなることが推定できます。 下図には比較対象として最大同時実行件数設定値を10に設定した場合の{avg(f1(10,x),f2(10,x)}も重ねて描いています。
- "どちらのポリシーでチューニングするにしても、上記近似式の
に依存して変わるため、環境設定変更を何度か試行錯誤して最適値を求めることが必要になっています。
- 二分探索的に｛100多重の設定,50多重設定、10多重の設定、5多重設定,2多重設定,7多重設定,6多重設定}と変えて比較する等 ある程度実験計画を工夫しても、そのデータ収集作業に要するコストは大きなものです。"
- しかしながら、1回のデータ収集だけで精度の高い近似式が得られて、それによって下図のような「最大同時実行件数設定値毎の、特定負荷量に対する応答時間」のグラフを描くことができて、｛負荷量が２０多重で、全種URLの平均応答時間を最小化できる最大同時実行件数設定値は、6多重が最適」という結果を示せるならば、チューニング作業コストを数分の１に低減できます。
- また、最大同時実行件数の最適値が、6多重であると算定できたとしても、その改善効果の大きさを示せなければ、実際に環境設定変更作業に反映する決断ができません。
- 例えば、下図のように「現状設定（最大同時実行件数設定値が１０多重）を、最大同時実行件数設定値を6多重に変えた場合、高負荷（系内保留URL件数が２０件）の場合のスループットを２０％増やすことができる」という効果を示すことができて、その上で、「環境設定変更の為に、Webアプリケーションサーバを用いた生産活動を何時間か止めても、翌日以降のスループット改善(20%up）で 元が取れる」という、経営的な判断の材料の提示が必要です。
- "最大同時実行件数を変えた場合のスループット効果を示す場合に、上図に示した二コブの山なり型から、１つの山に変われば改善効果を示すことができます。
- また、上記グラフの形は、冒頭の近似式から派生して描ける形で、しかも現実のWebアプリケーションサーバのスループットの特性グラフに ある程度似た形にはなっています。
- しかし、残念ながら、｢1回の高負荷試験データ収集から得られる近似式」で、上記のような改善効果まで予測できるような、高精度の近似式を見つけておりません。"
以上
