タグ別アーカイブ: サイト運営

Amazon EC2 マイクロインスタンスに移行

仕事で Amazon EC2 使うことが増えてきたこともあって、このサイトのサーバも Amazon EC2 のマイクロインスタンスに移行しました。
移行作業自体は、簡単。

  • 新サーバに Nginx, PHP, MySQL をインストール
  • 現行サーバから rsync で WordPress フォルダの内容を全て新サーバにコピー
  • 現行サーバの MySQL でテーブルをロックしてから /var/lib/mysql/ 以下を全部 tar で固めて、新サーバにコピー
  • /etc/my.cnf, /etc/php.ini, /etc/nginx/ 等の設定ファイルをコピー
  • ローカルPCの hosts 変更して確認取れたら DNS 変更

の5ステップです。
以下、メモがてら作業ログを書いておきます。
VPS – VPS 間での WordPress のお引越しの参考になれば幸いです。 続きを読む

め組VPSに移行後に設定した項目

さくらの共用サーバから、め組のVPSに移行した際に設定した項目のメモです。
大まかにはこんな感じ

続きを読む

WordPress Object Cache のバックエンドに Tokyo Cabinet を利用する

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 から利用してみましょう。
続きを読む

MySQL 4 から 5へ

このサイトを設置している、さくらインターネットのサーバ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 サイトのパフォーマンスチューニング (4)

さて、前回、オブジェクトキャッシュの効率化に着手して、モノの見事に失敗した私ですが、File-Based Extension to the WordPress Object Cacheなるモノを発見。
DBアクセスせずにファイルアクセスで、済ませてしまおうという仕掛けです。
要はコレ、WordPress 2.5.x 以前にあったオブジェクトキャッシュを、2.5.x 以降のバージョンでも使えるようにしてしまおうというものです。

しかも、ご丁寧にも APCXCacheeAccelerator などのPHP用の各種キャッシュモジュールが使える場合は、それ用のモノも用意してあります。
これらを利用すれば、オブジェクトキャッシュ情報をファイルに書き出すのではなく、PHP用の各種キャッシュモジュールが管理する変数キャッシュ領域にセットしてくれます。
SAKURA では PHP が CGIモードで動作しているため、PHP用の各種キャッシュモジュールがイマイチ使えないので、File-Based Extension を導入してみました。
続きを読む

WordPress サイトのパフォーマンスチューニング (3) – 冥府魔道変 –

さて、前回の続き。
すっかり 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 のコアコードに手をつけないでイケる。
バージョンアップ時も安心だ。

.これが冥府魔道の入り口だとは、その時は気づきませんでした。
続きを読む

WordPress サイトのパフォーマンスチューニング (2)

さて、昨日の続きです。

さて、さらにゴニョゴニョして、現在は

  • トップページ 69 queries. → 34 queries.
  • シングルページ 35 queries. → 23 queries.

になりました。
ゴニョゴニョの詳細は、また次回。

と言っておりましたので、そのゴニョゴニョの部分の説明。

一言で言えば、「投稿の付属情報のキャッシュをWebサーバにファイルとして持つ」プラグインを作りました。
まだまだ改良の余地は有りますが、とりあえず現状の状態で結構満足の行く仕上がりになってます。

このプラグインを稼動させ、キャッシュが作成された後の query数がこちら。

  • トップページ 42 queries. → 34 queries.
  • シングルページ 35 queries. → 23 queries.

確実に減ってますねぇ。いい感じです。
続きを読む

WordPress サイトのパフォーマンスチューニング (1)

過去にも何度かパフォーマンスチューニングを施してきたウチのサイトですが、まだまだトップページの表示が遅い。

ひょっとすると query 数が多いんじゃないか?とは思っていたのだが、あらためて他の WordPress で作成されたサイトと比較してみると、ウチのサイトは明らかに query 数が多い。
SAKURA のレンタルサーバでは、 MySQL サーバと Apache サーバが別のサーバなので、query 数が多いのは、パフォーマンス的に不利だ。
(参照:WordPressの不要なプラグインを外してチューニングする記事のメモ (blog@browncat.org)

これは、なんとかせねばだ。と言うことで、プラグインを止めたり改良したり、結果をキャッシュに持ったりしてみました。
続きを読む

WordPress 2.6.1 へのアップデート

WordPress 2.6.1 がリリースされたのでアップデート。
今回のアップデートはバグフィックスが主とのこと。
導入済みのプラグインでは、特に問題は発生しなかった。
一応、ざっと確認して問題は無さそうだが、何かあれば教えてください m(_ _)m
# と言っても、しばらく出張のため、サイト管理はできないので来週以降の対応になるのだが