WordPress高速化を試みる
Sunagaeでは現在WordPressを使用しています。最近はその速度の遅さが気になっています。その遅さの原因を探って、改善を試みました。
気になるってのは、当然、見てくれる方にとって遅いのも困るけど、記事を編集する時も、記事開いたり、保存とかするのが遅すぎて結構いらいら。できれば両方高速化したいのですが。。。
ということで、ベンチマークとりつつ、Apache、PHPなど含め、いくつかの方法をためしてみることにします。結論は最後にまとめてあるのでせっかちな人は最後だけどうぞ。
状態把握
まずは測定。ベンチマーク。sunagae.netのトップページを表示させたとき、CPUの使用率をY軸、時間軸をX軸にして折れ線チャートを書いてみました。左上のチャートがその書いたものです。
ちなみに、sunagae.netのマシンはIntel D945GCLF2です。Atomの1.6GHz×デュアルコアです。
五回試して、すべて重ねて書いてあります。時間軸の単位はあんまあてにならないんですが、とにかく同時実行数が一つでも結構な負荷で、どうしようもない。
WordPressってこんなものなのか。それともサーバーがAtomだからだめなのか。とりあえず後者の可能性を排除するため、Core 2 duo E8500 3.16GHzのマシンでも試してみました。チャートとか作ってないけど、結局似たような負荷になりました(いやまぁ、さすがにatomよりはいくらか早いけど)。ということで、結局WordPressかApacheとかPHPあたりの、ソフトウェアが悪いと判断。
とりあえず、高速化できたかどうかの指標のために、ApacheBenchで計測しながらチューニングしていく。
とりあえず何もしない状態。
実験条件＝#ab -n 10 -c 10 http://sunagae.net/
Requests per second: 1.57 [#/sec] (mean)
Time per request: 6369.249 [ms] (mean)
Time per request: 636.925 [ms] (mean, across all concurrent requests)
Transfer rate: 47.34 [Kbytes/sec] received
数字の読み方は、一番上の太字の部分(Request per second)が、一秒間に何回ページを表示(読み込み)させることができるか、です。これを基準にしていきます。
ちょっとした出来心で・・・
WordPressをKCachegrindで解析したときのキャプチャ
あまり意味のある結果がえられるか分からななかったけど、ちょっとやってみたかったのでプロファイラに挑戦。方法詳細は省略。XdebugとKCachegrindをつかって解析してみました。KCachegrindはKDEの開発ツール入れればかってに入ってます。このことに気がつかなくてちょっと苦戦しました。
右の写真が解析結果。これは、http://sunagae.net/を三回表示させた後です。
とりあえず、ローカライズまわり(gettextあたり)が結構処理時間を食っていることまではわかりました。ローカライズしないで英語のままでWordPress使えば結構はやくるのかな。
あまり深入りもしなかったのでこれ以上のことはよくわからず。
ま、他の方法があまり効果がなくて、かつ気が向いたら改造とかいろいろ試してみます。
APCを入れてみる
適当にググってみたら、phpの高速化の手段としててはまずAPCと言うのがあるらしい。PHPのスクリプトを中間コードにコンパイルして、それをキャッシュしておくソフトウェアらしい。WordPress.comではこれを用いて五割程度性能向上したとの話も。
Gentoo Linuxでは「dev-php5/pecl-apc」というパッケージで提供されている。ということでそこからemerge。
# emerge dev-php5/pecl-apc
Apache用の設定ファイルは「/etc/php/apache2-php5/ext/apc.ini」にあるらしいけど、最初っから有効にする設定になるっぽいので、そのままApacheの再起動。
# /etc/init.d/apache2 restart
phpinfo()なりで有効かどうかが確認できます。
というわけで、早速ベンチマーク。上と同じ条件で計測。
Requests per second: 1.65 [#/sec] (mean)
Time per request: 6043.692 [ms] (mean)
Time per request: 604.369 [ms] (mean, across all concurrent requests)
Transfer rate: 49.82 [Kbytes/sec] received
んー、たしかに多少早くなったけど。。。大差なし。残念。sunagaeでは五割の向上は程遠いようです。なんか設定間違えているのかなー。。。apc.phpとかでキャッシュしてる事も確認したんだけど。
とりあえず断念。今んとこAPCは有効のまま使ってるけど、なんかたまに空白のページとか出るようになったから様子見て無効化するかも。
wp-cache
WordPressの各ページをキャッシュして、高速化するプラグイン。当然外部に見せるためのページに関しては、高速化できるはず。
ということでwp-cacheの本家からダウンロードして入れてみました。
ベンチマーク。
Requests per second: 7.12 [#/sec] (mean)
Time per request: 1403.556 [ms] (mean)
Time per request: 140.356 [ms] (mean, across all concurrent requests)
Transfer rate: 215.52 [Kbytes/sec] received
速いっ。やっぱり速い。4倍以上速い。まぁ当然か。体感も速い。最初(未キャッシュ状態)以外でははほぼ一瞬で表示される。でも毎秒7リクエストってのもWebサーバとしてどうかと思うけどね。まぁいいか。
しかしながら、残念な事に、編集画面には影響なし。
Hyper Threadingを無効化
D945GCLF2のAtomはHyper Threadingが有効になっています。もしかしたらHyper Threadingも影響するのかなんて思いつつ、一応変化を調べてみました。HTの有効無効はBIOSで設定できます。
ちなみに、実験条件は、Hyper Threading無効のときに(たぶん)有利になるように、同時実行数は一つにしました。つまり、-cオプションを1にしてあります。
(HT有効時)
Requests per second: 0.66 [#/sec] (mean)
Time per request: 1505.313 [ms] (mean)
Time per request: 1505.313 [ms] (mean, across all concurrent requests)
Transfer rate: 20.00 [Kbytes/sec] received(HT無効時)
Requests per second: 0.57 [#/sec] (mean)
Time per request: 1767.685 [ms] (mean)
Time per request: 1767.685 [ms] (mean, across all concurrent requests)
Transfer rate: 16.69 [Kbytes/sec] received
結果、HT無効時に有利になるように条件かえたのにもかかわらず、HT有効の方が若干速いということに。
ちょっとHTがどういう効果があるのかは分かりませんが、とにかくシロートは有効にしとけって話なんでしょう。さーせん。
結論
sunagae(Dual-Core Atom)上のWordPressにおいて、
- APC(PHPスクリプトの中間コードキャッシュ)有効化→あまり効果なし、phpの実行がやや不安定になる
- wp-cacheプラグイン(WordPress記事のキャッシュ)→4倍近く速くなる、ただ編集画面は変わらず
- HT無効化→条件揃えても遅くなる。シロートは有効にしとけ。
ということで、wp-cacheだけ使っとくのがいいという結論です。
編集画面を高速にする方法は未だ見出せず。Google Gearsってのが高速化に使えるらしいけど、Firefox3@Linuxでつかえなさげだし。ていうかGoogleきらいd(ry
だれかいいのあったら教えてください。