HTTP Keep-aliveについて質問です。

>Webではむしろリクエストは散発的になるので

確率として、MaxKeepAliveRequestsが予測できるので
あればそれ以上連続した要求がないと仮定できる時間を
KeepAliveTimeoutに設定すればよいはずですが。
サーバに同一クライアントから常に繰り返し処理が依頼する
場合、KeepAliveTimeoutをあまり短くするとプロセスの
常駐コストと、生成コストのどちらが低いか？
(プロセスではないかもしれませんが）
と言うことになります。
KeepAliveTimeoutより短い間隔でクライアントからの
要求が発生すると設定しても意味がありません。
KeepAliveTimeoutより長い間隔でクライアントからの
要求確立が高い場合設定する意味はあります。

　

補足ありがとう御座います。

せっかくコメント頂いたんですが、
今一つ理解することが出来ませんでした。


＞サーバに同一クライアントから常に繰り返し処理が依頼する場合
との事なので、通常のブラウジングではなくポーリング等を行っているような状況のお話かと思います。
プロセスの常駐コストと生成コストの分岐点があるのも、具体的には分かりませんが確かにありそうだと思います。

しかしどうしても理解できないのは、KeepAliveTimeoutより長い間隔でクライアントからの要求確立が高い場合、の部分です。
KeepAliveTimeoutより長い間隔の要求ということは、その要求がある時プロセスは終了している事になると思います。
KeepAliveTimeoutが短すぎると生成コストが常駐コストより高いかも、という話の流れからKeepAliveTimeoutを長めにすべき状況もあるのだろうとは思いつくのですが、それでも要求間隔はKeepAliveTimeoutより短くなければプロセスが終了しているので、長く常駐した上に必要になる前に消えるという事に、ならないのでしょうか。
これがどうしても分からなかった部分です。
説明が長くなってしまいましたが、良かったら教えて下さい。


これを書いていてふと思ったのは、KeepAliveTimeout以内に2度目の要求があった場合、常駐プロセスで処理することになって、KeepAliveTimeoutはその2度目の要求から数えなおしてくれるんだろうか・・・

>KeepAliveTimeoutより長い間隔でクライアントからの
>要求確立が高い場合

当然プロセスは消滅していることになります。
この場合、例えば30秒以上の間隔の要求が予想
される場合にKeepAliveTimeoutが15秒がとした場合、
クライアントの要求が完了した後 平均7.5秒程度の時間無駄
にプロセスを維持する可能性があるので、より短い
KeepAliveTimeoutにより短い値を設定するより早く
無駄な資源を解放できると言う意味があると言う事になります。

>KeepAliveTimeoutより長い間隔でクライアントからの
>要求確立が高い場合
細かい話ですが、プロセスは消滅しません。コネクションが消滅するだけです。

理論上はすべてのコネクションを接続しっぱなしにしておくのが最速かと思われます。
ただ、現実問題 Web サーバーは多くのクライアントから同時に接続を受け付けているわけでそんな事をすればあっという間にＣＰＵとメモリ資源を食い尽くしてダウンしてしまいます。
サーバー資源とコネクションの永続化のバランス点として一般的には短い方が効率がよいと言うだけです。

極論すれば特定１０端末からの接続しかありえない状況であれば、KeepAliveTimeout は無限でも構わない事になります。（実際にはそのほかの要因もあるのでそういうわけにもいきませんが）

>サーバー資源とコネクションの永続化のバランス点として
>一般的には短い方が効率がよいと言うだけです。
↑システムがより高い限界近い負荷で動作するようになった
　場合、従来以上の想定以上の要求を受け入れ。
　システム特性によってはサービスに何らかの不具合を発生
　原因となる可能性があります。実環境では慎重に調整
　する事をお勧めします。
(MaxClients未満で過負荷)

　システムに余力があるのであればあえていじる必要は
　ないかと思います。

>圧縮したファイルや動画等ファイルサイズ

質問に関係ありませんが、趣味としては
　大容量のデータ配布をする場合、ＷＥＢ系の処理と
　大容量データの処理と切り離した違うサーバ(論理・物理）
　で分けて処理したい気分ですが。

色々とご説明ありがとう御座います。
<br />
> 例えば30秒以上の間隔の要求が予想
> される場合にKeepAliveTimeoutが15秒がとした場合、
> クライアントの要求が完了した後 平均7.5秒程度の時間無駄
> にプロセスを維持する可能性があるので、より短い
> KeepAliveTimeoutにより短い値を設定するより早く
無駄な資源を解放できると言う意味がある
<br />
なるほど分かりました。
一般的なwebサイトの場合、
各ページに付随する画像等は数秒のうちに要求が来るので、
2回目のページへのアクセスがどのくらいに来るかを考えると、
ユーザによってですがちゃんとページを読んだりしているならばそれなりの時間がかかりますね。
であれば、さっさとタイムアウトさせてしまった方が良いので、
一般的にKeepAliveTimeoutは短くとなるわけですね。
<br />
> 細かい話ですが、プロセスは消滅しません。コネクションが消滅するだけです。
プロセスは残っているなら、やはりにKeepAliveTimeoutは短くして接続を終わらせた方がいいって事になるのかな。
と思いますが、ここまで来るとしっかりと調べないと一概にそうとも言えないケースもあるんでしょうね。
<br />
> システムがより高い限界近い負荷で動作するようになった
> 場合、従来以上の想定以上の要求を受け入れ。
> システム特性によってはサービスに何らかの不具合を発生
> 原因となる可能性があります。
同じユーザが割りと短い間隔で要求を発生することが多いサイトなんかは、KeepAliveTimeoutをその間隔をカバーする形で設定したほうがよさそうですね。
もしくはポーリングをしているとかの場合。
システム特性というのはこの辺の事なのかなと思っていますが、あまり自信はありません。
<br />
> システムに余力があるのであればあえていじる必要はないかと思います。
デフォルトの15秒は、恐らく殆どの場合で無駄になっていそうなので、とりあえず一般的に採られる数秒を自分のデフォルトにして、そこから状況に合わせて調整するようにしようかなと思います。

>システム特性というのはこの辺の事なのかなと

例１：（接続に対してなんらかのリソース割り当てを行う場合）
ログインしている間一定期間リソースを
保持するサービスがあるとします。
リソースを保持する期間は、例えば自動ログオフする
時間15分程度とした場合。
従来は、KeepAliveTimeoutのせいで過負荷時は新規に
ログイン数は抑えられていましたが、より沢山のサービス
要求が確立出来るようになり同時にログインする数が
増えました。　結果として管理するリソースが増加。

例２：（接続数オーバー)
比較的繰り返し、処理を要求する画面遷移を
している場合、KeepAliveTimeoutが短くなりMaxClients
付近まで接続数が推移していたため、ＷＥＢページをアクセス　
するとエラーページが頻発して表示されるようになる。

例３：（処理が重い場合）
遅い回線、端末で端末で処理するJavaScriptや、画像
などの処理が重くて遅い場合、端末が次の要求を出す前に
KeepAliveTimeoutになり。さらに遅くなる。

==========================================
設定の前後でCPU/RAM/接続端末数/ログイン数/IO負荷率
/回線利用率等をモニターしてしておけば問題が発生する
兆候が何かあるはずです。