転送量削減効果に関する継続報告

 前の記事でPukiWikiに自作の転送量削減機能を組み込んだ事を報告しましたが、効果のほどをもう少しきちんと見極める為に追加で実装後の変化のデータを取って見ました。

データ

 Oblivion Wiki JP (避難所)のデータです。効果の程を判定しやすいようにデータ数を増やしています。
『対照』は転送量削減機能導入前のデータです。転送量やリクエスト数が極端に異なるものを選んでいますので期間は様々です。
 表が横長になっちゃって見難いですが、行と列を入れ替えるのが面倒なのでこうしてます。すみません。

項目 対照 (2009-11-01~11-07)1 対照 (2010-07-18~07-24)2 対照 (2010-08-01~08-07)3 refプラグイン304機能導入 (08-15~08-21) Web cache (2010-08-29~09-04) Web cache (2010-09-05~09-11) Web cache (2010-09-12~09-18)
総リクエスト数 1,815,914 841,242 855,453 119,1379 821,195 798,403 823,720
転送量 (GB) 17.10 7.33 7.67 10.59 6.48 6.22 6.37
1リクエストあたりの平均転送量 (B) 9416.75 8713.31 8966.00 8888.86 7890.94 7790.55 7733.21
200 OK 1,430,710 684,680 699,293 953,548 630,433 596,794 602,234
304 Not Modified 384,633 156,259 155,886 237,393 190,470 201,270 221,094
304/200 0.2688 0.2282 0.2229 0.2490 0.3021 0.3373 0.3671

考察・結論

 結論から言いますと、Web cache機能の効果は有ったように思われますがrefプラグインの改造の効果の程ははっきりしませんでした。

 Web cacheに関しては『1リクエストあたりの平均転送量』や『304/200』で実装前と実装後での差が明らかです。特に304 Not Modifiedの送信割合がわずかなりとはいえ増加傾向にあるのはかなり期待させてくれます4
 
 対して、refプラグインに関しては『1リクエストあたりの平均転送量』で導入時の値を未導入時5の値が下回っており、導入時の変化は誤差の範囲内にとどまっているとも言え、効果が有るかの判定は不能です。前回の記事でも触れましたが、refプラグインへのリクエストに関して抽出して厳密に調査しないと正しい結果は出せないでしょう。気が向いたら時にでも調査してみようと思います。

余談

 全管理WikiにWeb cacheを導入するする際に修正をミスったせいで数時間Wikiが編集が出来なくなっていたのは秘密です6。え?言ったら秘密じゃないって?このぽんこつめがー、ですって?あーうー……ごめんなさいです。Tumuguneさん、ご報告頂き誠にありがとうございました。

 あと、同じくその時にもうひとつ修正を間違っており、Convert_Cache7が利かない状況になっていました。サーバコンパネを覗いたらCPU時間8いつもの2-3割増し5割増し位9だったのでびっくりして色々調べたら修正ミスが原因だということに気づきました。やーい、自分のぽんこつー。幸いサーバの能力のおかげで問題は表面化しませんでした。Load Average10でも派手な変動は見られなかったようです。黙っていればバレなかったのですが……恥かきついでということで。Convert_Cacheで負荷半分って、偉大なんだと再認識したしだいです。

 余談ついでに。ログの分析でPHP Scriptを書いて処理しました11。で、気になったのでメインPC(PhenomII X4 965, CygwinでソースからコンパイルしたPHP 5.3.3)とローカルサーバ機(Atom330, Debian, PHP 5.2.4 PHP 5.2.6)で処理時間を比較してみました。実験対象は09-01~09-18のアクセスログ約100MB(圧縮時。展開すると約1.3GB)。処理時間は前者が88秒、後者が280秒でした。大きな性能差があるにもかかわらずAtomさんは健闘しているっぽいです。普通にファイルを読み込んで書き出すだけなので大した処理はしてないのですが。また、メイン機で色々試したのですが、公式から入手したPHPバイナリよりもCygwinで自分でコンパイルした方が明確に速いという結構予想外な結果が出ました。あた、アクセスログを事前に展開してから処理するより、圧縮状態でgzipファイルを読み込む形で処理した方が早いという結果も出ました12。書き出しにはバッファを使う方法でデータがいくらか溜まってから書き出す処理にしましたが、ためしに1行づつ書き出す形にしたら10倍以上の時間がかかりました13。色々勉強になる実験結果が得られて個人的には満足でした。

  1. アクセスがとんでもなく集中した週のデータ。何があったのだったかなぁ、このころ…… []
  2. 平均的なデータ []
  3. 導入直前 []
  4. ∵後になればなるほどWiki閲覧者が見るページが以前見た事のあるページになる可能性が高くなる。よって、ローカルキャッシュが有効に利用されているならば全体的に304の占める割合が時間の経過と共に或る程度まで増加すると予想できる []
  5. 2010-07-18~2010-07-24 []
  6. requireすべきライブラリをrequireしてなかったのでエラーが発生していた。しかもWeb cache機能のおかげでローカルWebキャッシュを積極的にブラウザが使用するようになっていたので問題が表面化しにくかった []
  7. PukiWiki側のキャッシュ機構 []
  8. サーバ負荷だと思って良い []
  9. だと思う。CPU時間はコンパネからしか確認できず、3日分しかログが保持されないので自信なし []
  10. 負荷の指標のひとつ。CPUコアの数以下ならサーバ的には余裕な状況と考えてよい []
  11. さくらはアカウント上の全てのドメインへのアクセスが単一のログに記録される。よってドメイン毎の分析を行いたい場合は分割処理を行わないと不便 []
  12. これはHDD速度が制限要因になったのだろうと推測 []
  13. 88秒→1,000秒。HDD速度かファイルのオープンクローズにかかる時間のどっちかと思われる []

コメントを残す

メールアドレスが公開されることはありません。