WordPress はユーザ数が多いだけに、必要なものはたいていプラグインとして用意されている非常に使いやすいCMSだと思いますが、毎回動的にしかページを作れないという点にはちょっと不満を持っていました。

nginx や Vernish などのプロキシサーバを別に立ててキャッシュさせる方法を試そうと思っていたのですが、はまりポイントが多いらしく躊躇していました。そんな時に Really Static というプラグインを見つけたときから、今回の話は始まります。

Really Static プラグインの問題点

Really Static プラグインは、ブログの記事の HTML を PHP の curl 関数でダウンロードして static フォルダの中に置いておき、それ以降は PHP で動的に HTML を作るのではなく、静的な HTML ファイルを返す、といった事をしてくれるプラグインです。ちょうど、Ruby on Rails のページキャッシュみたいなイメージですね。

インストールも設定も難しくなく、HTML のダウンロードも WP-cron で少しずつ行われるため、完全に WordPress 内に閉じた環境で実現できるすぐれたプラグインだと思いますが、（私にとっては）ひとつだけ大きな欠点がありました。

それは、Really Static プラグインがサイトの構造(URL)を変えてしまうことでした。
例えば、http://blog.bluegold.me/sample という URL の記事に対して、Really Static の導入後にアクセスすると http://blog.bluegold.me/static/sample.html に 301 redirect されてしまいます。
さらには他のページに書かれたリンクも静的ファイルの URL を直接さすように変更されてしまうので、一度導入してしまうと、後で使うのをやめるときに元に戻すのが難しくなってしまうのではないかと思いました。

最初は Really Static プラグインに手を入れて、リンクの URL を変更させないようにしようと思ったんですが、コードを読むと仕組みは意外と単純だったので、Wordpress に統合することを考えなければ、nginx の try_files だけで、似たようなことが出来ることに気がつきました。

nginx の機能を使う

nginx の try_files はリクエストを処理する際に実際のファイルを探す順番を記述する nginx に固有の設定項目で、Apache では mod_rewrite の複雑なルールを駆使して実現できるようなことをシンプルなルールで記述できるようにしたものです。

現在のこのブログの nginx.conf には以下のような記述がされています。

location {
  gzip_static on;
#  try_files /system/maintenance.html /static/$uri/index.html $uri /index.php?q=$uri&$args;
  try_files /system/maintenance.html /static/$uri/index.html$args $uri /index.php?q=$uri&$args;
}

具体的な設定は WordPress のパーマリンクの設定で変わります。
$uri にはリクエストされた URL のパスの部分が入っています。リクエストを処理する際は以下を順番に調べていって、最初に見つかったものを返します。

※ 2011/01/30 追記
静的HTML化した投稿を表す /static/$url/index.html には $args も付けておかないと、プレビューが出来ませんでしたので修正しました。

• メンテナンス画面(/system/maintenance.html)
• 今回追加した静的HTMLのキャッシュ
• css や画像などの静的ファイル
• それ以外は WordPress に処理を渡す

この設定だけで静的なHTMLファイルの配信は出来るようになります。

静的HTMLの作成

あとはブログの各記事を HTML としてダウンロードするだけです。

$ wget -r --follow-tags=a http://blog.bluegold.me

（あくまでも例なので、自分のサイト意外にはやらないでくださいね。）

静的HTMLに変換しておくことで、このくらい速くなりました。(それぞれ３回試行)

実はこのブログは WPtouch プラグインも使っているので、このままでは iPhone 用の画面が表示されません。
この対処法はまた次回。

URLの切替には自作のプラグインを使っています。記事にした当時は stylesheet_uri と template_directory_uri の置き換えをするだけのものでしたが、今は WP_PLUGIN_URL も置換えて、プラグインが追加するスタイルや画像も CloudFront から配信しています。

ここまではわりと簡単に実装できていたのですが、メディアライブラリ(uploads ディレクトリ)に置いた画像ファイルは記事の中身を書き換える必要があるため、なかなか手を出せずに1年くらい放置していましたが、最近、WordPress Amazon S3 Plugin というものがあるのを知り、さっそく試してみました。

このプラグインのセットアップは簡単で、plugins ディレクトリに置いて有効化したあとで、Amazon S3 の認証情報と画像を置くバケツ名を指定するだけです。

設定が完了した後はしばらく待っていると、wp-cron の仕組みを使い、誰かがアクセスしてきた時にバックグラウンドで画像ファイルを Amazon S3 にアップロードしていきます。(アップロードする画像はキューに入れられ、順番に処理されていくようです。)

画像ファイル毎に Amazon S3 へのアップロード状況が記録され、正常に保存された画像ファイルの URL は次回に表示される時から Amazon S3 の URL に置換えられます。

非常に簡単に使えて効果の高いプラグインなのですが、このブログの環境ではいくつか問題がありました。

画像ファイルが完全URLで指定されている事が想定されている。

このプラグインでは画像ファイルへの URL が http:// から始まる完全 URL で書かれている事を想定しているのですが、当ブログでは、ある記事では完全 URL、別の記事ではルート相対URL、という感じで記事ごとに画像の URL の書き方がバラバラでした。
このため、画像への URL を探す正規表現にマッチしない画像がたくさん出てきてしまいました。

メディアライブラリから画像を「投稿に挿入」していれば、完全URLで書かれるので普通に使っていれば問題は無かったはずなんですが。。。

