WordPressを100倍速くする！ MySQLの調整やnginx proxy cache

[追記１] 最後で説明しているproxy cacheの設定を修正しました。
[追記２] nginx proxy cacheでキャッシュしない場合の処理を変更しました。
[追記３] スマートフォンや携帯で閲覧した時にキャッシュしない設定を追加しました。

はじめに

大げさな題名ですが、今回はWordPress単体を速くするのではなく、データベースやWebサーバなどの調整、またnginxのproxy cache機能を使って速くする話になります。

サイトの構成によっては、proxy cacheは使えないかもしれませんが、使わなくても5倍程度速くすることはできましたので、参考にしていただければと思います。

今回行うチューニング一覧

1. DBを最適化するプラグインを導入する
2. APCを導入してPHPを速くする
3. MySQLを速くする
4. 重いWordPressプラグインを外す
5. nginx+FastCGIにする
6. WP Super Cacheを使う
7. nginxのproxy cacheを使う

準備

現状の調査や、ログの出力など、いくつか準備をします。

WordPressの遅さ

kray.jpはAmazon EC2のsmallインスタンスにWordPressをインストールして構築しています。
普段はそれほどアクセスがないので気にならないのですが、たまにアクセスが集中した時にサーバが重くなります。smallインスタンスだからしょうがないよねって思っていましたが、今回本格的に調査してみることにしました。

現状の把握

kray.jpは下記の環境で動いています。
静的コンテンツはnginxが返しており、Apacheの方でWordPressが動いています。

• Amazon EC2 small
• nginx + Apache + WordPress
• MySQL

計測結果

0.90/sec

静的コンテンツと動的コンテンツを組み合わせて負荷計測もしましたが、レスポンスが違いすぎてわかりにくいため、今回は動的コンテンツのレスポンスを把握します。

結果は、0.90/secという驚愕の遅さでした。
1秒間当たり、1レスポンス返せていません。
正直何か設定を間違えているのかと思うほどでした。

原因を推測する

まず思いつくことをざっと挙げてみます。

• Amazon EC2 small自体の重さ
• WordPressのDBテーブルのインデックスが適性でない
• PHPが重い
• MySQLが重い
• WordPressプラグインが重い
• nginx+Apacheの組み合わせが悪い

この中で私は次の項目が主な原因だろうと推測しました。（結果として下記の推測は外れます…）

• WordPressのDBテーブルのインデックスが適性でない
• MySQLが重い

時間のない時は当たりをつけて解決を目指しますが、今回は詳細に調べたかったので一つずつ調べていきたいと思います。

Amazon EC2 small自体の重さを確認する

まずAmazon EC2 smallインスタンス自体の遅さを考えてみます。
smallインスタンスはCPUの上限が抑えられているため、重い処理のレスポンスは悪そうです。そもそもsmallが重いのかを確認するために簡単なRailsアプリで調査してみました。

100万件のデータを突っ込んで、20件ずつページネーションするようなRailsアプリを作って、計測します。

20.0/sec

思ったよりも悪くありません。
もちろん通常のサイトなら、いろんな処理をするためにもっと遅くなりますが、1/5になっても絶望的な数値ではありません。アプリケーションの作り方さえ気をつければ、smallでも十分そうです。

遅いクエリログをログに出力する

これだけ使われているWordPressのテーブルやインデックスが適切でないとは考えにくいのですが、プラグインが使っているSQLがインデックスに合っていないとかはありえそうです。

まずMySQLでslow logを出すように設定します。
kray.jpはMySQL5.0系でしたので、5.0の設定をします。5.1の場合は少し設定が違うので注意してください。

log-slow-queries = /var/log/mysql-slow.log
long_query_time = 1
log-queries-not-using-indexes

log-queries-not-using-indexesはインデックスを使っていないSQLもログに残す機能です。

ログを確認したところ、1秒以上かかるようなクエリはありませんでした。
ただインデックスを使っていないクエリはあったので、explainを使って確認しましたが、あまり関係なさそうです。

では次から実際にチューニングをしてきたいと思います。

DBを最適化するプラグインを導入する

WordPressデータベースの最適化をしてくれるプラグインがあるので入れてみます。
下記の2つを試してみました。

WP-DBManager

http://wordpress.org/extend/plugins/wp-dbmanager/

Figment Thinking WordPress Database Table Optimizer

http://wordpress.org/extend/plugins/wordpress-database-table-optimizer/other_notes/

3回ほど計測してみましたが、全然変わりません。
やらないよりはましですが、効果無しと考えました。

APCを導入してPHPを速くする

APCとはPHPを中間コードにしてメモリ上にキャッシュし、高速化するモジュールです。

