先日の修正で管理下のWikiに転送量削減の仕組みを追加したのですが、その結果を報告します。

　結論から言いますとそれなりの効果があったように思います¹。以下にその判断にいたったデー
タや考察をまとめます。

導入
　導入したものは304送信機能追加のrefプラグイン²とWeb cache³です。両方とも当方の自作で完成しだい速攻管理下のWikiに導入してみました。加えた改造によるマイナス要因は理論上は考えられないので効果は有るだろうとは推測できましたが、全く検証・実証してないのに効果が有る(だろう)とか言う事はガチガチの理系人間な自分の中では許されないと思ったので自ら検証する事にしました。

データ
　Oblivion Wiki JP (避難所)のデータです。

　08-08～08-14の中ごろにrefプラグインを304機能を付与した物に交換したのでその週を省いています。また、08-21～08-28の週の途中でWeb cacheを導入したので同じく省略しています。08-29～09-04は改造refプラグインとWeb cacheの両方が機能しています。
ステータスコードは200と304以外の割合はきわめて低い⁴ので単純に200と304の比を比較に使用します。

考察・結論
　先ず、最初に行った改造refプラグインの効果です。転送量を見ると全く効果が無いように見えますがこれはお盆時期でアクセスが集中したせいでしょう⁵。よって転送量をアクセス数で割った値、即ち1アクセスあたりの平均転送量を見るべきです。で、そこを見ると1リクエストあたり約80Bの減少が見られます。これは誤差の範囲かどうか見極めがつけ難い微妙な値です。たった1%程度の差では効果の有無は断言できません。ステータスコードの発生比(304/200)をみると304の比率が増加しているので効果が有るっぽいとは言えるでしょう。もう少し検討対象データを広げたりrefプラグイン自体へのリクエストを分析すれば判定できそうですが流石に面倒なのでやりません⁶。このようにあまりはっきり効果が現れなかったのはOblivion Wiki JP (避難所)はあまり画像添付を行なわれていないせいでしょう。

　次にWeb cacheの効果です。同じく『1リクエストあたりの平均転送量』と『304/200』を見てみますとかなり明確な差が出ています。前者は1kB近い差が出ていますし、後者もはっきりとした違いが見受けられます。当方が管理しているWikiはHTMLデータの転送はgzip圧縮を利用しているので、若しそれを行わなかったらその差はもっと開いたでしょう⁷。

　結論としてはそれなりに効果はあったと見てよさそうです。検証方法としては手抜きも良い所なのですが、趣味ですしこれくらいで良しとします。

余談
　アクセスログを見ると延々何時間も同じページを定期的⁸にリクエストし続ける人がいます。特にOperaな人にその傾向が見られます。たしかにOperaは自動F5機能がデフォルトで有るようですが。まあ、F5アタックのつもりならもっと簡単にもっと性悪な事が出来るので恐らくそのアクセスは操作ミスだと思います。というか何でOperaにはそんなサーバ負荷をかけるような機能がデフォルトであるのか理解できません。設定できる最短時間間隔が5秒なんて十分イカレてます。まぁ最近のサーバはスペックの進歩もありその程度はへっちゃらーんなのでしょうけど。ただこれも通常のブラウザを使用している故に、今回の話題であるWeb cache機能でうまく受け流せるようになりました⁹。よしよし。

後日談 (2011-08-21)
1年ほどずっと運用していますが特にトラブルはないようです。サーバの能力もしっかりしているので敢えてここまでの転送量対策をする必要は高くは無いのではありますが……そこにやりたい事があるから挑戦する、その精神は大事かなーと思っています。

さて現状の話です。管理下のWikiでの設定はちょっと弱めなのですがとりあえず効果は有るようです。Oblivion/Fallout 3ともにアクセス数は減少傾向なので厳密な検討はしていませんが、アクセスログ解析を見ると大体そんな様子が見て取れます。有意差の検証等は面倒なので今のところは保留していますが、1年間の運用結果を又同じように分析する事もありかもしれません。要検討という事で。
　前述の通り、設定は弱め¹⁰なのであまり弊害は発生しないと考えていましたが、環境によっては稀にキャッシュが効き過ぎる事があるようです¹¹。サーバとブラウザの息が合わない事が原因だと思うので正直解決法が見つからないです。当方の環境で再現できればまだ手は有ると思うのですが。最悪、304機能のON/OFFをCookieに設定してそれで対応を変えるって方法も有るでしょうが……場当たり的な気がして手をつけていません。そもそも負荷がでかいWikiでそのような逃げ道を作るのはあんまり良くない気がします。それが閲覧者のF5アタックに繋がる可能性も有りなかなか難しい問題だとは思っています¹²。

1. 有意差が有るか等の詳細検討は省きます [↩]
2. http://z49.org/2010/08/24/479/ [↩]
3. http://z49.org/tag/web_cache/ [↩]
4. 0.01%以下 [↩]
5. この少し前に一部の海外からのアクセス禁止を投稿禁止に緩和したのでその影響も有るかもしれない [↩]
6. こういう微妙なデータを色々統計的手法を使って判定するのって結構楽しいのですが [↩]
7. 因みに画像はgzip転送を行わない(行っても意味が無い) [↩]
8. 1分間隔とか [↩]
9. それ以前から過度or妙なアクセスに対してはしばし門前払いするシステムを組み込み済みでしたが [↩]
10. Convert_Cacheも導入しているので [↩]
11. ブラウザキャッシュクリアでも駄目っぽい [↩]
12. その対策に管理下のWikiではそれぞれのページのタイトル付近のそのページの更新時間を表示するようにした。デフォルトはページのフッタに有るので分かり難い [↩]