さて、前回、オブジェクトキャッシュの効率化に着手して、モノの見事に失敗した私ですが、File-Based Extension to the WordPress Object Cacheなるモノを発見。
DBアクセスせずにファイルアクセスで、済ませてしまおうという仕掛けです。
要はコレ、WordPress 2.5.x 以前にあったオブジェクトキャッシュを、2.5.x 以降のバージョンでも使えるようにしてしまおうというものです。

しかも、ご丁寧にも APC、XCache、eAccelerator などのPHP用の各種キャッシュモジュールが使える場合は、それ用のモノも用意してあります。
これらを利用すれば、オブジェクトキャッシュ情報をファイルに書き出すのではなく、PHP用の各種キャッシュモジュールが管理する変数キャッシュ領域にセットしてくれます。
SAKURA では PHP が CGIモードで動作しているため、PHP用の各種キャッシュモジュールがイマイチ使えないので、File-Based Extension… を導入してみました。
続きを読む →

さて、前回の続き。
すっかり query 数を減らすことに執着してしまった男が、冥府魔道に迷い込んでしまったお話。

他に減らせるコストは無いか？キャッシュできる情報は無いか？しばし黙考。
そうだ！オブジェクトキャッシュでキャッシュされているデータを取っておいて、次に呼び出された時にロードすれば
良いじゃないか？
と言うわけで、wp-settings.php を読んでいると、以下の記述を発見。

if ( file_exists(WP_CONTENT_DIR . '/object-cache.php') )
	require_once (WP_CONTENT_DIR . '/object-cache.php');
else
	require_once (ABSPATH . WPINC . '/cache.php');

おぉ！cache.php を改良して wp-content 直下に object-cache.php と言う名前で置いておけば良いのか。
これなら WordPress のコアコードに手をつけないでイケる。
バージョンアップ時も安心だ。

….これが冥府魔道の入り口だとは、その時は気づきませんでした。
続きを読む →

さて、昨日の続きです。

さて、さらにゴニョゴニョして、現在は

• トップページ　69 queries. → 34 queries.
• シングルページ　35 queries. → 23 queries.

になりました。
ゴニョゴニョの詳細は、また次回。

と言っておりましたので、そのゴニョゴニョの部分の説明。

一言で言えば、「投稿の付属情報のキャッシュをWebサーバにファイルとして持つ」プラグインを作りました。
まだまだ改良の余地は有りますが、とりあえず現状の状態で結構満足の行く仕上がりになってます。

このプラグインを稼動させ、キャッシュが作成された後の query数がこちら。

• トップページ　42 queries. → 34 queries.
• シングルページ　35 queries. → 23 queries.

確実に減ってますねぇ。いい感じです。
続きを読む →

過去にも何度かパフォーマンスチューニングを施してきたウチのサイトですが、まだまだトップページの表示が遅い。

ひょっとすると query 数が多いんじゃないか？とは思っていたのだが、あらためて他の WordPress で作成されたサイトと比較してみると、ウチのサイトは明らかに query 数が多い。
SAKURA のレンタルサーバでは、 MySQL サーバと Apache サーバが別のサーバなので、query 数が多いのは、パフォーマンス的に不利だ。
（参照：WordPressの不要なプラグインを外してチューニングする記事のメモ (blog@browncat.org)）

これは、なんとかせねばだ。と言うことで、プラグインを止めたり改良したり、結果をキャッシュに持ったりしてみました。
続きを読む →