サーバー転送量が契約の最大値の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ヘッダに対応するつもりです。
投稿