計測結果

0.9/sec → 1.0/sec

今回の状況だとあまり効果がなかったのですが、APCは導入するとCPU負荷は減ると思いますので、導入した方がいいと思っています。

参考記事

• APC（Alternative PHP Cache）再び
• php-apcでPHPの高速化 on CentOS5
• PHP（というかWordPress）高速化のためにAPC（Alternatice PHP Cache）入れた

MySQLを速くする

クエリログを調べた時に遅そうなログはなかったと書きましたが、1つずつは軽くても、たくさんあれば重くなるので、1ページ当たりのDBへのアクセス数を調査しました。

クエリログを残すように設定するには次のようにします。

log=/var/log/mysql-query.log

ログを確認したところ、kray.jpのトップで発行されるクエリ数は47ありました。MySQLをインストールしただけでは、クエリキャッシュは効いていないため、設定すれば大きな効果が得られそうと考えました。

MySQLのチューニングは1つの記事になってしまうぐらいなので、さらっと流します。
チューニングは下記の記事が参考になると思います。

参考記事

• 5分でできる、MySQLのメモリ関係のチューニング！
• MySQLのパラメータ調整
• MySQLのパラメータチューニング

今回は次の設定にしました。

skip-bdb
thread_cache_size=64
query_cache_size=128M
query_cache_limit=4MB
table_cache=128
tmp_table_size=32M
max_heap_table_size=32M
key_buffer=256M
sort_buffer=32M
myisam_sort_buffer=32M
wait_timeout=60

結果は次のようになりました。

計測結果

1.0/sec → 1.1/sec

あまり速くなっていません。
ページのレスポンスが低く、DBへの負荷があまり無いのだと推測できます。
ボトルネックがDBの場合は大きな効果はあると思います。

重いWordPressプラグインを外す

DBが重いというアテが外れたので、他の原因を調査します。

WordPressはプラグインが豊富にあって、いろいろ試したくなります。
kray.jpでもいろんなプラグインを使っていますが、重い可能性があるので確認してみました。

まず全てのプラグインを停止して計測してみます。

1.1/sec → 2.0/sec

おっ！倍ぐらいに速くなりました。
でも全部を停止すると困るので、1つずつ調べたところ、embedlyという使っていないプラグインが重いことがわかりました。

こちらを外して、後は元に戻しました。
結果として次のような値になっています。

計測結果

1.1/sec → 1.5/sec

nginx+FastCGIにする

PHPの場合、nginx+FastCGIにした方が速いので変更します。
それとnginx+Apacheの組み合わせだと、メモリは喰うし、ボトルネックがわかりにくいという理由もあります。

nginx+FastCGIへの変更は下記の記事がわかりやすかったです。

参考記事

• WordPress on nginx with FastCGIのCentOSの場合
• WordPress on nginx with FastCGIに移行してみた

FastCGIをunix socketで動かす方が速そうなので、設定してみます。

FastCGIをunix socketで動かす

nginxのドキュメントを参考にします。
http://wiki.nginx.org/PHPFcgiExample

spawn-fcgiを使っている場合は、下記のように修正します。

bind=/tmp/php.socket
daemon $spawnfcgi -s ${bind} -u ${server_user} -g ${server_group} -P ${pidfile} -C ${server_childs} -f ${php_cgi}

nginx+fastcgi(unix socket) で次のようになりました。

計測結果

1.5/sec → 1.8/sec

WP Super Cacheを使う

WordPressプラグインのWP Super Cacheでキャッシュをします。
これが一番効果があるとは思いますが、最初から導入してしまうとわかりづらくなるため、最後の方に持ってきました。

計測結果

1.8/sec → 7.2/sec

やっとまともな数値になってきました。

nginxのproxy cacheを使う

さて今回の目玉です。
nginxのproxy cache機能を使って、動的コンテンツもキャッシュします。
nginx+FastCGIでproxy cacheを使えば、リソースもあまり喰いません。

nginx+fastcgiで127.0.0.1:8001でWebサーバを立て、nginx内で同時にproxy cacheで8001ポートを見るという構成になっています。

まず、FastCGI部分の設定になります。

WordPressを動かすWebサーバの設定（FastCGI）

127.0.0.1:8001でWordPressを動かしています。

server {
        listen       8001;
        server_name  _;
    
        access_log  /var/log/nginx/fastcgi-access.log  main;

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

            # static files
            if (-f $request_filename) {
                expires 30d;
                break;
            }

            # request to index.php
            if (!-e $request_filename) {
                rewrite ^(.+)$  /index.php?q=$1 last;
            }
        }

        location ~ \.php$ {
            root           html;
            fastcgi_pass   unix:/tmp/php.socket;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /var/www/html/$fastcgi_script_name;
            include        fastcgi_params;
        }
}

