W3TCパフォーマンステスト – 塵芥空間

W3TCパフォーマンステスト

Posted by – 2009年11月8日

W3 Total Cache Benchmark Graph

W3 Total Cache(W3TCは)Page Cache、Minify Cache、Detabase CacheにDisk、Memcached、APCなどいくつかの設定ができるので、どの組み合わせが最良か、ab(Apache Bench)を用いてテストを行った結果、実はどれでも大差ない事がわかった。

テスト方法は、このサイトに対して、abを用いて次のコマンドを実行し、Time taken for tests:の値に着目してテストを行った。

ab -n 100 -c 10 http://jinkai.macaro.net

まず、APCを有効にしない、Apche単体でテストを3回行うと、27.144824秒、27.836070秒、27.471900秒と概ね27秒程度を要した。

次に、APCのみを有効にしApacheのテストを3回行うと、20.884433秒、21.294718秒、20.516184秒と概ね20秒~21秒前後となった。

W3TCを有効にし(APCも有効)毎回キャッシュをすべて削除しPage Cache{Disk, Memcached, APC}、Minify Cache{Disk, Memcached, APC}、Database Cache{Memcached, APC}の組み合わせ18通りをテストすると1.8秒~3.9秒程度まで結構数字がばらつくが再現性がなく、どの組み合わせでも大差ない事がわかった。但し、どの組み合わせでもキャッシュをクリアせずにキャッシュが有効になっている状態で再度abコマンド(ab -n 100 -c 10 http://jinkai.macaro.net)を実行すると0.372460秒など殆どの組み合わせで、0.36~0.37秒前後に収束した。つまり、1.8秒~3.9秒の大部分は、キャッシュされている状態でありabで求めたTime taken for tests:の時間のばらつきはキャッシュ作成時の最初の数回分のみでしかなく、何回キャッシュにヒットしたかが微妙にばらつく事で発生していることが判明した。

実際にはどの組み合わせでも大差ないが、Diskを使うとディスクアクセスが発生するデメリット(メモリが多ければ実際にはOSが制御するのでそれほど問題はない)、APCを使うとApache再起動時にキャッシュがクリアされてしまうことを勘案すると、私はすべてMemcachedに設定するのが最も効率的であると考えます。

wp super cache 0.9.7(gzip圧縮あり)+APCでテストしてみると、2.515151秒、2.208088秒、2.630919秒(毎回キャッシュクリア)、キャッシュをクリアせずに同じコマンドを発行すと、0.132580秒、0.121404秒、0.131634秒。単純にトップページのみの圧縮であればW3TCも、wp super cacheのもキャッシュ作成にかかる時間は大差なくキャッシュ済みコンテンツへのアクセスに関しては、wp super cacheの方が、W3TCより3倍近く高速で尚且つサーバ負荷低い。これはwp super cacheの方はmod_rewrite分のオーバーヘッドしかないのに対して、W3TCは条件判断が加わるので当然と言えば当然の結果。

wp super cacheに対して、W3TCが大きくアドバンテージを発揮するのは、データベースへのクエリが何パターンも発生する場合などだと思う。cssやjavascriptの圧縮は、自分でYUM compressorなどを使って実行しておくことも可能なわけで、Pageキャッシュは、wp super cacheの方が速いとなれば、その部分でしか、W3TCのメリットは出てこない(もちろん、W3TCはそれを自動でやってのけるので、そのメリットは大きいが、そんなに頻繁にCSSなどは変更するものではない)。

今回のパフォーマンステストはある意味、W3TCのメリットを全く生かしきれないもっとアクセスパターンが多様で、DBへのクエリに多様性が出るケースなどでテストすれば、W3TCの方が早くなる可能性が高いし、W3TCの方がアーキテクチャ的に伸び代が大きい。W3TCへの期待をこめる意味と、もう少し動作を調べたいので当面、このサイトではW3TCを使用していくことにします。

あと、W3TCの大きなメリットとして、wp super cacheのように完全に静的HTMLに落とし込んで、mod_rewriteでURLを書き換える方式ではないので、ktai styleのようなプラグインとバッティングしません。両方ともキャッシュが効いてるようです。(この部分はまだ詳しくテストしてないです)。(現在テストしていますが、タイミングによってはバッティングするようです、何らかのキャッシュ制御しないとだめかな?調査中です。11/10 追記)wp super cacheとktai styleの組み合わせは、ある意味クイックハック的な処置で実現していますよね。wp super cacheと相性の悪いプラグインもいくつか存在しますし、wp super chacheの静的なhtmlに落とし込んで、mod_rewriteでルーティングするやり方はWordpressの大きなメリットである柔軟性を損なう可能性が高いので、相性の悪いプラグインが出るたびにクイックハックでキャッシュ・ルーティング対象から外したり、場合によっては新しいルーチンを組むなど本質的な対応が面倒。その点、W3TCの方がアルゴリズム的に汎用性が高く、影響のでるラグインが少ないはずです。最初はなんでW3TCが旬なXcacheではなくAPCを採用したか、理解に苦しみましたが、結構その辺は難しい部分で、APCの方がよりシンプルで、Xcacheを使う場合は、phpの変数までキャッシュ可能なので、かなり複雑な制御をしないと色々と破綻しやすいんですね。もちろんその部分を煮詰めればXcacheの方が速いでしょうが、一筋縄ではいかないし、相性問題も発生しやすくなるはずです。

W3TCは非常に良くできています、感心します。素晴らしいプラグインを作ってくださった、Frederickさんに感謝。

WordPressページ処理ベンチマーク(100リクエストあたり)
PHP単体-(等倍)
PHP + APC1.32倍
APC + wp super Cache キャッシュ作成時11.21倍
APC + wp super Cache キャッシュ済み213.82倍
APC + W3 Total Cache キャッシュ作成時9.17倍
APC + W3 Total Cacheキャッシュ済み73.46倍
0 Comments on W3TCパフォーマンステスト

Respond | Trackback

Respond

Comments

Comments

Comments links could be nofollow free.


Performance Optimization WordPress Plugins by W3 EDGE