「動かない」と言われた時は「後で書いておくよ」と軽い気持ちで答えてしまっていましたが、よく考えると XCache の管理ページなんてインストールした時に表示させただけで、その後はすぐに munin での監視を始めてしまったので、あまり記憶に残っていません。nginx 側で BASIC 認証を設定していたのが原因だったかで、うまく動かなくて苦労した記憶はあるのですが。（munin の設定については後述）

前に書いた記事で php.ini の設定を載せましたが、管理者の設定が抜けていました。

[xcache.admin]
xcache.admin.auth = On
xcache.admin.user = "admin"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = "d41d8cd98f00b204e9800998ecf8427e"

パスワードは MD5 でハッシュを計算しておく必要があります。
コードとしては下のような簡単なものですが、このURLでハッシュを計算するものを作ってみました。

<!--

http://blog.bluegold.me/pass.php?password=XXXX

XXX の部分にパスワードを入力します
-->
xcache.admin.pass = "<?php echo md5($REQUEST["password"]); ?>"

php.ini に管理者の設定を行った後で XCaxhe に付属の管理ページ(xcache.php)を開くと、パスワード認証をした後で管理ページが表示されると思います。

XCacheに付属の管理ページではキャッシュされているスクリプトや、使用メモリ、キャッシュヒットやキャッシュミスの回数などの基本的な情報を調べることはできますが、得られる情報はあくまでも「その時点」での情報でしかないので、キャッシュミスが増えているか等は分かりません。

このサイトでは munin を利用して XCache のキャッシュ状況をモニターしています。munin はサーバなどをモニタリングして統計画像を作るためのソフトで、この種のソフトとしては非常に簡単に設定を行うことができます。監視用のプラグインは比較的用意に作ることができ、既に多くのソフトウェアに対応しています。

XCache用のプラグインは標準ではインストールされていないので、ここから munin_xcache-0.2.tar.bz2 をダウンロードします。インストールは他のプラグインと同様に出来ますが、このプラグインは少し変わっていて「監視される側の php ファイル(munin_xcache.php)」 も一緒に入っています。こちらはウェブサーバーから見える場所においておく必要があります。

しばらくすると、このようなグラフが出来てきます。

6/16 の晩に WordPress 2.8 にアップグレードしたので、そこからキャッシュミスが多くなってきています。

複数の WordPress を１つのホストで稼働させる際に XCache Object Cache Plugin for WordPress 2.5+ を使用すると、オブジェクトキャッシュが混ざってしまうようです。

このサイトではhttp://blog.bluegold.me用とhttp://mama.bluegold.me用に２つの WordPress を稼働させています。それぞれ専用のデータベースを持つ独立したブログになっていますが、双方でオブジェクトキャッシュを有効にしたところ、しばらくして blog.bluegold.me 側の WordPress の管理コンソール(wp-admin)にログインできなくなりました。

XCache をインストールしてからは時間が経っていたので関係しているとは全く思わずに、MySQL 側でパスワードを何度も更新してログインを試みたり、WordPress 2.7.2 2.7.1 にバージョンを上げたばかりだったので、仕様が変わったのかと調べてみたりしたものの原因は分かりませんでした。

管理コンソールいろいろなIDとパスワードを入力しているうちに、blog.bluegold.me のユーザ名(bg)を入力すると「ユーザ名が違います」を表示されるのに、mama.bluegold.me 側のユーザ名(papa)を入力すると「パスワードが違います」と表示される事に気がつきました。ありえない事が起きているのが分かってきたので、試しにpapa の正しいパスワードを入力してみたところログインに成功し、bgのダッシュボードが表示されました。

ここでキャッシュが悪さをしている事がわかったので、オブジェクトキャッシュの使用を止めて、キャッシュをクリアするために PHP の FastCGI のプロセスを再起動しました。

調べてみると、やはり同じような問題を抱えている人はいるようで、以下のサイトに詳しく書かれていました。ユーザ情報が混在するのは仕様なんですかね．．．
http://jamescoletti.com/multiple-wordpress-installs-and-object-cache-collision

PHPアクセラレータにはeAcceleratorやAPCなどいろいろとあるようですが、今回は使った事のないXCacheを使ってみます。XCacheはバイトコードのキャッシュの他にPHPの変数をキャッシュする機能があるので、この機能をWordPressで使うように設定も行います。

XCacheのビルドは以下の通り簡単に行うことができます。

wget http://xcache.lighttpd.net/pub/Releases/1.2.2/xcache-1.2.2.tar.gz
gzip -dc xcache-1.2.2.tar.gz | tar xvf -
cd xcache-1.2.2
./configure --enable-xcache
make
make install

php.ini ファイルにXCacheの設定を記述します。
ソースに付属しているサンプルの xcache.ini からあまり変えていません。

[xcache-common]
zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xcache.so

[xcache]
xcache.shm_scheme =        "mmap"
xcache.size  =               22M
xcache.count =                 1
xcache.slots =                8K
xcache.ttl   =             86400
xcache.gc_interval =         600

xcache.var_size  =            2M
xcache.var_count =             1
xcache.var_slots =            8K
xcache.var_ttl   =             0
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300

xcache.test =                Off
xcache.readonly_protection = Off
xcache.mmap_path =    "/dev/zero"
xcache.coredump_directory =   ""
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =            On

xcache.size は使用するアプリケーションの種類によって調整した方がよいと思います。XCacheはeAcceleratorなどと違い、キャッシュは全てメモリ上に持つようなので大きめに設定しておいた方が良いかもしれません。

バイトコードのキャッシュは以上の設定でphpのFastCGIを再起動するだけで使用出来ますが、変数のキャッシュを利用するにはアプリケーション側で対応する必要があります。WordPressにはXCache for WordPressというプラグインがあるようですが、最近のバージョンのWordPressでは動作しないようなので、XCache Object Cache Plugin for WordPress 2.5+を使用する事にしました。

インストールは簡単ですが、XCache Object Cache Plugin for WordPressは通常のWordPressのプラグインとはインストールするパスが異なるので注意が必要です。プラグインのファイルは object-cache.php １つだけで、これをWordPressのコンテントディレクトリ（通常は xp-content ディレクトリ）に置きます。私も最初は説明を読まずに他のプラグインと同じように xp-content/plugins ディレクトリに置いて、しばらく悩みました。

このようにバイトコードと変数の双方がキャッシュされている事を確認出来ます。これだけで体感出来る程度には速度が向上するので、導入する価値はあると思います。