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