WordPressのパフォーマンス向上策~WEBO Site SpeedUpの導入

DB層(MySQL)、PHPと続けてきたパフォーマンス向上策の第三弾です。 今度は、WordPressそのもののパフォーマンス向上を狙ってみます。

そこで、いきなり結論ですが、以前ふと見つけていた「WEBO Site SpeedUp」を導入したいと思います。

インストールは簡単です。WordPressのプラグインとしてインストールできます。 下記URLで、zipファイルをダウンロードして、それをプラグインインストールするだけです。

http://code.google.com/p/web-optimizator/downloads/detail?name=webo.site.speedup.v1.4.0.wordpress.zip

あとは、設定というより、それぞれの環境に応じていろいろ試行錯誤してみてください。日本語対応版がありませんが、「Configuration wizard」という便利な機能もあるので、楽ちんでパフォーマンス向上ができます。是非お試し下さい。

WEBO Site SpeedUp による当サイトのチューニング(最適化)結果には満足しています。WEBO Site SpeedUp の効果で、サーバ処理時間がほぼ半分になりました。

ちなみに、当サーバ環境での現在状況を示す画面のコピーを掲載しておきます。最適化直後のものではありませんが(画面コピーを取り忘れました)。

WEBO Sites SpeedUp

PHP~パフォーマンス向上策(続報)

前日に、PHPのパフォーマンス向上策として、php-eaccelerator (eAccelerator)を導入しましたが、その後の状況をお伝えします。

php-accelerator の設定(/etc/php.d/eaccelerator.ini の設定)を2カ所変更しました。そのうちの eaccelerator.shm_size については、カーネルの許容範囲ぎりぎりの

eaccelerator.shm_size = “30”

という設定をしました。

ほぼ一日稼働させた後、キャッシュメモリの使用率がどうなっているか確認したところ、80% でした。わざといろいろな(WordPressのダッシュボードも含めてほぼすべての)ページパターンを実行してみましたので、必要とされるほぼすべてのPHPコードを使用したと考えています。

その状態でキャッシュメモリ使用率が80%ですので、”30″(30MB)でほぼ足りると判断しています。

ちなみに当サーバのWordPress関連環境は次の通りです。

WordPress 3.1.8 (テーマ:Atahualpa 3.6.4) MySQL 5.5.10 PHP 5.3.6

PHP~パフォーマンス向上策

MySQLのパフォーマンスチューニングに続き、WordPressの記述言語であるPHPのパフォーマンス向上策を施します。 PHPのバージョンは 5.3.6 です。

検討結果からお話しすると、最も手軽で、それなりの効果実績と、開発プロジェクトがしっかり動いているという観点から、eAccelerator を導入することにしました。

1.パッケージの検索

さて、eAccelerator のホームページ http://www.eaccelerator.net/ ではソースからのインストールになっています。 rpmもしくはyumでインストールできないかと思い、早速remiに探しに行ったところ、あるじゃないですか。

yumコマンドでパッケージ情報を確認してみると、次の通りeAccelerator のパッケージで間違いないことが分かります。

[root ~]# yum info –enablerepo=remi php-eaccelerator Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile * addons: www.ftp.ne.jp * base: www.ftp.ne.jp * epel: ftp.iij.ad.jp * extras: www.ftp.ne.jp * remi: remi-mirror.dedipower.com * rpmforge: ftp-stud.fht-esslingen.de * updates: www.ftp.ne.jp remi | 2.6 kB 続きを読む »

MySQL 5.5.10 ~パフォーマンスチューニング

WordPressのパフォーマンス向上の目的で、パフォーマンスチューニングを始めました。

httpd層では、別記事に記載したように、mod_chche、mod_disk_cacheを使用して、最低レベルの対策を実施しています。もちろん、まだ上のレベルがありますが、ここでは、DB層のパフォーマンスチューニングを実施します。

WordPressですので、DB層はMySQLです。現時点で最新のバージョン5.5.10を使用しています。

さて、まずは、現状を知ることから。

そこで、MySQLTuner を使用してみます。MySQLTuner は稼働中のMySQLの設定情報やログ情報からセキュリティ、パフォーマンスに関する診断結果と推奨情報を提供してくれるperlスクリプトです。

実際の利用には、まずは MySQLTuner をダウンロードします。

[root ~]# wget mysqltuner.pl –2011-03-30 12:51:21– http://mysqltuner.pl/ mysqltuner.pl をDNSに問いあわせています… 50.56.84.181 mysqltuner.pl|50.56.84.181|:80 に接続しています… 接続しました。 HTTP による接続要求を送信しました、応答を待っています… 302 Found 場所: http://mysqltuner.pl/mysqltuner.pl [続く] –2011-03-30 12:51:22– http://mysqltuner.pl/mysqltuner.pl mysqltuner.pl|50.56.84.181|:80 に接続しています… 接続しました。 HTTP による接続要求を送信しました、応答を待っています… 200 OK 長さ: 41393 (40K) [text/plain] `mysqltuner.pl’ に保存中 100%[======================================>] 41,393 76.2K/s 時間 0.5s 2011-03-30 12:51:23 (76.2 KB/s) 続きを読む »

mod_pagespeedをやめて、mod_cache、mod_disk_cacheに戻した

Apache HTTP Serverの「高速化」の目的で導入してみたGoogle codeの mod_pagespeed ですが、どうもメモリを食うということが分かってきました。感覚的に、平均500MB程度消費が増えていると判断しています。

恐らくそれが原因でしょうが、逆にWebを含めたサーバのパフォーマンスが悪化するケースが頻発するようになりました。

単純な検証ではありますが、mod_pagespeed を外し、mod_cache に戻すとメモリ使用量の推移とその変化に伴うパフォーマンス悪化が劇的な位に無くなります。 別に、これをもって mod_pagespeed を悪評価するつもりではありませんが、私の環境(WordPressによる動的HTML作成)には不相応だったのかも知れません。

ということで、 mod_pagespeed をやめて、元の mod_cache、mod_disk_cacheの戻しました。