noriyuruの日記： ApacheとKeep Aliveの実験
日記 by
noriyuru
Apacheのログ取りと設定を見直すため、いくつか実験を行った。
Keep Aliveにまつわる観測結果と導き出される設定について、ここに記す。観測はApacehログを利用した。
Keep AliveはHTTP/1.1で定められたもので、1度の接続で複数のリクエストと、その応答を行うことを目的としてる。接続の継続と終了のためにヘッダーConnectionフィールドを定めている。Connectionフィールドはブラウザー、サーバー共に出力する。
ブラウザーは引き続き要求コンテンツがあればkeep-alive、なければcloseだ。IEとFirefoxは常にkeep-aliveだ。たぶん、世界中のほとんどのブラウザーは常にkeep-aliveを出す。よってサーバーは最後のコンテンツを認識する方法がない。だから、ApacheでKeepAliveをONにすると常にkeep-aliveを返す。もちろん例外もある、MaxKeepAliveRequestsなどを設定してサーバー側で切断する場合だ。
クライアント側は接続を分割する場合がある。これは1クライアントが1接続にならないことを意味する。つまり、Keep Alive設定でリクエストを待ち続けても利用されない場合がある。/にあるindex.htmlと3つの画像で構成されるコンテンツ（"Welcome to Your New Home in Cyberspace!" ―つまりDebianでApacheを入れたときのデフォルト）の場合でログを観察すると、Keep Aliveを有効にしても両ブラウザともに2つの接続を作り出しているようだ（ログ中のプロセス番号出力から）。
結局のところHTTPはステートレスであることを考えなければならない。サーバーはベストを尽くすだけである。以上のことから考えられるApacheの設定について述べる。
１．KeepAlive Off
常にKeep Aliveしない。昔のチューニング解説はこう書いてあった、と記憶している。サーバーはベストを尽くすだけである。
２．KeepAlive On,MaxKeepAliveRequests 0,KeepAliveTimeout 1
Keep Aliveはする。接続中のリクエストは無限に受け付ける。
無限に続くリクエストは受け付けるとまずい気がするならば100くらいにすればよい。どのみちリクエストには返答せねばならない、リクエストの善悪を判断する方法はサーバーにはない。ただし、もしかしたらリクエスト受付プログラムにメモリーリークがあるかもしれない。もっともそんな話を聞いたことはない。そういった杞憂を防ぐ程度の効果はあるだろう。
KeepAliveTimeoutの設定は重要である。これがプロセスの無駄な生存時間になる。
これは、一つのリクエストから、次のリクエストまで待つ時間を定義する。これはどのような事態であるか？ 例えば、ブラウザーが/であるindex.htmlをGETして、それをパースし、含まれる画像などのほかのコンテンツを要求する。このことから、最初のリクエストから次のリクエストまでサーバーからの返答とそれをパースする時間が掛かることがわかる。
さて、ブラウザーは次のリクエストまで何秒かかるだろうか？ 結論をいえば不明であり0秒はない。ではKeep Aliveは無駄なのだろうか？ そうでもない、なぜならRFC2616の8章ではリクエストのパイプライン化について述べられている。そして、ここがポイントだ。
パイプライン化されたリクエストならば、あるリクエストの終了から次のリクエストの開始の間は0秒のはずだ。少なからず、システム全体を考えるとApacheには時間差を認識する方法はない。もし、0秒以上ならば（可能性はある）何秒待てばよいのかは分からない。
これらのことから最短時間である1秒を指定するのがベストだと考えられる。
※最悪、パイプライン化されたリクエストがTCP/IPパケットの境界、socketバッファーの狭間？ に挟まって0秒以上と認識されてしまうかもしれない。
※Keep Alive中にサーバーからの返答をまってからリクエストを送るクライアントがあるかもしれない。例えばTelnetによる手動リクエストが考えられる。そのような動作はサーバーにとってはただの負荷である。なぜならサーバーは本当にリクエストがあるのか、ないのか判断できないからだ。このような場合、サーバーはcloseを返すので問題も起こらない。
※余談だが0だと全部closeされた、本当に0秒らしい。
もしかしたら、サイトによってはもっとベストな設定の組み合わせがあると思うかもしれない。そう考える人は設定1をすすめる。
相互にベスト尽くそうにもブラウザーがcloseしない、サーバー側でベストを尽くすにはApacheのKeep Alive設定が荒すぎる。それらの原因は「HTTPはステートレスであり、あるサイトへの複数のリクエストが同じ条件で処理される保証がない」との考え方が根底にある。
Keep Aliveにまつわる観測結果と導き出される設定について、ここに記す。観測はApacehログを利用した。
Keep AliveはHTTP/1.1で定められたもので、1度の接続で複数のリクエストと、その応答を行うことを目的としてる。接続の継続と終了のためにヘッダーConnectionフィールドを定めている。Connectionフィールドはブラウザー、サーバー共に出力する。
ブラウザーは引き続き要求コンテンツがあればkeep-alive、なければcloseだ。IEとFirefoxは常にkeep-aliveだ。たぶん、世界中のほとんどのブラウザーは常にkeep-aliveを出す。よってサーバーは最後のコンテンツを認識する方法がない。だから、ApacheでKeepAliveをONにすると常にkeep-aliveを返す。もちろん例外もある、MaxKeepAliveRequestsなどを設定してサーバー側で切断する場合だ。
クライアント側は接続を分割する場合がある。これは1クライアントが1接続にならないことを意味する。つまり、Keep Alive設定でリクエストを待ち続けても利用されない場合がある。/にあるindex.htmlと3つの画像で構成されるコンテンツ（"Welcome to Your New Home in Cyberspace!" ―つまりDebianでApacheを入れたときのデフォルト）の場合でログを観察すると、Keep Aliveを有効にしても両ブラウザともに2つの接続を作り出しているようだ（ログ中のプロセス番号出力から）。
結局のところHTTPはステートレスであることを考えなければならない。サーバーはベストを尽くすだけである。以上のことから考えられるApacheの設定について述べる。
１．KeepAlive Off
常にKeep Aliveしない。昔のチューニング解説はこう書いてあった、と記憶している。サーバーはベストを尽くすだけである。
２．KeepAlive On,MaxKeepAliveRequests 0,KeepAliveTimeout 1
Keep Aliveはする。接続中のリクエストは無限に受け付ける。
無限に続くリクエストは受け付けるとまずい気がするならば100くらいにすればよい。どのみちリクエストには返答せねばならない、リクエストの善悪を判断する方法はサーバーにはない。ただし、もしかしたらリクエスト受付プログラムにメモリーリークがあるかもしれない。もっともそんな話を聞いたことはない。そういった杞憂を防ぐ程度の効果はあるだろう。
KeepAliveTimeoutの設定は重要である。これがプロセスの無駄な生存時間になる。
これは、一つのリクエストから、次のリクエストまで待つ時間を定義する。これはどのような事態であるか？ 例えば、ブラウザーが/であるindex.htmlをGETして、それをパースし、含まれる画像などのほかのコンテンツを要求する。このことから、最初のリクエストから次のリクエストまでサーバーからの返答とそれをパースする時間が掛かることがわかる。
さて、ブラウザーは次のリクエストまで何秒かかるだろうか？ 結論をいえば不明であり0秒はない。ではKeep Aliveは無駄なのだろうか？ そうでもない、なぜならRFC2616の8章ではリクエストのパイプライン化について述べられている。そして、ここがポイントだ。
パイプライン化されたリクエストならば、あるリクエストの終了から次のリクエストの開始の間は0秒のはずだ。少なからず、システム全体を考えるとApacheには時間差を認識する方法はない。もし、0秒以上ならば（可能性はある）何秒待てばよいのかは分からない。
これらのことから最短時間である1秒を指定するのがベストだと考えられる。
※最悪、パイプライン化されたリクエストがTCP/IPパケットの境界、socketバッファーの狭間？ に挟まって0秒以上と認識されてしまうかもしれない。
※Keep Alive中にサーバーからの返答をまってからリクエストを送るクライアントがあるかもしれない。例えばTelnetによる手動リクエストが考えられる。そのような動作はサーバーにとってはただの負荷である。なぜならサーバーは本当にリクエストがあるのか、ないのか判断できないからだ。このような場合、サーバーはcloseを返すので問題も起こらない。
※余談だが0だと全部closeされた、本当に0秒らしい。
もしかしたら、サイトによってはもっとベストな設定の組み合わせがあると思うかもしれない。そう考える人は設定1をすすめる。
相互にベスト尽くそうにもブラウザーがcloseしない、サーバー側でベストを尽くすにはApacheのKeep Alive設定が荒すぎる。それらの原因は「HTTPはステートレスであり、あるサイトへの複数のリクエストが同じ条件で処理される保証がない」との考え方が根底にある。