RSS配信転送量対策
サーバー転送量が契約の最大値の1000MByteを断続的に超えるようになってしまい、転送量の９割以上がRSS配信のRSSだったので、転送量対策を行いました。
対策は２通り行いました。gzip転送対応と、アイテム件数の削減です。gzip転送
は成果は上がりませんでしたが、アイテム件数の削減は効果が出ました。直接RSSの容量を減らしたわけですから当然といえば当然ですが。
gzip転送は、リクエスト数の多いRSSを対象に対応しました。gzip転送に対応したクライアントからのアクセスであれば、転送量が1/3～1/7に減少するのでかなり期待していました。しかし、しばらく転送量を監視したところほぼ全くと言っていいほど成果は上がりませんでした。
メジャーなRSSリーダーはgzip転送に対応していないということか？と疑問に思ったので、UAのリクエスト数ランキングをみたところ、RSSバー（１位）とgoo RSSリーダー（２位）が８割を占めていたので、http-accept-encodingヘッダを確認できるRSSを用意してgzipに対応しているか実際に確認しました。案の定、両リーダー共にgzip転送に対応していませんでした。
今後の対応に期待して、RSSバーの作者様と、goo RSSリーダーのサポートセンターへgzip転送への対応要望を出しました。
RSSはその性質上、一日に（多いときは１時間に）何度もアクセスされるリソースなので、トラフィック削減に繋がるgzip転送には是非対応すべきだと思います。RSSリーダーを公開するor公開している方や企業にはgzip転送の対応を期待しています。
ちなみにwebmasterが愛用するHeadline-Readerもgzip転送に対応していませんでした。
アイテム件数の削減は、リクエスト数の７～８割を占める、Googleニュース関連のRSSを対象にしました。今までは各カテゴリのニュースをすべて配信しており、20件全て配信していました。今回の対策で最大で15件までに絞りましたので、5件の節約です。結果、１日の転送量が100～150MByteほど減少し、1000MByteを下回りました。とりあえずはこれで一安心です。
次は、HEADリクエストとLast-Modifiedヘッダに対応するつもりです。
関係あるかわからんけども、mod_rubyをアレしたりしていたのですが、nph-CGIというものに出会いました。
http://www.nurs.or.jp/~sug/homep/logging/log2.htm
これの「304」が使えるかもとか思ってコメント。知ってたらゴメンよ〜。
If-Modified-Sinceのことですね。304。
ちなみにHEADリクエストとLast-Modifiedヘッダには既に対応しましたが、
肝心のHEADリクエストを送ってくれるUAが
・Samurize Client Script http://www.samurize.com/
・Hatena Diary RSS Module (http://d.hatena.ne.jp/help#rssmodule)
以上の２つしか確認できず、ほとんど成果が上がっていません。
そして304を返すことのできるのは
HEADリクエストを送ってくれるUAだけなので、
実装しても殆ど意味が無いという。
クライアント側にしてみればHEADリクエストなぞ投げて一々確認しなくても
GETリクエストでいっぺんに取得しちゃっても十分だからでしょうか。
むしろHEADリクエスト→GETリクエストを行うと
余計遅くなることもありえるから、
いきなりGETしちゃったほうが確実で早いのかもしれません。
ちなみに、blogにこのエントリを入れた途端にRSSへのアクセスが急増してしまい、
断続的に300MByteオーバーしている状況です。
潜在的なRSS購読者を呼び起こしてしまったのでしょうか...。
これ以上どうしようもないので、転送量無制限のサーバーをレンタルしようと思います。
カンパ窓口でも作ってみようかとも考えてます。
RSSバーの勧め
最近流行ってどんどん増加するブログ。FC2も登録数2万突破したらしいです。10月下旬に始めたサービスがもう2万人突破ですか。同じ人が2,3個登録したりしてそうで...
以前、RSSバーへの要望としていただきました下記対応を行った1.10を公開しました。
・If-Modified-Sinceの対応
・Accept-Encoding:gzipの対応(gzipへの対応)
ご要望ありがとうございました。
RSSバーがIf-Modified-Sinceとgzipに対応