K4750.NET

最近の投稿を表示する

WordPressにて最近の投稿を一覧表示させた際のメモ。BootstrapのList group&Linked items(リストの要素にアンカータグを使う)にて実装している。


1.スクリーンショット

recentposts


2.ソースコード

最近の投稿を10個('numberposts' => 10)表示する。また、個別投稿ページかつ記事のIDが一覧のIDと一致した場合(is_single() && get_the_ID() == $p->ID)は、アンカータグのclass属性にactiveを追加し、背景を強調する。

<div class="panel panel-default">
  <div class="panel-heading"><h4 class="text-muted">Recent Posts</h4></div>
  <div class="list-group">
    <?php foreach(get_posts(array('numberposts' => 10)) as $p) {?>
      <a class="list-group-item<?php if (is_single() && get_the_ID() == $p->ID) echo " active";?>"
         href="<?php echo get_permalink($p->ID);?>"><small><?php echo $p->post_title;?></small></a>
    <?php } ?>
  </div>
</div>

SSLを最短で有効化

WordPressの管理画面へhttpsでアクセスできるように設定した際のメモ。ただし、面倒な作業は極力避け、SSLを最短の手数で有効化する。なお、いわゆる「オレオレ証明書(self-signed certificate)」はデフォルトでインストールされているものを使用せずに、今回のSSL化に伴い再生成している。環境はUbuntu 12.04.3 LTS + Apache2。


1.SSL有効化

Apache2のSSLを有効化。オレオレ証明書は再生成する(make-ssl-cert)。

# a2enmod ssl
# a2ensite default-ssl
# make-ssl-cert generate-default-snakeoil --force-overwrite
# service apache2 restart

WordPressのログインおよび管理画面へのアクセスでhttpsを強制するためにwp-config.phpへ以下を追記する。

define('FORCE_SSL_ADMIN', true);

2.make-ssl-cert

make-ssl-certコマンドの正体(何をやっているのか)については後日投稿予定


3.参考

WordPressの性能解析

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


1.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

2.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といった名前のファイルが生成される。


3.プロファイル解析

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配下に生成されたプロファイルが一覧表示されるので、ファイルをクリックすると・・・あとは個々の関数呼び出しにかかる時間や割合、コールグラフによる視覚的な呼び出し関係が確認できる(詳細割愛)。


4.解析結果

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


5.ab(ApacheBench)の結果

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

テスト時間(秒) 秒間リクエスト数 リクエスト時間
(ミリ秒)(平均)
初期状態 26.370 7.58 2637.035
APC導入後 12.973 15.42 1297.319
WPLANG変更後 8.869 22.55 886.885
convert_smiliesオフ 8.235 24.29 823.525

WPLANG変更によるWordPressの高速化

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


1.プロファイリング

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

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

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


2.WPLANG定数の変更

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

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

3.ab(ApacheBench)の結果

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

テスト時間(秒) 秒間リクエスト数 リクエスト時間
(ミリ秒)(平均)
初期状態 26.370 7.58 2637.035
APC導入後 12.973 15.42 1297.319
WPLANG変更後 8.869 22.55 886.885

4.余談

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

APC(Alternative PHP Cache)によるWordPressの高速化

本サイトの表示速度を上げるためにAPCを導入した(事前にMaxClientsの値を20に設定済)。結論から言うと、レスポンスタイムが半減した。


1.ab(ApacheBench)の結果

abコマンド(ab -c 20 -n 200 http://www.k4750.net/(20多重で200リクエスト))の実行結果について、導入前後の測定値を比較すると、APCの導入だけでリクエスト時間(Time per request)が半減したことが分かる。

テスト時間(秒) 秒間リクエスト数 リクエスト時間
(ミリ秒)(平均)
導入前 26.370 7.58 2637.035
導入後 12.973 15.42 1297.319

2.環境および導入

環境についてはこちらを参照。導入方法は以下のとおり。

# apt-get install php-apc
# service apache2 restart