仕事で Amazon EC2 使うことが増えてきたこともあって、このサイトのサーバも Amazon EC2 のマイクロインスタンスに移行しました。
移行作業自体は、簡単。
の5ステップです。
以下、メモがてら作業ログを書いておきます。
VPS – VPS 間での WordPress のお引越しの参考になれば幸いです。 続きを読む
さくらの共用サーバから、め組のVPSに移行した際に設定した項目のメモです。
大まかにはこんな感じ
2.5以前の WordPress には Object Cache という機能がありました。
最近の WordPress では、この機能はデフォルトでは使えない状態になっているのですが、wp-content フォルダに object-cache.php というファイルを置き、wp-config.php に "define(’ENABLE_CACHE’,true);" を追加することで、この機能が使用できるようになります。
この object-cache.php は、WordPress のコアには含まれていないので、どこからか調達してくる必要があります。
バックエンドに何を使うかにも寄りますが、ファイルや memcached に Cache 情報を持たせるモジュールが提供されています。
参考URL:
で、この object-cache.php を書いてしまえば、Memcached やファイルだけでなく、軽量データベースライブラリ Tokyo Cabinet なんかもバックエンドのDBとして利用できるのです。
ってなわけで、レンタルサーバに Tokyo Cabinet をインストールして、WordPress から利用してみましょう。
続きを読む
このサイトを設置している、さくらインターネットのサーバOSが FreeBSD 7.1 にバージョンアップされました。
その際 MySQL も 4.0.x と 5.1.x を選択できるようになりました。
てなわけで、WordPress で使用する DB を MySQL4系から5.1系に移行したわけなんですが、文字コード周りでちょっとハマってしまったので、メモを残しておきます。
今回ハマったのは、"〜"(波ダッシュ)等の文字コードが Win系のUTF-8と標準UTF-8で異なる問題（いわゆる波ダッシュ問題）。
とりあえず、エクスポートした過去エントリのデータを文字コード変換して、さらに今後のエントリのためにForce Wave Dashプラグインを導入しました。
続きを読む
さて、前回、オブジェクトキャッシュの効率化に着手して、モノの見事に失敗した私ですが、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数がこちら。
確実に減ってますねぇ。いい感じです。
続きを読む
過去にも何度かパフォーマンスチューニングを施してきたウチのサイトですが、まだまだトップページの表示が遅い。
ひょっとすると query 数が多いんじゃないか？とは思っていたのだが、あらためて他の WordPress で作成されたサイトと比較してみると、ウチのサイトは明らかに query 数が多い。
SAKURA のレンタルサーバでは、 MySQL サーバと Apache サーバが別のサーバなので、query 数が多いのは、パフォーマンス的に不利だ。
（参照：WordPressの不要なプラグインを外してチューニングする記事のメモ (blog@browncat.org)）
これは、なんとかせねばだ。と言うことで、プラグインを止めたり改良したり、結果をキャッシュに持ったりしてみました。
続きを読む
WordPress 2.6.2 がリリースされたのでアップデート。
今回は、yutaka さんのエントリ(WordPress2.6.2 – Binsan's Cafe)を参考にして、差分ファイルだけを入れ替え。
続きを読む
WordPress 2.6.1 がリリースされたのでアップデート。
今回のアップデートはバグフィックスが主とのこと。
導入済みのプラグインでは、特に問題は発生しなかった。
一応、ざっと確認して問題は無さそうだが、何かあれば教えてください m(_ _)m
# と言っても、しばらく出張のため、サイト管理はできないので来週以降の対応になるのだが…