サーバーのエラーログを見てたら、なんだか WordPress で良く転けてる事があった。
で、エラーの内容で検索してみても、特にコレと言ったモノにはたどり着けない。
WordPress 自体なのか、最近入れたプラグインのどれかが原因なのか、PHP がサッパリの僕には、これらのエラーは全て呪文にしか見えない（汗）
誰か。。。サーバーと PHP に詳しい人はおらぬか。。。
気を取り直して、特にひどく転けてる時間帯について更にサーバーのログを調べてみたら、確かにその時間帯はメモリが食い潰されててアラートが出てる事が判った。
マジかよ。。。プラン上げたのにまだ足りぬと申すか。。。
ソニータイマーのように、頃合いを見てプランをあげさせるタイマー発動？（曝）
で、途方に暮れながら Google を漂流するうちに、いつしかひとつの策に辿り着いた。
それが、Wordpress 2.6.x 高速化する、2つの大原則 と クエリ結果のキャッシュ。
この設定により、WordPress の表示をキャッシュ化できるらしい。
確かに WordPress は PHP なので、アクセスの度に毎回サーバーがシコシコ処理させられるから、コレは大きな負荷に違いない。それをキャッシュで表示できるようになれば、これはかなりの負荷軽減になりそうだ。
で、そのキャッシュ化を行うためには、MySQL のクエリキャッシュと、WordPress のコンテンツキャッシュの設定が必要とのこと。
ところで今回の目的はエラーログの原因を解決する事だったが、それもこれも WordPress によるリソースが原因に繋がっている事には間違いなさそうなので、まずは上記のサイト情報を元に、サーバーと WordPress を設定してみることにした。
詳しい手順は上記のサイトを見た方が確実ですが、とりあえず僕の備忘録をここに残します。
まずは MySQL（データベース）のクエリキャッシュの設定
-
SSHを使ってサーバーに root 権限でログイン。
root 権限じゃないと設定ファイルが編集できないので注意コマンド
$ su ←root権限でログインするためのコマンド（スーパーユーザ） password: ←コレが出るのでrootパスワードを入力（表示はされない） # ←root権限に切り替わるとプロンプト記号が$から#に切り替わる
viを使って/etc/my.cnfへ以下の記述を追加。
[mysqld]
query_cache_limit=1M
query_cache_min_res_unit=4k
query_cache_size=24M
query_cache_type=1上書きして vi を終了。 vi は Windows のメモ帳みたいな Unix のエディタ
コマンド
# vi /etc/my.cnf ←viで/etc/my.cnfを開くコマンド i ←viを編集モードに切り替えるキー ここで上記のように入力 [Esc] ←viをコマンドモードに戻すキー :wq ←viを上書き終了するコマンド
phpMyAdminで変数の確認。
query_cache_size含め上記での変更が反映されたかのチェック。-
mysqldサービスを再起動。
僕はサーバー管理ツールから再起動したが、コマンドなら以下のようになる。# /etc/init.d/mysqld restart
続いて、WordPress のコンテンツキャッシュの設定
- File-Based Extension to the WordPress Object Cache へ行って、
File-Based Object Cache Extensionをダウンロード。
解凍したobject-cache.phpを WordPress の/wp-content/へ放り込む。 - WordPress の
wp-config.phpをエディタで開いて、一番上あたりにdefine('ENABLE_CACHE',true);を追記して上書きアップロード。
- WordPress の
/wp-content/の中にcacheと言うディレクトリを作成し、アクセス権を777に設定。
以上で、WordPress がキャッシュ化され、サーバー負荷が軽くなると言う話。
但し、設定によってはキャッシュが優先されて新しいデータが反映されにくくなるらしいので注意とのこと。
これは my.cnf の設定値を変えながらオペレーションすると言うことなのかな。
とりあえず、なんとなく早くなったような気がする。
具体的にどれくらい早くなったのかは、また調べ方を調べてみよう（曝）