しかたがないので、これはプラグインのソースに手を入れてルート相対URLでも書き換えられるように修正しました。

CloudFront の URL に対応していない。

このプラグインは画像ファイルのURLを http://>バケツ名<.s3.amazonaws.com という場所に変更するのですが、私のデータは Amazon S3 の中でも北米東海岸のサーバに置かれているため、ファイルの送信にちょっと時間がかかります。どうせなら国内の CloudFront のサーバから配信したいので、以下のようにソースを修正しました。wp-cdn.bluegold.me はヂストリビューションに付けた CNAME です。

*** 212,218 ****
  if (file_exists ( $mediaInfo [ 'cache' ] ) === TRUE) {
          $fileContents = file_get_contents ( $mediaInfo [ 'cache' ] );
          if ($fileContents == 'done') {
!           $cdnUrl = "http://{$this->s3BucketName}.s3.amazonaws.com/" . $mediaInfo [ 'path' ];
            $the_content = str_replace ( $mediaInfo [ 'url' ], $cdnUrl, $the_content );
          }
  } else {
--- 214,221 ----
 if (file_exists ( $mediaInfo [ 'cache' ] ) === TRUE) {
         $fileContents = file_get_contents ( $mediaInfo [ 'cache' ] );
         if ($fileContents == 'done') {
! //       $cdnUrl = "http://{$this->s3BucketName}.s3.amazonaws.com/" . $mediaInfo [ 'path' ];
!           $cdnUrl = "http://wp-cdn.bluegold.me/" . $mediaInfo [ 'path' ];
             $the_content = str_replace ( $mediaInfo [ 'url' ], $cdnUrl, $the_content );
         }
 } else {

このプラグインは非常に簡単に使えるので、Amazon S3 のアカウントを持っている人にはお勧めできますね。

このブログは今のところ自宅に置いてあるサーバで運用しています。
手直にあるので管理は簡単なのですが、自宅の回線はアップストリームの帯域幅が大きくないので、ページを表示するさいの画像読み込みの遅延が以前から気になっていました。

このサイトでは以下のように nginx を設定することで、可能な限り静的なコンテンツの使用する帯域幅を小さくしようとしていますが、それでもファイル転送量のほとんどは画像ファイルになっています。

location / {
    if (-f $request_filename) {
        expires 30d;
        break;
    }
}
location ~* ^.+\.(html|css|txt|tar|bmp|rtf|js)$ {
    gzip_static on;
    expires 30d;
}

以前から画像を外部のサイトに置いて転送負荷を減らそうと考え、一部の画像をflickrに置いたりしていますが、これはという解決策がありませんでした。

最近、仕事関係で Amazon のウェブサービスについて調べていてAmazon CloudFrontというサービスがあるのを知り、WordPress のテーマの画像を置いてみたらどうなるのかを調べてみました。

Amazon CloudFront は Amazon の提供するウェブサービスの１つで、いわゆるCDNです。Amazon S3に保存したファイルをインターネット上に分散配置されたキャッシュサーバに置く事で、静的なコンテンツを高速に配信する事ができるようになっています。

有料のサービスなので利用には Amazon Web Service のアカウントが必要になりますが、以下のように安価な価格設定になっているので費用対効果は高いと思います。

United States

$0.170 per GB – first 10 TB / month data transfer out

$0.010 per 10,000 GET Requests

Japan

$0.221 per GB – first 10 TB / month data transfer out

$0.013 per 10,000 GET Requests

Amazon S3 の使い方はいろんな場所で説明されているので省きます。使用しているテーマのディレクトリから画像や css, js ファイルを CloudFront に配備してください。
S3 に置いたファイル（オブジェクト）に対して Everyone の Read 権限を与える必要がある点だけ注意してください。
Firefox のプラグイン S3OrganizerはCloudFront にも対応しているのでお勧めです。

CloudFrontに置いたファイルをWordPressから参照する方法はテーマファイル次第ですが、私のサイトで作ってもらったテーマでは bloginfo(‘template_directory’); と bloginfo(‘stylesheet_url’); の２つの値を変更するだけで大丈夫そうでした。
私はWordPressもPHPも詳しくなく、この二つの値を変更する「正しい方法」が分からなかったため適当にプラグインを書いてみました。
（こうやって野良プラグインが増えていくんだろうな）

プラグインのソースは以下の通りです。

<?php
/*
 * Plugin Name: CloudFront
 * Plugin URI: http://blog.bluegold.me/cloudfront
 * CloudFront plugin is a plugin designed to help you drastically speed up your blog's load time by loading content onto Amazon CloudFront.
 * Version: 0.1
 * Author: Blog Bluegold.me
 * Author URI: http://blog.bluegold.me
 * */

$cdn_base = "__EDIT_HERE__";

function    filter_cdn_css($url) {
    global $cdn_base;
    return $cdn_base . "/style.css";
}

function    filter_cdn_template_dirctory($url) {
    global $cdn_base;
    return $cdn_base;
}

add_filter('stylesheet_uri','filter_cdn_css');
add_filter('template_directory_uri','filter_cdn_template_dirctory');
?>

これを WordPress の wp-content/plugins/cloudfront/cloudfront.php という名前で保存するだけです。

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 ディレクトリに置いて、しばらく悩みました。

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