最近 WordBench が、当サイトと同じめ組のVPSに引っ越して来ました。
そんな縁もあって WordBench.org のサーバのチューニングを手伝ったのでメモ。
今回、行ったチューニングは Apache, PHP, MySQL についてだけで、WordPress のプラグインを用いる ( WP Super Cache や object cache など ) チューニングは行っていません。
WP Super Cache とか使わなくても、サーバー側の設定をつめてやるだけで、子サイトを複数持った WordBench のようなサイトでも、十分に良いパフォーマンスが得られますよっていうお話です。
大まかな項目は、こんな感じ。
さくらのVPSのお試し期間を使って、色々試してみたので、メモ。
初期設定とかは、hiromasa さんのエントリを参考に。
今回の構成は、Web サーバ lighttpd 、PHP 5.3.x、MySQL 5.1.x で WordPress を動作させるところまでやってみます。
続きを読む
さくらの共用サーバから、め組のVPSに移行した際に設定した項目のメモです。
大まかにはこんな感じ
livedoor blog から WordPress に移行してからずっと dogmap.jp は、SAKURAのレンタルサーバで運用してきましたが、先日ホスティング先をめ組VPSライトに移行しました。
め組さんが、このサービスを本格的に立ち上げる前に先行モニターとしてしばらく使わせてもらっていました。
まだ、設定が詰めれてないんで詳細報告できませんが、そのうち設定をどのように行ったかは、当ブログにエントリします。
apache の設定をホンのちょっと変更して、APC入れたくらいですが、かなり速度改善されました。
SAKURA（スタンダード）版は、しばらく以下のURLから接続できるようにしておくので、見比べて見てください。
http://blog.dogmap.jp/
よりパフォーマンスの良い WordPress サイトを構築したいならば .htaccess ファイルを修正しましょう。
Webサーバに apache 2系を使用しているサイト用に、私が書いた .htaccess ファイルを元に解説します。
基本方針は
このサイトを設置している、さくらインターネットのサーバOSが FreeBSD 7.1 にバージョンアップされました。
その際 MySQL も 4.0.x と 5.1.x を選択できるようになりました。
てなわけで、WordPress で使用する DB を MySQL4系から5.1系に移行したわけなんですが、文字コード周りでちょっとハマってしまったので、メモを残しておきます。
今回ハマったのは、"〜"(波ダッシュ)等の文字コードが Win系のUTF-8と標準UTF-8で異なる問題（いわゆる波ダッシュ問題）。
とりあえず、エクスポートした過去エントリのデータを文字コード変換して、さらに今後のエントリのためにForce Wave Dashプラグインを導入しました。
続きを読む
「逆光は勝利」「世はなべて三分の一」「ピーカン不許可」「頭上の余白は敵だ」
と言うわけで、投稿やページにアップロードされた画像ファイルを抽出し、サムネイルで一覧表示する WordPress 用プラグイン wp-kougabu を導入しました。
このプラグインによるサムネイルの一覧表示は こちら。
で、このプラグイン導入したページをページ分割しようと思ったんですが、私が使っているテーマ（ほぼ自作）はページ分割に対応していないことが判明。
慌てて、テンプレートタグ wp_link_pages() を追記したんですが、これが吐き出す (X)HTML が、気にくわない。
カレントページ番号に対して CSS でスタイル指定しづらいマークアップになってしまうので、ゴニョゴニョして何とかしました。
続きを読む
さて、前回、オブジェクトキャッシュの効率化に着手して、モノの見事に失敗した私ですが、File-Based Extension to the WordPress Object Cacheなるモノを発見。
DBアクセスせずにファイルアクセスで、済ませてしまおうという仕掛けです。
要はコレ、WordPress 2.5.x 以前にあったオブジェクトキャッシュを、2.5.x 以降のバージョンでも使えるようにしてしまおうというものです。
しかも、ご丁寧にも APC、XCache、eAccelerator などのPHP用の各種キャッシュモジュールが使える場合は、それ用のモノも用意してあります。
これらを利用すれば、オブジェクトキャッシュ情報をファイルに書き出すのではなく、PHP用の各種キャッシュモジュールが管理する変数キャッシュ領域にセットしてくれます。
SAKURA では PHP が CGIモードで動作しているため、PHP用の各種キャッシュモジュールがイマイチ使えないので、File-Based Extension… を導入してみました。
続きを読む
さて、前回の続き。
すっかり query 数を減らすことに執着してしまった男が、冥府魔道に迷い込んでしまったお話。
他に減らせるコストは無いか？キャッシュできる情報は無いか？しばし黙考。
そうだ！オブジェクトキャッシュでキャッシュされているデータを取っておいて、次に呼び出された時にロードすれば
良いじゃないか？
と言うわけで、wp-settings.php を読んでいると、以下の記述を発見。
if ( file_exists(WP_CONTENT_DIR . '/object-cache.php') ) require_once (WP_CONTENT_DIR . '/object-cache.php'); else require_once (ABSPATH . WPINC . '/cache.php');
おぉ！cache.php を改良して wp-content 直下に object-cache.php と言う名前で置いておけば良いのか。
これなら WordPress のコアコードに手をつけないでイケる。
バージョンアップ時も安心だ。
….これが冥府魔道の入り口だとは、その時は気づきませんでした。
続きを読む
さて、昨日の続きです。
さて、さらにゴニョゴニョして、現在は
- トップページ 69 queries. → 34 queries.
- シングルページ 35 queries. → 23 queries.
になりました。
ゴニョゴニョの詳細は、また次回。
と言っておりましたので、そのゴニョゴニョの部分の説明。
一言で言えば、「投稿の付属情報のキャッシュをWebサーバにファイルとして持つ」プラグインを作りました。
まだまだ改良の余地は有りますが、とりあえず現状の状態で結構満足の行く仕上がりになってます。
このプラグインを稼動させ、キャッシュが作成された後の query数がこちら。
確実に減ってますねぇ。いい感じです。
続きを読む