Nao さんが PHP カンファレンスの質疑の時に、「wordpress.com では memcached が使われている」ということを言われているのをふと思い出し、ためしにぼくも WordPress に memcached を適応してみようとやってみました。 
といっても memcached が動いているレンタルサーバはないと思いますので、実際に利用できるのは専用サーバ使われている人になるとおもいます。 ぼくはちょっとローカルで試してみただけですので、その辺はご容赦ください。。（笑）
とりあえず、memcached。
memcached は、汎用の分散型メモリキャッシュシステムである。
もともと Danga Interactive によって LiveJournal サービスのために開発されたが、現在は多数のサイトで利用されている。memcached は、データとオブジェクトをメモリ内にキャッシュすることでデータベースから読み出しを行う回数を減少させ、データベースを用いた Web サイトを高速化するために良く用いられる。memcached はpermissive free software licence によりライセンスされている。[1]
高スケーラブルが要求される、Web サービスでよくつかわれているメモリキャッシュの実装です。 たしか mixi も使っているとどこかで読んだきもします。
memcached の WordPress の適応範囲は、SQL のクエリキャッシュのような感じで使われ、MySQL への負荷をさげ、同一参照に関してはメモリ内のキャッシュを返すことで動作を速くすることです。
（注意） wordpress.com で実際に行っていることは分かりません。 おそらくは似たこともやっていると思いますが、いろいろ追加チューニングしていると思います。
ここで使ったのは WordPress コアに付加できるようになっている object-cache.php の一つで、以前をかもとさんが動かされていたファイルキャッシュの memcached 版ということになります。
WordPress サイトのパフォーマンスチューニング (4) : dogmap.jp
さて、前回、オブジェクトキャッシュの効率化に着手して、モノの見事に失敗した私ですが、File-Based Extension to the WordPress Object Cacheなるモノを発見。
DBアクセスせずにファイルアクセスで、済ませてしまおうという仕掛けです。
要はコレ、WordPress 2.5.x 以前にあったオブジェクトキャッシュを、2.5.x 以降のバージョンでも使えるようにしてしまおうというものです。
てなわけで、とりあえずローカルの Ubuntu に memcached をインストール。 これは簡単。
sudo apt-get install memcached
でもって、PHP に memcached クライアントをインストールします。 ぼくは Ubuntu の XAMPP なので以下のようにしてモジュールをコンパイルします。(xampp-dev とか gcc とか autoconf とかは事前に入れておくのこと）
モジュールは以下にあります。
memcache-2.2.5.tgz (35.1kB)
現時点 2.2.5 が stable だったのでこれをダウンロードしてどこかに展開。
ダウンロードしたソースフォルダに cd した後、
/opt/lampp/bin/phpize
./configure --enable-memcache --with-php-config=/opt/lampp/bin/php-config
make
sudo make install
sudo vi /opt/lampp/etc/php.ini
extension="memcache.so" ←行追加
sudo /opt/lampp/lampp restart
これでOKです。 Apache リスタート後、phpinfo で読まれていることを確認します。
できたら、object-cache.php をダウンロードして wp-content/object-cache.php に配置します。
ちなみに Authoer は、
Author: Ryan Boren
Ryan さんですね。
てなかんじで、これで準備完了です。
ローカルにおいてある .another のトップページを表示してみました。 まずは、一回目。
17 queries. 1.987 seconds.
これでキャッシュしたハズなのでもう一度トップにアクセス。
4 queries. 1.020 seconds.
ぶはは、４クエリ（笑）
ちなみにこのローカルは、PHP の debuger とかプロファイラ等いろいろいれていおり MySQL 以外の部分が元々遅く、ちゃんとチューンしたサーバをつかえば相当速い速度がでそうです。 あと MySQL の負荷が高いときにはさらなる威力を発揮するでしょう。
さて、一応いくつか動作確認はして大丈夫そうでしたが、まぁまぁキャッシュ技術の特性上不具合もでやすいと思いますので、もしも本番運用する方がいましたら老婆心ながら試験は十分に･･･。
プラグインから発行される SQL なんかは object-cache 対応していないものがおおいので、そのへんのチューニングも含めてアクセスの多いサイトでは試してみるのもおもしろいかもしれません。
) » Blog Archive » We Love WordPress in Susukino (番外編)
wp-jrelated 1.52 リリース (関連取得不具合修正)
WordPress Related Post for Japanese の 1.52 をリリースしました。
1.50 における Yahoo! API の URL 変更に伴うエントリポイントの変更で旧バージョンからアップデートしたさいに正しく URL が更新されない不具合の修正です。 条件にあたってしまった方は、現在関連がとれなくなってしまっていると思いますので、バージョンをあげていただければと思います（すいません）。
をかもとさんから先日いただいておりました、実体参照文字列がある場合のレスポンスで XML パースエラーがでる場合があった不具合の修正もマージさせていただいています。 ありがとうございました。
もし最近とれない記事があった場合はプラグインをアップデートした後に、管理画面から「閲覧時」にチェックをいれて、何度か該当記事のシングルページにアクセスしてみてください。 そのうち再取得されると思います。
尚、過去ログの関連がすべて取り終えている方は、ここのチェックをハズしておいた方がいいです。 処理的に 1 クエリー得します。
—-
以下余談。
先日から .another でも関連がとれなくなっていて、おかしいなぁとおもいつつ、他の方もとれていたりとれていなかったりで、原因がぱっと思いつかず困っていたのですが、今日重い腰を上げてみてみたところ、思いっきりバグってました。。 すいません。。
ぼくの管理画面付きのプラグインは、業務ロジックのオブジェクトをシリアライズしてそのまんま (wp_)options に保存して実装されているのが多いのですが（要はメンバがオプション値）、前回 URL のメンバ変数の初期設定を変えたときに、オブジェクト・アップデートロジックに URL の変更を忘れていたのが不具合の原因です。 とほほ。 （なので新規インストール時は大丈夫でした）
さて、このプラグインって投稿時のレスポンスを落とさないようにバックグラウンド非同期(wp-cron)で Yahoo! に問い合わせにいくようにしているのですが、解析に「重い腰」というのはここでした。
いつもならデバッガでブレイクして、鼻歌交じりに「あぁここ」と思って修正完了なのですが、非同期の場合は別セッションで動くためデバッガが使えないのです。 じゃーログファイルデバッグ、という手もあるのですがどうも wp-cron 中にあまりに長い処理を動かすと、PHP に途中でぶったぎられてしまうこともあるようでうまくありませんでした。
ということで、動機側に処理をまずもってくる。。 管理画面に post_id 指定でとれるよう項目を新設。
で、デバッグブレイク。
こんな感じで１行ずつ処理を追っていきます。 たまに変数を確認。
こんな感じでみれるでありますね。
PHP のデバッグについては、以前かきましたので興味のある方はどうぞ。
せっかくなのでPHP デバッグ (XDebug) のちょっとしたコツを。
WordPress の管理画面など cookie 認証を伴う場合に、デバッグセッションがうまくつながらなくてブレイクできない場合があります。 そんなときは以下のようにするととまってくれます。
まず、デバッガの設定でログイン前の画面にデバッグエントリポイントを指定します。 WP だとトップの index.php あたりに。
「File」の部分がワークスペース上のパスで、「URL」がブラウザでアクセスしたときのパスです。 ここの対応キモ。 あっていないとブレイクしないので、よく確認します。
で、デバッグスタートさせると WP のトップが表示されますが、このときブラウザに表示された URL の引数をどっかにコピペしておきます。
この ? 以降をとっておいた上で、WP の管理画面にログインして、ブレイクの張ってある画面にたどりつきます。 ブレイクしましたか？
もしもしなかったら、その画面の URL のおしりに上でとっておいた ? 以降の引数をつけてあげましょう。 これでとまるとおもいます。
動きしか見てないですが、たぶん WP の認証によりデバッグセッションの cookie がきえてしまうのがとまらない原因です。 なので GET でつけてあげて再設定すればこの後は何もしなくてもとまるようになります。
てなかんじでデバッガでウオッチしてたら、URL に古いエントリポイントがでてきたというかなり、とほほな結末でした。
なくしそうなので、管理画面から同期取得できるバージョンもおいておきます。 wp-jrelated/debug/ ディレクトリをつくっておくとログファイルもかくようにしています。 （ちゃんとバリデーションとかしてないので本番では使わないでください）
という感じでした。（←オチを考える元気がなかった