2005年01月31日(月) [過去の今日]
RFC2068 にpipeliningはサーバの負荷を下げるから強く実装を勧めるとあるので、ロードアベレージの上昇まで考えてなかったな。英語読み違えたかな? あ、更新版があるのか。 RFC2616の日本語翻訳 めっけ。
んーと、ここか
TCP コネクションの開閉が少なくなる事で、ルータやホスト (クライアント、サーバ、プロクシ、ゲートウェイ、トンネル、キャッシュ) における CPU 時間は節約され、TCP プロトコルコントロールブロックのために使用されるメモリも節約される。
[- 日記システム警告：コマンド TCP は予約されています。-]HTTP リクエストとレスポンスは、接続上でパイプライン化する事ができる。パイプライン化によって、クライアントは、各々のレスポンスを待つ事なく複数のリクエストを行う事ができ、また1つの TCP 接続をより少ない経過時間で、より効果的に使用できる。
確かにコネクションの開閉のことしか考えてないみたいだな。
転送量は確かに減るっぽいな。 実験レポートを見付けた ので見てみたら、
HTTP/1.1 Pipelining は HTTP/1.0 (6パラ) と比べて、
- パケット数は55%〜65%減少 (PPPでは16%)
- 時間は約40%短縮 (PPPでは10%)
- バイト数はほとんど変化なし (ヘッダが減少した分のみ?)
だそうだ。
つまり全体の計算量自体は減るはずなんだわな。持続的接続でコネクション開閉数を減らし、pipeliningでパケット生成数を減らすってことか。
一瞬に集中されるよりもそこそこのアクセスが分散して発生してくれたほうがうれしい ってのは、俺も半分中の人だからよくわかるけども、GET数ではなくアクセス数で考えると、アクセスは分散してくれたほうがうれしいのは間違いない。でも1アクセス中のGET数が分散するかはページの作りの問題でもある。1アクセスあたりの処理がちまちま時間食ってるよりはとっとと終ってくれた方が、ユーザーにもページの管理者にもサーバの管理者にもうれしいようにも思う。そこで他の処理が犠牲になるかはOSのマネージャによりけりなんかな。
具体的にデータを取って検証してみたいとこだが、うまい検証方法が思い付かないな。いいアイディア無い?
＠ っていうか:
1つのページに何個もCGIやら画像やら置くような作りが一番サーバに負荷かかるって事だな……
(@562)
＠ pipeliningの功罪:
仲間たちといろいろ話した結果、確かにルータやネットワークには優しいが、サーバには優しくないぞと。たくさんのリクエストをがんがん処理するんだから当然っちゃ当然だろうと。んー、ラグが無くなるだけかと思ってたが、そういうわけでもないのか。
で、よくよく考えなくても当り前なんだが、pipeliningが効果を発揮するのは、一つのHTML文書で画像やらをたんまり使ってる場合なんだわな。そういう意味では、pipeliningによる負荷というのは
- 弱いサーバで画像たんまり使ってる奴が悪い
- pipeliningで負荷をかける奴が悪い
と、二者択一になるわけだ。
で、pipeliningはネットワーク負荷の軽減を目的としたものであるからして、使うことはHTTP/1.1の仕様書でも推奨されてる。そう考えると、やっぱり弱いサーバで画像たんまり使ってる奴のほうが悪いんじゃないの、という結論に達してしまうわな。
なるほど、俺がひっかかってたのはここだな。pipeliningは迷惑だからやめましょう、ではなく、pipeliningがたくさん発生するようなページを作るのは迷惑だからやめましょう、ということでいいのかな。
(@675)