節電だるいねー(´・ω・`)

さくらVPSとnginxリバースプロクシで最速WordPressブログを作る方法（ベンチマーク付き）

nginx,WordPress — タグ: , — さくら @ 2011/09/07 15:07
このエントリーをはてなブックマークに追加

負荷的に厳しくなってきたので sakuratan.biz を Apache（さくらスタンダード）から nginx（さくら VPS 512）に移転しました。
頻発していた 503 もほとんど出なくなって快適です。

Apache から VPS の nginx へ WordPress を移転したいと考えている人もいるかなーと思いましたで、さくら VPS で nginx リバースプロクシを使った WordPress ブログの構築する方法をがっつり書いていきたいと思います。

結構長文になってしまいましたので、先に索引を載せときます。

  1. nginx とは
  2. nginx が速い理由
  3. リバースプロクシ
  4. さくら VPS にインストールするシステム構成
  5. EPEL パッケージリポジトリのインストール
  6. MySQL のインストール
  7. PHP のインストール
  8. nginx のインストール
  9. nginx と PHP FastCGI の設定
  10. WordPress のインストール
  11. Nginx Proxy Cache Purge WordPress プラグインのインストール
  12. ベンチマーク
  13. 参考サイト

nginx が速い速いとだけ言われてもいまいち腑に落ちない方もいらっしゃるかと思いましたので、最初の方の章は nginx 自体の説明にしました。前置きは置いといてとりあえずインストール方法を知りたい方は、『さくら VPS にインストールするシステム構成』あたりからどうぞ。ちなみにさくら VPS は CentOS ですので、他のレン鯖でも OS が同じなら同じ手順でインスコできると思います。

サンプルのファイルをまとめた zip を nginx-examples.zip に置いてますので、とりあえずファイルだけ欲しいって人はこちらをどうぞ。

あと、なんとなくあった方が良いかなーと思いまして Apache と nginx のベンチマークもしてみました。結果の方は最後の方に載せてますが、結論だけ言えば nginx は多い日も安心のロリエセーフティロング高性能です。

nginx とは

まず最初に nginx の wiki から引用します。

Nginxはその高いパフォーマンスと安定性、豊富な機能、設定の容易さ、消費リソースの低さで知られています。

NginxはC10K問題に取り組むべく開発された一握りのサーバのうちの一つです。従来のサーバとは異なり、Nginxはリクエストの処理をスレッドに依存していません。その代わりにもっとスケーラブルな（非同期の）イベント駆動アーキテクチャを使用しています。このアーキテクチャはメモリ使用量が少ないだけでなく、最も重要な事として、稼働時のメモリ使用量が予測可能であるということです。

http://wiki.nginx.org/NginxJa

C10K問題とは、ハードウェアは安くなって大量のクライアントを同時処理できるようになったけど、OS やサーバプログラムの実装がボトルネックになってて1万（=10K）クライアント以上は処理できない(*´・ω・)(・ω・｀*)ﾈｰ、という問題です。（Web2.0の先にあるC10K問題 － ＠IT の説明が分かりやすいと思いますので詳しく知りたい方はどうぞ。）

上の概要に書いてますが、nginx はC10K問題を解決すべく作られた新しいウェブサーバですので、Apache 等の従来からあるウェブサーバと比べて本質的にスケーラブルなシステムとなっています。

nginx が速い理由

開発されてる方でしたら、nginx が速いと言う話をどこかで聞いた事があるかと思います。

実際のところ nginx が速いと言うよりも、nginx は Apache などの従来のサーバと比べ少ないリソースで複数の HTTP リクエストを処理できるように設計されているため、サーバが負荷の高い状態になっても性能が劣化しにくい、と言うのがより正確だと思います。

ということで、nginx が高負荷状態に強い仕組みについて簡単に説明しようと思います。

nginx では外部からのネットワークコネクションを受け付けるプロセスをマスタープロセス、HTTP リクエストに対するレスポンスを返すプロセスをワーカープロセスと呼びます。マスタープロセスはコネクションを受け取ると稼働中のワーカープロセスのいずれかに HTTP レスポンスを返す処理を行うよう指示します。（マスター／ワーカープロセス構成自体は TCP/IP ベースの Unix daemon の一般的な構成ですので速い理由と関係ありません。）

nginx のワーカープロセスは（kqueue (FreeBSD 4.1以降)／epoll (Linux 2.6以降) などのカーネルによって異なる）非同期 I/O 通知メソッドを使い、複数のリクエスト／レスポンスを一つのプロセスで平行して同時に処理します。

一方、Apache などの従来のウェブサーバでは、リクエストを応答するプロセスは同期 I/O を使います。同期 I/O を使うと一つのワーカープロセスは複数の HTTP リクエストを同時に処理することができません。複数の HTTP リクエストを処理する場合は、先行するリクエストが完了するのを待って順次処理していきます。

Apache の場合、サーバにアクセスが集中し応答すべきリクエストが増えてきて、既に起動しているワーカープロセスだけでは処理が追いつかなくなると、新しいワーカープロセスを起動したり／新しいワーカープロセスを起動できない場合応答中のレスポンスの完了を待ってからリクエスト処理を開始することになります。

ワーカープロセスはそれぞれある程度のメモリを使用しますので、システムリソースから決まる同時応答可能な上限を越えると（スラッシングが発生するなどの原因で）ウェブサーバ全体の性能が急激に悪化します。（MPM worker を使って Apache をマルチスレッドで動かす場合も、1スレッドに対してそれなりのシステムリソースが必要となりますので、高負荷状態においてこの問題はそれほど改善しないです。）

それに対して nginx の場合、非同期 I/O を使って一つ（設定により増やせますがあくまで少数）のワーカープロセスですべてのリクエストを処理するよう設計されいます。必要なシステムリソースが少ないので、Apache では性能が悪化する局面でも極端に性能が悪化しません。なので nginx は速い、ということになります。

ちなみにワーカープロセスが行うレスポンス処理については Apache と nginx で特に性能に差がある訳ではありませんので、1リクエスト当たりの実処理時間はだいたい同じです。（一部のベンチマークではレスポンス自体は nginx の方が遅いという数字が出ていますが、自分のサイトで測った限りでは意味のある差はでませんでした。いずれにしても今時のサーバだと、ワーカープロセスの性能の優劣は特に気にする必要はないと思います。）

　_______________________
　　　　　＜○√　　くそっもうだめか・・!!
　　　　　 くく　　　リクエストが多すぎる、Apacheでは処理しきれない・・・
　________________________________
　　　　　　　　~|
　　　　　　　　　＼○　　　　大丈夫か？BOY
　　　　　 　 　　　 ∥＼
　　　<○>　　　　 ∥／
　　　 ∥　　　　／ |
　　 　>>　　　　＼ |
　nginxさん！！

リバースプロクシ

リバースプロクシとは、ざっくり言いますとウェブサーバをまるごとキャッシュする機能です。

WordPress などを動かす場合、アプリケーションを実行する部分がウェブサーバのボトルネックとなります。このボトルネックを解消するために、WP Super Cache などのアプリケーションレベルでのキャッシュや mod_cache などのウェブサーバレベルでのキャッシュがありますがウェブサーバと別にリバースプロクシサーバを用意しプロクシサーバがキャッシュを行うという解決方法もあります。

リバースプロクシを加えたウェブサーバの処理は下図のようになります。

リバースプロクシサーバがフロントエンドとなり、80 番ポートで外部からの HTTP リクエストを受け取ります。
リクエストされた URL がキャッシュされていれば、プロクシサーバはキャッシュ済みのレスポンスを返します。
キャッシュされていなければウェブサーバへリクエストを転送し、レスポンスをキャッシュして返します。

プロクシサーバには PHP スクリプトを実行する機能などは不要ですので、通常ウェブサーバよりも高速に動くよう実装されています。システム構成にリバースプロクシを加えることで全体での処理能力が高くなります。

nginx をリバースプロクシにする場合、リバースプロクシの設定が簡単なので（一つの設定ファイルにフロントエンドのプロクシサーバとバックエンドのウェブサーバの設定を記述できます）、とりあえずリバースプロクシも立てとけって感じです。

ちなみに、nginx をリバースプロクシに、バックエンドのウェブサーバは元から動いていた Apache そのまま、といった構成も可能です。VPS（特にさくら VPS 512）ではメモリサイズ的にこの構成は少し厳しいと思いますが、リソースにある程度余裕がある状況では費用対効果の高い性能改善策になると思います。

さくら VPS にインストールするシステム構成

ということで、nginx 自体の説明はこの辺にして、さくら VPS で nginx リバースプロクシを有効にした WordPress ブログのインストール方法について説明していきたいと思います。

まずさくら VPS のデフォルト OS は CentOS でして、OS はそのまま使う設定で話を進めます（VPS に Debian 入れたりする人は nginx の How To 記事なんか見なくても自分で設定できると思いますし）。CentOS ならさくら VPS 以外のサーバでもだいたい同じような手順でインスコできると思います（プレインストールされている yum パッケージの構成やバージョンが違う場合、一部異なる手順になるかもしれませんが）。

インストールするシステム構成はこんな感じです。リバースプロクシ／ウェブサーバともに nginx を使います。nginx には PHP を実行する機能がありませんので、FastCGI サーバとして PHP を実行します。

  • nginx 1.0.6 + Cache Purge plugin
  • PHP 5.3.3 + FastCGI + eAccelerator
  • MySQL 5.0.77
  • WordPress 3.2.1-ja

MySQL は yum のパッケージから普通にインスコします。

PHP は最近 yum に追加されたっぽい php53 パッケージを使います。eAccelerator があった方が良いのですが、php53 系列には eAccelerator のパッケージが無いのでこれだけソースからインスコします。

nginx はソースからビルドしてインスコします。nginx のパッケージが EPEL リポジトリにあるのですが、WordPress を動かす場合パッケージ版の nginx には含まれていない Cache Purge プラグインが欲しいので、パッケージは使いません。（nginx にプラグインを追加する場合はビルド時に組み込む必要があります。）

以下、EPEL のインスコ、MySQL インスコ／起動、PHP インスコ、nginx インスコ、nginx / PHP FastCGI の設定、WordPress インスコ…みたいな順番で書いてます。知ってるところは適当に読み飛ばしてください。

特に明記しない場合すべて root で作業を行う前提で書いています。まずサーバにログインして su するか sudo してください。

EPEL パッケージリポジトリのインストール

最初に EPEL パッケージをインスコします。EPEL の公式サイト から epel-release-5-4.noarch.rpm をダウンロードして rpm コマンドでインスコします。（EPEL 6 系列は CentOS にはインストールできませんので epel-release-5-4.noarch.rpm もしくはバージョン 5 系列の最新版をインストールしてください。）

wget http://download.fedoraproject.org/pub/epel/6/i386/epel-release-5-4.noarch.rpm
rpm -Uvh epel-release-5-4.noarch.rpm

EPEL パッケージのインスコ方法も含めて、yum 関係で VPS を借りたら最初にしといた方が良い作業が ウェブ開発者のための、1時間でできるLAMP環境構築術（CentOS編） – さくらインターネット創業日記に書かれてますので、よく分からない人はまずはこちらをご覧ください。

MySQL のインストール

MySQL は yum パッケージをインスコします。

yum install mysql mysql-server

インスコしたらサーバを起動し、chkconfig でリブート時に MySQL サーバが立ち上がるように設定します。

/etc/init.d/mysqld start
/sbin/chkconfig --level 345 mysqld on

PHP のインストール

yum から php53 パッケージをインスコし、eAccellaretor だけソースからビルドします。

yum install php53 php53-cli php53-xml php53-mysql php53-mbstring php53-devel

php53-xml は要らないような気もしますが検証するの忘れてましたのでとりあえずインストールするということで。

PHP をインスコできたら、eAccellaretor のソースコードを SourceForge からダウンロードして展開します。（eAccellaretor のビルド作業については、make install 以外は一般ユーザーで作業しても問題ないです。）

wget http://downloads.sourceforge.net/sourceforge/eaccelerator/eaccelerator-0.9.6.1.zip
unzip eaccelerator-0.9.6.1.zip

ビルドしてインスコします。

cd eaccelerator-0.9.6.1
phpize
./configure --enable-eaccelerator
make
make install

make install で /usr/lib64/php/modules に eaccelerator.so がコピーされますので、/etc/php.ini の extension に eaccelerator.so を追加します。

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;

extension=eaccelerator.so

デフォルトでは eaccelerator.cache_dir が /tmp/eaccelerator になっていますが個人的に /var/tmp 以下にしたいので、php.ini の末尾に以下の設定を加えます。デフォルトで問題ない場合はそのままでどうぞ。

[eAccelerator]
eaccelerator.cache_dir = "/var/tmp/eaccelerator"

eaccelerator.cache_dir を作ります。パーミッションはサーバによって適当に変えてください。

mkdir -p /var/tmp/eaccelerator
chmod 777 /var/tmp/eaccelerator

nginx のインストール

nginx をソースからビルドするため、ビルドと実行に必要な yum パッケージをインスコします。

yum --enablerepo=epel install make automake gcc gcc-c++ rpm-build spawn-fcgi \
pcre-devel zlib-devel openssl-devel libxslt-devel GeoIP-devel gd-devel

スクラッチからビルドすると init.d のスクリプト等を用意しないといけないので、nginx のソースパッケージ (SRPM) をダウンロードしてから、最新版の nginx を Cache Purge Plugin 付きでビルドするように nginx.spec を書き換えます。

まず EPEL 配布サイトから nginx の SRPM nginx-0.8.54-1.el5.src.rpm をダウンロードします。

wget http://download.fedora.redhat.com/pub/epel/5/SRPMS/nginx-0.8.54-1.el5.src.rpm

SRPM は rpm コマンドでインスコします。/usr/src/redhat/SPEC に nginx.conf が、/usr/src/redhat/SOURCES に SRPM に含まれるファイルが展開されます。

rpm -ivh nginx-0.8.54-1.el5.src.rpm

rpm -ivh を実行する際に mockbuild ユーザーが存在しないためワーニングが出ますが無視して問題ないです。

SRPM をインスコできたら、/usr/src/redhat/SOURCES に最新版の nginx と Cache Purge plugin をダウンロードします。

cd /usr/src/redhat/SOURCES
wget http://nginx.org/download/nginx-1.0.6.tar.gz
wget http://labs.frickle.com/files/ngx_cache_purge-1.3.tar.gz

nginx-1.0.6 で Cache Purge を有効にした nginx.spec を nginx.spec に置いてますので /usr/src/redhat/SPECS ディレクトリにダウンロードしてからビルドします。

cd /usr/src/redhat/SPECS
mv nginx.spec nginx.spec.orig
wget http://sakuratan.biz/nginx/nginx.spec
rpmbuild -bb nginx.spec

ビルドが終われば /usr/src/redhat/RPMS/x86_64 に nginx-1.0.6-1.x86_64.rpm が作成されますので rpm コマンドでインスコします。

rpm -Uvh /usr/src/redhat/RPMS/x86_64/nginx-1.0.6-1.x86_64.rpm

nginx と PHP FastCGI の設定

必要なものがインスコできたら nginx の設定をしていきます。

PHP FastCGI サーバ起動用スクリプトの作成

FastCGI サーバとして PHP を起動するためのスクリプトを php-fastcgi に置いていますので、ダウンロードしてから /etc/init.d に置きます。

wget http://sakuratan.biz/nginx/php-fastcgi
mv php-fastcgi /etc/init.d
chmod 755 /etc/init.d/php-fastcgi

PHP FastCGI サーバの実行ユーザー等を変更する場合は、php-fastcgi スクリプトの以下の箇所を変更してください。なお、以下の説明では 9000 番ポート上で PHP FastCGI サーバを起動する設定で例示しています。また、FastCGI サーバとの通信に TCP/IP ではなく Unix ドメインソケットを使用したい場合は php-fastcgi の spawn-fcgi の起動方法を変更してください（変更方法は各自で調べてください）。

user=nginx
group=nginx
host=127.0.0.1
port=9000
pidfile=/var/run/nginx/php-fastcgi.pid
numclients=5

pidfile を作成するディレクトリは、PHP FastCGI サーバの実行ユーザー（変更しなければ nginx）から書き込める必要がありますので、php-fastcgi スクリプトをデフォルトのまま使う場合は予め /var/run/nginx ディレクトリを作成する必要があります。

mkdir /var/run/nginx
chown nginx:nginx /var/run/nginx

以上の作業が終われば、とりあえず php-fastcgi を起動してみます。

/etc/init.d/php-fastcgi start

エラーが出る場合は設定を確認してください。

nginx.conf の修正

/etc/nginx/nginx.conf にリバースプロクシとバックエンドウェブサーバと PHP FastCGI サーバの設定を追加します。ちょっと長いですが全部貼ります。サーバにファイルを置いてますのでコピペして使いたい方は nginx.conf をどうぞ。

user              nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;

    keepalive_timeout  5;

    gzip  on;
    gzip_disable "MSIE [1-6]\.";

    proxy_cache_path  /var/cache/nginx levels=1:2 keys_zone=czone:4m max_size=50m inactive=120m;
    proxy_temp_path   /var/tmp/nginx;
    proxy_cache_key   "$scheme://$host$request_uri";
    proxy_set_header  Host               $host;
    proxy_set_header  X-Real-IP          $remote_addr;
    proxy_set_header  X-Forwarded-Host   $host;
    proxy_set_header  X-Forwarded-Server $host;
    proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;

    upstream backend {
        ip_hash;
        server 127.0.0.1:8080;
    }

    server {
        listen       80;
        server_name  example.com;

        location / {
            if ($http_user_agent ~* '(DoCoMo|J-PHONE|Vodafone|MOT-|UP\.Browser|DDIPOCKET|ASTEL|PDXGW|Palmscape|Xiino|sharp pda browser|Windows CE|L-mode|WILLCOM|SoftBank|Semulator|Vemulator|J-EMULATOR|emobile|mixi-mobile-converter)') {
                set $mobile 1;
            }
            if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFront|PSP|BlackBerry)') {
                set $mobile 2;
            }
            if ($http_cookie ~* "comment_author_[^=]*=([^%]+)%7C|wordpress_logged_in_[^=]*=([^%]+)%7C") {
                set $do_not_cache 1;
            }
            proxy_no_cache     $do_not_cache;
            proxy_cache_bypass $do_not_cache;
            proxy_cache czone;
            proxy_cache_key "$scheme://$host$request_uri$is_args$args$mobile";
            proxy_cache_valid  200 301 302 10m;
            proxy_cache_valid  404 5m;
            proxy_cache_use_stale  error timeout invalid_header updating
                                   http_500 http_502 http_503 http_504;
            proxy_pass http://backend;
            proxy_redirect http://example.com:8080/ /;
        }

        location ~ /purge(/.*) {
            allow 127.0.0.1;
            allow 192.0.2.1;
            deny all;
            proxy_cache_purge czone "$scheme://$host$1$is_args$args$mobile";
        }
    }

    server {
        listen       8080;
        server_name  example.com;

        location / {
            root   /var/www/html;
            index  index.html index.htm index.php;
        }

        error_page  404              /404.html;
        location = /404.html {
            root   /usr/share/nginx/html;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }

        location ~ \.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
            include        fastcgi_params;
        }

        location ~ /\.ht {
            deny  all;
        }
    }

    # Load config files from the /etc/nginx/conf.d directory
    include /etc/nginx/conf.d/*.conf;
}

この設定ファイルは以下のサーバ環境用に設定しています。サーバ環境に応じて適宜修正してください。

  • サーバの IP アドレス: 192.0.2.1
  • ホスト名: example.com
  • HTML ドキュメントルート: /var/www/html
  • リバースプロクシのポート: 80
  • バックエンドウェブサーバのポート: 8080
  • PHP FastCGI サーバのポート: 9000

ドキュメントルートに対して nginx ユーザーから読み込み権限が必要になります。WordPress を使用する場合ウェブディレクトリに対して書き込み権限も必要ですので、ドキュメントルートのオーナーを nginx ユーザー（FastCGI の実行ユーザー）に変更しておく方が良いかもしれません。

リバースプロクシのキャッシュを PC と携帯とスマートフォンで切り替える設定を入れています。不要な方は location / の設定を以下のように変更してください。Ktai Style や WPTouch を使う場合はそのままで。

        location / {
            proxy_no_cache     $do_not_cache;
            proxy_cache_bypass $do_not_cache;
            proxy_cache czone;
            proxy_cache_key "$scheme://$host$request_uri$is_args$args";
            proxy_cache_valid  200 301 302 10m;
            proxy_cache_valid  404 5m;
            proxy_cache_use_stale  error timeout invalid_header updating
                                   http_500 http_502 http_503 http_504;
            proxy_pass http://backend;
            proxy_redirect http://example.com:8080/ /;
        }

設定ファイルを自分の環境用に書き換えたら nginx を動かします。

/etc/init.d/nginx start

この状態でブラウザからホストにアクセスすると 403 Forbidden が表示されると思います。

ドキュメントルートに空のファイルを作成し、ブラウザでアクセスできるか確認します。

cp /dev/null /var/www/html/index.html

同じく phpinfo を実行するスクリプトを作成し、ブラウザでアクセスできるか確認します。

echo '<?php phpinfo() ?>' > /var/www/html/phpinfo.php

動作が確認できたら index.html と phpinfo.php を削除し（残してても良いですけど）、chkconfig を実行してリブート時に nginx と PHP FastCGI サーバが起動するように設定します。

/sbin/chkconfig --level 345 nginx on
/sbin/chkconfig --level 345 php-fastcgi on

WordPress のインストール

PHP の動作が確認できれば、WordPress のインストール自体は Apache の場合とそれほど違いません。

まず VPS ですので mysql コマンドでデータベースを作ります。

CREATE DATABASE wordpress DEFAULT charset utf8;
GRANT ALL ON wordpress.* TO 'wpuser'@'localhost' IDENTIFIED BY 'password';

ja.wordpress.org から最新版の WordPress をダウンロードして /var/www/nginx に展開します。

cd /var/www/nginx
wget http://ja.wordpress.org/latest-ja.zip
unzip /tmp/latest-ja.zip
chown -R nginx:nginx wordpress

wordpress ディレクトリの wp-config-sample.php を wp-config.php にコピーし、

cd wordpress
cp wp-config-sample.php wp-config.php

wp-config.php にデータベース設定と FS_METHOD を追加します。FS_METHOD を direct にすると、WordPress プラグインなどのダウンロード時に ftp を使用せず PHP スクリプトから直接ダウンロードするようになります。必須ではありませんが、VPS で ftp の設定をわざわざするのも面倒なので付けてます。

define('DB_NAME', 'wordpress');
define('DB_USER', 'wpuser');
define('DB_PASSWORD', 'password');
define('FS_METHOD', 'direct');

WordPress の設定が終わったら、ブラウザでアクセスする前に、/wordpress/wp-admin へのアクセスをキャッシュしないよう nginx.conf のリバースプロクシの設定を変更します。（この修正を入れた nginx.conf を nginx-wordpress.conf に置いています。）

    server {
        listen       80;
        server_name  example.com;

        location /wordpress/wp-admin/ {
            proxy_pass http://backend;
        }

        location / {

nginx.conf を修正したらリブートします。

/etc/init.d/nginx restart

これでブラウザから http://example.com/wordpress/ などのインストールした URL にアクセスすると WordPress のインストーラが立ち上がります。

パーマリンクの変更

パーマリンクを /wordpress/archives/1 等の形式に変更する場合、WordPress の設定を変える前に nginx.conf のバックエンドサーバの設定を変更する必要があります。

WordPress のインストール先が /wordpress/ で、/wordpress/ 以下のみを WordPress として運用する場合（トップページを WordPress に割り当てない）は、以下のように nginx.conf の location / に if (!-f $request_filename) { } を加え、location /wordpress を加えます。

    server {
        listen       8080;
        server_name  example.com;

        location / {
            root   /var/www/nginx;
            index  index.html index.htm index.php;
            if (-f $request_filename) {
                break;
            }
        }

        location /wordpress {
            root   /var/www/nginx;
            index  index.html index.htm index.php;
            if (!-e $request_filename) {
                rewrite ^(.+)$  /wordpress/index.php?q=$1 last;
            }
        }

設定を変更したら nginx をリブートします。

/etc/init.d/nginx restart

nginx をリブートしたら WordPress のパーマリンク設定を変更します。

パーマリンクの変更（WordPress ディレクトリとは別のディレクトリにサイトのホームページを設定する場合）

なにを言ってるかよく分からないかもしれませんが、WordPress の一般設定で以下のキャプチャのように WordPress のアドレス (URL) とサイトのアドレス (URL) を変えた場合に、パーマリンクの変更を行うための設定方法です。

この設定を行う場合、まず wordpress/index.php をコピーして HTML ドキュメントルートに index.php を作ります。

cd /var/www/html
cp wordprses/index.php index.php

コピーした index.php の require 部分を以下のように書き換えます。

require('./wordpress/wp-blog-header.php');

nginx.conf のバックエンドサーバの設定を書き換えてから、nginx をリブートします。

    server {
        listen       8080;
        server_name  example.com;

        location / {
            root   /var/www/nginx;
            index  index.html index.htm index.php;
            if (-f $request_filename) {
                break;
            }
            if (!-e $request_filename) {
                rewrite ^(.+)$  /index.php?q=$1 last;
            }
        }

nginx をリブートが完了したら WordPress のパーマリンク設定を変更してください。

Nginx Proxy Cache Purge WordPress プラグインのインストール

WordPress のインスコが終わったら Nginx Proxy Cache Purge WordPress プラグインを入れます。普通に WordPress のダッシュボードからインスコしてください。

このプラグインを入れると、記事を更新した際に nginx のキャッシュがパルスのファルシのルシがパージされるようになります。このプラグインを入れないと nginx のキャッシュタイムアウトまでの間（上の設定だと10分）古い内容で表示されることになりますので、nginx でリバースプロクシ立てたサイトで WordPress を動かすときは一緒にインスコしておいた方が良いです。

ちなみにこのプラグイン、パージ URL が /purge/* 固定（上の nginx の設定はこれに合わせています）でソースコード中にハードコーディングされていますので、パージ URLを変更したい場合はプラグインのソースを書き換える必要があります。上の nginx の設定例ではパージ URL を /purge にしてますので書き換えなくても問題ありませんが、変更したい場合はちょっと不便かもです。

nginx purge とかで WordPress プラグインを検索すると、他にも nginx のキャッシュをパージするためのエナがチャンガしてるプラグインが何個かありますので、他に良さげなのがあればそちらをどうぞ。

ちなみに、リバースプロクシでキャッシュしている場合は WP Super Cache 等のキャッシュプラグインは要りませんので、他のサイトから移行してきた場合キャッシュ関係のプラグインは無効または削除した方が良いと思います。

ベンチマーク

画竜点睛を欠くふいんき（なぜかry）でしたので、さくら VPS 512 上で httperf でWordPress のベンチマークを取ってみました。ついでにさくらスタンダードの WordPress に対してもベンチマークを取っていますが、こちらはサーバ環境が違いすぎるのであくまでも参考値ということで。

VPS の Apache はほぼデフォルトの設定／VPS の nginx はリバースプロクシありの設定ですので、ぶっちゃけフェアな比較ではありませんがまあこんなもんだと思います。（Apache の mod_cache を有効にするとか性能的な対策が可能ですが、別の VPS 鯖で mod_cache 入れたら過負荷になったときにサーバが落ちた（入れる前は過負荷でも落ちなかった）のでピーク時性能についてはどっちもどっちだと思います。まあ細かいことを言い出したらキリが無いので別の条件でベンチ取りたい人はよろしく〜(^o^)／）

まず最初のグラフは1秒あたりのサーバが返したレスポンス数です。

グラフのY軸がレスポンス数／秒、X軸が1秒あたりにクライアントから同時に発生したリクエスト数です。

nginx が nginx の WordPress トップページに対するベンチマーク、apache(VPS) が VPS 上で動かした Apache の WordPress トップページに対するベンチマーク、apache(STD) がさくらスタンダード上（の Apache）で動かした WordPress トップページに対するベンチマークの値です。

一個だけ見てもよく分からない部分が多々ありますので先にグラフを全部貼ります。

次のグラフは正常に完了したリクエストのレスポンスタイム(ミリ秒）です。

同時リクエスト数 70 〜 80 の間で Apache (VPS) のレスポンスタイムが 0 になっているのは、次のグラフのとおりサーバが落ちていたためです。

最後のグラフはエラーが返された数です。

Apache (VPS) では、リクエスト数（X軸）が70と80の時にエラーが70と80返されています。ベンチマークのリクエストが50を越えたあたりからサーバが処理しきれなくなって、70 〜 80 の間完全に落ちた状態となり、（このベンチマークは連続して行いましたので）90ぐらいから先に送ったリクエストが（タイムアウトなどで）終了し始め、100リクエストのころにはちょっと回復していた感じになっています。

Apache (STD) が微妙にエラーを出してるのは、アクセス制御用のモジュールを入れているからだと思いますが、自分で設定したサーバでは無いので詳細は不明です。

以上から、

  • nginx: 25 〜 44 リクエスト／秒のスループットで、同時リクエスト数が 60 を越えたあたりからレスポンスタイムが悪化（最高値 720.2 ms)、同時リクエスト数が 90 を越えたあたりからエラーが出始める。
  • Apache (VPS): 13 〜 24 リクエスト／秒のスループットで、同時リクエスト数が 20 を越えたあたりからレスポンスタイムが悪化（最高値 3643.2 ms)、同時リクエスト数が 50 を越えたあたりからエラーが出始め、一時完全に落ちた。
  • Apache (STD): 18 〜 30 リクエスト／秒のスループットで、レスポンスタイムは線形に悪化していないので詳細不明、割とすぐにエラーを返し始める。共有サーバだし詳細もよく分からんのでご勘弁を。

みたいな感じだと思います。

とりあえず VPS で WordPress を動かすなら nginx 使う方が良い(*´・ω・)(・ω・｀*)ﾈｰ、って結果でした。

VPS についてはベンチマーク中に Load Average も計ってたんですが、nginx の最高値が 0.14、Apache の最高値が 132.56 でした。お話にならんって感じです。

VPS サーバで一番メモリを使ってるのは MySQL サーバですので、ここをチューニングするとさらに速くできるかも、です。
nginx のキャッシュに memcached を使ったりもできるのですが、さくら VPS 512 にデータベースやらなんやら全部置いててメモリ的に厳しいので今のところパスしてます。

こちらの記事によると別の VPS に DB サーバを立てたりしてもおkみたいですので、チューニングの余地は結構ある感じです。
さくらクラウドで動かすのもいいかもしれませんねー。

てことで、WordPress が重い重い言ってる人は nginx に乗り換えチャイナYOU！

参考サイト

最後に sakuratan.biz を nginx に移行する際に参考にしたページのリンクを貼っときます。この記事のとおり作業してみたけど何かうまくいかないって時は以下のサイトに解決方法があると思います。

あわせて読みたい

ハイパフォーマンスHTTPサーバ Nginx入門
ハイパフォーマンスHTTPサーバ Nginx入門
posted with AZlink at 2011.9.7
Clement Nedelcu,長尾高弘
アスキー・メディアワークス
売り上げランキング: 56939
Amazon.co.jp で詳細を見る

0 Comments »

コメントはまだありません。

この投稿へのコメントの RSS フィード。 TrackBack URI

コメントする

Copyright © 2011 さくらたんどっとびーず | powered by WordPress with Barecity