proxy cacheの設定（FastCGI）

まず、nginx.confのhttpの項目に以下を追加します。

proxy_cache_path /var/www/nginx_cache levels=1:2 keys_zone=czone:4m max_size=50m inactive=120m;
proxy_temp_path  /var/www/nginx_tmp; 

それとWebサーバとの連携部分です。

upstream backend {
        ip_hash;
        server 127.0.0.1:8001;
}

server {
        listen 80;      
        server_name kray.jp;
        access_log  /var/log/nginx/kray.jp.access.log;
        error_log  /var/log/nginx/kray.jp.error.log;
                                        
        location ~ .*\.(htm|html|jpg|JPG|gif|GIF|png|PNG|swf|SWF|css|CSS|js|JS|inc|INC|ico|ICO) {
            root    /var/www/html;
            index   index.html;
            ssi     on;
            break;
        }

        location /wp-admin { proxy_pass http://backend; }
        location /wp-login.php { proxy_pass http://backend; }

        location / {
            if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
                set $do_not_cache 1;
            }

            if ($http_user_agent ~* “2.0\ 2MMP|240×320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800″) {
                set $do_not_cache 1;
            }

            proxy_no_cache     $do_not_cache;
            proxy_cache_bypass $do_not_cache;

            proxy_pass http://backend;
            proxy_cache czone;
            proxy_cache_key $scheme$proxy_host$uri$is_args$args;
            proxy_cache_valid  200 10m;
        }
}

上記でcookieの条件部分はコメント投稿者とログインユーザはキャッシュしない設定になります。cookie周りの設定については、まだ検証中ですので良い方法などありましたら教えてください。

追記１

proxy_cache_valid の設定箇所を修正しました。どういうタイミングで発生するかわかりませんが、301のレスポンスをキャッシュしてしまい、リダイレクトループしてしまうことがあるようです。

proxy_cache_valid  200 302 304 10m;
proxy_cache_valid  301 1h;
proxy_cache_valid  any 1m;

上記を下記のように変更しました。

proxy_cache_valid  200 10m;

追記２

キャッシュしない場合の条件と処理を変更しました。コメントを書いた人とユーザを個別のキャッシュを使うようにしていましたが、うまくキャッシュされないようです。

location / {
  if ($http_cookie ~* "comment_author_[^=]*=([^%]+)%7C|wordpress_logged_in_[^=]*=([^%]+)%7C") {
    set $my_cookie $1;
  }

  proxy_pass http://backend;
  proxy_cache czone;
  proxy_cache_key $scheme$proxy_host$uri$is_args$args$my_cookie;
  proxy_cache_valid  200 10m;
}

上記を下記のように変更しました。

location / {
  if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
    set $do_not_cache 1;
  }

  proxy_no_cache     $do_not_cache;
  proxy_cache_bypass $do_not_cache;

  proxy_pass http://backend;
  proxy_cache czone;
  proxy_cache_key $scheme$proxy_host$uri$is_args$args;
  proxy_cache_valid  200 10m;
}

追記３

コメントで教えていただいたスマートフォンや携帯から見た時にキャッシュしない設定を追加しました。user agentもproxy_cache_keyに付加して、それぞれのキャッシュのキーを作るといいかもしれませんが、今回はキャッシュしない設定にしてあります。

if ($http_user_agent ~* “2.0\ 2MMP|240×320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|PlayStation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows\ CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915\ Obigo|LGE\ VX|webOS|Nokia5800″) {
  set $do_not_cache 1;
}

計測結果

7.2/sec → 133.0/sec

参考記事

• Using Nginx as a caching proxy with WordPress+Apache
• Nginx Reverse Proxy Cache for WordPress and Apache

最後に

proxy cacheが強力なので、他の設定に意味があるのかとか思ってしまいますが、シビアな状況になってくると活きてくると思います。またキャッシュですので動的コンテンツによっては気をつけないといけない場面もあります。

今回は「WordPressを速くする」という内容でしたが、他にも使える方法も多いので、何か参考になりましたら採用してみてください。

宣伝

DocBaseとは

小さく始める・みんなで育てる・適切に伝える・安心して伝えるをコンセプトにした情報共有サービスです。
メモという形で小さく始められる、エンジニア以外のメンバーでも使いやすい仕組み、情報をまとめて整理できる、柔軟な権限設定で様々なプロジェクトで使えるなど、積極的な情報共有と業務の効率化を実現し、チームの成長を促します。

詳しくはこちらから。
https://docbase.io