RSS配信で配信しているRSSの転送量削減対策として、HEADリクエスト時にLast-ModifiedとContent-lengthを返すようにしました。しかし、成果は全くといっていいほど上がりませんでした。HEADリクエストを送るUAがほとんど皆無だからです。
変更と同時にHEADリクエストを送信するUAを収集する機能を実装したのですが、数日経過した今、HEADリクエストを確認できたUAはたったの２つでした。収集に使用したRSSは、１日17万アクセスを受けているGoogleニュース関連のRSSです。
- Samurize Client Script http://www.samurize.com/
- Hatena Diary RSS Module (http://d.hatena.ne.jp/help#rssmodule)
Samurize Client Scriptは詳細は不明です。Hatena Diary RSS ModuleははてなのRSS読み込み機能ですね。あと、UA名がLWP::Simple/5.68のものと、空のものが数件ありましたが１日数アクセスしかありませんので除外します。
たったの２つ、しかもこのクライアントはリクエスト全体の１％も満たしていません。結城氏が言及したRSSのトラフィックの問題はかなり深刻な状況にあることがわかりました。配信側がいくら対応しても、クライアント側が殆ど全く対応していないのですから。←これは誤りでした。殆どのクライアントはHEADリクエストで更新を確認するのではなく、GETリクエストでIf-Modified-Sinseヘッダを送って転送量を削減していました。（2005-01-07追記）
RSSリーダーを作成している皆様へ。ネットワークトラフィックの節約のためにも、配信側の負担軽減のためにも、転送量を削減するための実装を切に願っております。
HEADリクエスト対応は処理フローを考えると少々面倒だと思いますので、まずはgzip転送から実装しては如何でしょうか。RSSは単純なテキストデータなので、gzip転送に対応するだけで少なくとも転送量は半減します。クライアント側も体感できるほど高速化できるますので、是非お願いいたします。
ちなみに、blogに転送量対策のエントリを入れた途端にRSSへのアクセスが急増してしまい、断続的に300MByteオーバーしている状況です。潜在的なRSS購読者を呼び起こしてしまったのでしょうか...。
これ以上どうしようもないので、転送量無制限のサーバーをレンタルしようと思います。
3 Comments