W3 Total Cacheって実はヤバイのかも知れない
またもや最近WordPressの速度低下に悩んでいるlatexcatsuitです。
サーバを引っ越すまで散々高速化を計っていたものの大きな効果なく引越しを決断したのが昨年5月初め。
そして半年くらいは快適な速度で運用できていたにも拘わらず、
昨年12月くらいからまたもや目に見えて速度低下が激しくなり、
サーバのロードアベレージが目に見えて高い状態に陥ることが多くなりました。
記事数が1000を超え、一日のPVが1800〜2100PV、転送量が700〜800MBをうろちょろしている状態で
これは明らかにおかしいぞと検証を始めることとしました。
使用しているのはさくらのレンタルサーバスタンダードプラン。
そして高速化の為に導入していたプラグインは以下のとおり。
の4つ。
最近流行の構成といっても差し支えないものしか使っていませんでした。
ところが。
こんな感じで、頻繁にロードアベレージが高くなることがわかりました。
共用サーバのため、他の同居人がなにか重い処理をしているのだろうとタカをくくっていたところ、
なんと自分がそのサーバリソースの多くを使用しているとの指摘が・・・。
これはいかんとW3 Total Cache（以下W3TCと略します）定期的に動作しているCache Preloadに着目しました。
これです。
この設定では、1時間ごとに20ページのキャッシュを生成するようにしていましたが、これを停止。
数日ほど様子を見ていたのですが、それでもロードアベレージが目に見えて落ちず、
まさかと思いW3TCを停止してみたところ、キャッシュが動作していないにも拘わらずそこそこ快適なスピードが！
そうです、
高速化のために導入したW3TCが実は速度低下の原因の１つ
だったのです。
これは盲点でした。
痒いところに手が届く至れり尽くせりのW3TCですが、サーバリソースが潤沢でないと実は相当厳しいプラグインだったのです。
いろいろと調べてみますと、次のような記事に行き当たりました。
W3 Total Cacheを使ってレスポンス速くなって喜んでたらひどい目にあった
なるほど、至れり尽くせりだけに調子に乗って色んなオプションを使用すると大変なことになりますよ、ってことですね。
ですが、WordPressを使っていてキャッシュプラグインを使用しない手はないので、次に何を使うか。
選んだのはQuick Cache。
なんでもかの有名なWP Super Cacheの後継・後発？のものだそうで、
簡単な設定のみで使用出来るっていうのがウリです。
導入にあたり参考にしたのは次のサイトです。
WordPressを高速化させるプラグイン 「Quick Cache」インストールと設定
たった1行でケータイやスマホ用ページを高速化するQuick CacheのTips
早速使用してみると、これが爆速。驚きました。
爆速という言葉が適当でないなら、相当のスピードアップ（当社比）。
これは使わない手はないとばかりに、ひとまずこれを使用することを前提で環境を整備することとしました。
手始めにW3TCでは標準機能だったmod_expires (静的ファイルの有効期限設定）周りを設定。
htaccessに以下の記述を追加。
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 10 minutes" ExpiresByType image/gif "access plus 1 weeks" ExpiresByType image/png "access plus 1 weeks" ExpiresByType image/jpg "access plus 1 weeks" ExpiresByType image/jpeg "access plus 1 weeks" ExpiresByType text/html "access plus 2 minutes" ExpiresByType text/css "access plus 2 weeks" ExpiresByType text/javascript "access plus 2 weekss" ExpiresByType application/x-javascript "access plus 2 weeks" </IfModule>
次いでW3TCで使用していたGZIP圧縮をphp.iniに次を記述することでこれを復活。
zlib.output_compression=on zlib.output_compression_level=2
さらに翻訳ファイルのキャッシュ。
これまではMO Cacheを使用していましたが、
心機一転以前少しだけ使用していた001 Prime Strategy Translate Acceleratorへと変更。
最後にHead Cleanerの設定再検証。
実はこれもちょっとした問題がありました。
W3TC使用時の設定のままでは一部に表示崩れなどが発生しました。
JS/CSSがGZIP圧縮できるのは魅力的だったのですが、ここはしょうがないと諦めました。
ここまでで、およそ以前W3TCで設定していたのとほぼ同じことを準備できたことになりますが、
その速度はやはり速い！段違いです。
ついでにちょっとした発見もありました。
W3TCの現行バージョン0.9.2.5には、cron関係のバグがある
ということです。
例えば予約投稿の失敗、WP DB Managerを使用しての自動バックアップの失敗です。
W3TCのサポートフォーラムでも話題に上っているほどのバグだそうで、
様々な解決法が提示されていますが、プラグインとしてのバグ修正はまだのようですが
いずれにしても怖いですよね・・・。
というわけで、過去のエントリーにもW3TCが重いと触れていましたが、
やっぱり共用サーバレベルで使用するのは厳しいんでしょうね。
ひとまずこのままで様子見をして、なにかあればまたご報告したいと思います。
ほんと、高速化は一日にしてならずですｗ
