2004年12月の記事

Anonymous氏よりHEADリクエストを使用しているRSSリーダーは皆無 (BlogId:37)へ以下のコメントを頂きました。

HEADよりも If-Modified-Since で GET してくるクライアントの方が多いよ。こっちの方がリクエスト一回で304か202か判断できるので効率的な気がする。

恥ずかしいことに、webmasterはIf-Modfied-SinceはHEADリクエストでのみ送られてくるものだと勘違いしていました。If-Modified-Sinceヘッダを送ってくれるUAを収集したところ、沢山のクライアントが対応している様子でした。リクエスト数１位のRSSバーは対応していない様子ですが、２位のgoo RSSリーダーは対応していました。

早速、Googleニュース関連のRSSのPHPスクリプトを修正してIf-Modfied-Sinceヘッダを送ってくれるクライアントに対して、更新が無いときはHTTP/1.1 304 Not Modifiedを返すようにしました。数日間、転送量を監視してみようと思います。

尚、If-Modified-Sinceヘッダの値の解釈にはモジュール版PHPで「If-Modified-Since」に対応するに掲載されている関数を利用させて頂きました。Etagについても参考にさせていただきました。

関数を利用する際に、動作確認を行ったところ最初はうまくいきませんでした。調べてみたところ、Content-lengthを返していた場合のIf-Mdofied-Sinceの値に対応していないようでした。たとえばSat, 18 Dec 2004 13:44:54 GMT; length=2153といった値です。「;」以降があるためにうまく解釈できない様子でしたので、正規表現を使用して「;」以降を削除するようにして対応しました。以下がサンプルコードです。

$headers['If-Modified-Since'] = preg_replace("!;.+$!is", "", $headers['If-Modified-Since']);

順次、アクセスの多いRSSも対応していきたいと思います。

2004-12-18 written by akiyan　|　記事　|　固定リンク　|　トラックバック (0)　|　

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購読者を呼び起こしてしまったのでしょうか...。

これ以上どうしようもないので、転送量無制限のサーバーをレンタルしようと思います。

2004-12-18 written by akiyan　|　記事　|　固定リンク　|　コメント (2)　|　トラックバック (1)　|　

2ヶ月前から、「超」整理手帳を使い始めました。

数週間先のスケジュールを一望できるジャバラ式スケジュールシートは納期に追われる立場な人にはかなりお勧めできる機能です。A4用紙を４つ折にして挟み込めるフューチャーも、使ってみれば「なるほど便利だ！」と思えます。今まで挟み込めなかったのが当たり前なので体感するまでピンと来ない点ですが「なんで今までこんな簡単で便利なことができなかったんだ」と思えますよ。

スケジュール管理に重点を置く方、A4用紙が手元に散乱している方は一度試してみて損は無いと思います。是非。

2004-12-18 written by akiyan　|　レビュー　|　固定リンク　|　トラックバック (0)　|　

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

2004-12-13 written by akiyan　|　記事　|　固定リンク　|　コメント (3)　|　トラックバック (2)　|