K4750.NET

2013-09-14

WordPressの性能解析

XHProf（Hierarchical Profiler）という性能解析ツールを使用して、WordPressにおいて処理に時間がかかっている個所をあぶり出し、可能であれば改善する。既にAPCの導入、ja.moファイルの無効化により大きな改善は見られているため、今回は細々とした改善になると思われる。

１．XHProf導入

まずは、XHProf拡張をコンパイル・インストール。

$ wget http://pecl.php.net/get/xhprof-0.9.3.tgz
$ tar xvfz xhprof-0.9.3.tgz
$ cd xhprof-0.9.3/extension/
$ phpize
$ ./configure
$ make
$ make test
$ sudo make install

/etc/php5/apache2/php.ini等に以下を追加する。

[xhprof]
extension=xhprof.so
xhprof.output_dir=/tmp

Apacheを再起動（service apache2 restart）後、XHProf拡張は有効になる。

XHProfではコールグラフを生成できるので、そのために必要なコマンドもインストールしておく。

$ sudo apt-get install graphviz

２．WordPressのプロファイリング

index.phpを以下のとおり編集する（赤字部分を追加する）。/home/www-data/xhprof-0.9.3は先ほどのxhprof-0.9.3.tgzを展開したディレクトリ。

<?php
/**
* Front to the WordPress application. This file doesn't do anything, but loads
* wp-blog-header.php which does and tells WordPress to load the theme.
*
* @package WordPress
*/
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
/**
* Tells WordPress to load the WordPress theme and output it.
*
* @var bool
*/
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php');

$xhprof_data = xhprof_disable();
include_once "/home/www-data/xhprof-0.9.3/xhprof_lib/utils/xhprof_lib.php";
include_once "/home/www-data/xhprof-0.9.3/xhprof_lib/utils/xhprof_runs.php";
$xhprof_runs = new XHProfRuns_Default();
$xhprof_runs->save_run($xhprof_data, "xhprof_foo");
?>

そして、WordPressのトップページにアクセスすると、サーバ上の/tmpディレクトリ配下に5233bea4082fb.xhprof_foo.xhprofといった名前のファイルが生成される。

３．プロファイル解析

xhprof-0.9.3.tgzに格納されている以下の2つのディレクトリを、WordPressと同じディレクトリ（例えば、/var/www）へコピーまたは移動する。

$ cp -rp .../xhprof-0.9.3/xhprof_html /var/www
$ cp -rp .../xhprof-0.9.3/xhprof_lib /var/www

そして、ブラウザから「http://…/xhprof_html/」へアクセスすると、/tmp配下に生成されたプロファイルが一覧表示されるので、ファイルをクリックすると・・・あとは個々の関数呼び出しにかかる時間や割合、コールグラフによる視覚的な呼び出し関係が確認できる（詳細割愛）。

４．解析結果

XHProfの結果をざっと見ると、私個人レベルで簡単に改善できそうな個所はほとんど見られず。ただ、細かい点として、convert_smilies（スマイリーを画像へ変換するフィルタ）に11ミリ秒、自作のカレンダー表示に15msかかっていた。カレンダーはせっかく作ったモノなのでそのままとして、convert_smiliesは不要なので使用しないことにした（管理画面の投稿設定「:-) や :-P のような顔文字を画像に変換して表示する」をオフにする）。

５．ab（ApacheBench）の結果

abコマンド（ab -c 20 -n 200 http://www.k4750.net/（20多重で200リクエスト））の実行結果について、前回（ja.moの無効化）との比較を以下に示す。

2013-09-14

WPLANG変更によるWordPressの高速化

wp-config.phpのWPLANGの値の変更によるWordPressの高速化（高速化ネタその１の続き）。結論から言うと、レスポンスタイムが、APC（Alternative PHP Cache）を導入した状態からさらに約3割削減となった（1297.319ミリ秒→886.885ミリ秒）。ようやくレスポンスタイムが1秒を切ったことになる。

１．プロファイリング

XHProfを使用して、処理に時間がかかっているファンクションを調査してみると、wp-settings.phpから呼び出されるload_default_textdomainの処理時間が、全体の処理時間の35%を占めていることが判明。

このファンクションはwp-config.phpのWPLANG定数の設定値に従い、wp-content/languages/ja.moファイル等を読み込む処理である。このja.moファイルは、簡単に言うと英→日の辞書であり、WordPressはこの辞書を使用して管理画面等を日本語表示する。

本サイトはテーマを自作しており、また、この翻訳機構を必須とするプラグインも導入していないため、ja.moの読み込みは無用である。よって、このファイルを読み込まないよう設定することとした。

２．WPLANG定数の変更

wp-config.phpのWPLANG定数の値をja（日本語）にするとja.moファイルを読み込んでしまうので、違う値（en（英語））に変更する。ただし、管理画面は日本語表示したいので、ここを参考に、WPLANG定数の定義を以下のように書き換える。

if (strpos($_SERVER['REQUEST_URI'], '/wp-admin/') === 0) {
    define ('WPLANG', 'ja');
} else {
    define ('WPLANG', 'en');
}

３．ab（ApacheBench）の結果

abコマンド（ab -c 20 -n 200 http://www.k4750.net/（20多重で200リクエスト））の実行結果について、前回（APCの導入）との比較を以下に示す。

４．余談

ja.moは使用しつつレスポンスタイムを低下させない方法としてMO CacheというWordPressプラグインを使用する選択肢もあるようだが、本サイトではその必要がなかったので、上記対応を行うこととした。