Mirage-OC Commercial

2010/03/22

軽量化について

カテゴリー: >サーバーメンテ — admin @ 18:32

当方の鯖は非常に古いシステムで稼動しているため処理速度がブロードバンドについていけないのは一つの問題です。
ですが、不況である昨今に個人で新規鯖を導入する余裕が無いため、幾つかのアプローチを健闘します。

◆PHP APC
これは結構前に導入済みで、PHP の処理が若干向上したと感じられました。
表示については大差ないですが、記事の保存など PHP で負荷が上がる部分には良い影響が出ました。

過去ログから抜粋ですが、導入ログを残します。

# cd /usr/ports/www/pecl-APC
# make
# make install
...
Then restart your web server and consult the output of phpinfo().
If there is an informational section for APC, the installation was
successful.
******************************************************************
===>   Registering installation for pecl-APC-3.0.19
******************************************************************

The following line has been added to your /usr/local/etc/php/extensions.ini
configuration file to automatically load the installed extension:

extension=apc.so

******************************************************************
# grep apc /usr/local/etc/php/extensions.ini
extension=apc.so
# /usr/local/etc/rc.d/apache22 restart

phpinfo before

Document Length:        52178 bytes
Requests per second:    937.45 [#/sec] (mean)
Time per request:       68.270 [ms] (mean)

phpinfo after

Document Length:        55233 bytes
Requests per second:    946.50 [#/sec] (mean)
Time per request:       67.618 [ms] (mean)

◆WP Super Cache
2.9 にアップデートした後プラグインを導入するには若干変更が必要そうです。
なぜなら、個人鯖ではレスポンスが悪く http リクエストで失敗するからです。
レンタ鯖、企業鯖では考慮しなくていいかもしれませんが、プロキシの無い環境では必要かもしれません。

やけに早いエラー通知のため接続関係のものを探してみると wp-includes/http.php が管理しているようです。
サラッと読んでみると http_request_timeout が 5sec というかなり狭域になっています。
これをもう少し猶予のある時間に変更します。

# diff -U0 http.php.old http.php
— http.php.old 2010-03-22 18:19:13.000000000 +0900
+++ http.php 2010-03-22 18:14:21.000000000 +0900
@@ -226 +226 @@
- ‘timeout’ => apply_filters( ‘http_request_timeout’, 5),
+ ‘timeout’ => apply_filters( ‘http_request_timeout’, 30),

これで単純なタイムアウトでの切断は免れます。

プラグインの新規追加で WP Super Cache を導入します。
導入直後は有効になっていないのでキャッシュを有効にします。
導入段階だったので他の設定は変更していません。

WP Super Cache を選んだのは 携帯プラグイン が wp-cache 対応でアップデートされていたからです。
個別に Feed なんかも導入しようかと思いましたが、設定を見た限り Feed も適用範囲内っぽいので保留しました。

忘れずにサブドメインでも有効にしておきましょう。

Virtual Multiblog 導入後のアップデート

カテゴリー: WordPress — admin @ 17:57

以前導入記事を書いて、その後着々と WP 本体をアップデートしていたが Virtual Multiblog 導入後のアップデート手順が記録されていなかったので手順をまとめておく。

◆ソースの入手
本家日本語版を入手します。

# wget http://ja.wordpress.org/wordpress-2.9.2-ja.zip

◆作業ディレクトリ展開
マルチブログのための設定が必要なので作業用ディレクトリとして展開します。

# unzip wordpress-2.9.2-ja.zip
# mv wordpress wordpress_new
# mv wordpress_new /usr/local/www/
# cd /usr/local/www/

◆VMB 設定ファイルのコピー
直下の設定ファイルをコピーします。

# cp wordpress/wp-config.php wordpress_new/wp-config.php
# cp wordpress/wp-config-vmb.php wordpress_new/wp-config-vmb.php

VMB をコピーします。

# cp -R wordpress/wp-content/multiblog wordpress_new/wp-content/

これでマルチブログの設定は複製できました。
構成はそのままであるはずなので手を加える必要はありません。

続いて Virtual Multiblog 以外のファイルを移行します。
ここからは wordpress のアップデートとなるので環境によって違いがあるかもしれません。
自サイトの管理目的メモなのでログしておきますが個人設定なので必要に応じて置き換えてください。

◆ユーザーコンテンツの移動
シンボリックリンクで格納してあるアップロードコンテンツ(画像)の適用。

# ln -s /home/username/uploads wordpress_new/wp-content/uploads

シンボリックリンク貼り忘れで露出したコンテンツの複製。

# cp wordpress/wp-content/swfobject.js wordpress_new/wp-content/
# cp wordpress/wp-content/player-viral.swf wordpress_new/wp-content/
# cp wordpress/wp-content/yt.swf wordpress_new/wp-content/
# cp -R wordpress/wp-content/skins wordpress_new/wp-content/

◆プラグインの移動
これもシンボリックリンクで集約するのが適切だと思う。

# cp -R wordpress/wp-content/plugins/counterizeii wordpress_new/wp-content/plugins/
# cp -R wordpress/wp-content/plugins/ktai_style wordpress_new/wp-content/plugins/
# cp -R wordpress/wp-content/plugins/openid wordpress_new/wp-content/plugins/
# cp -R wordpress/wp-content/plugins/syntaxhighlighter wordpress_new/wp-content/plugins/
# cp -R wordpress/wp-content/plugins/wp-cumulus wordpress_new/wp-content/plugins/
# cp -R wordpress/wp-content/plugins/wp-json wordpress_new/wp-content/plugins/

◆テーマの移動
これもシンボリックリンクで集約するのが適切だと思う。

# cp -R wordpress/wp-content/themes/aeros wordpress_new/wp-content/themes/
# cp -R wordpress/wp-content/themes/carrington-blog wordpress_new/wp-content/themes/
# cp -R wordpress/wp-content/themes/dark-marble wordpress_new/wp-content/themes/
# cp -R wordpress/wp-content/themes/dark-smoke wordpress_new/wp-content/themes/
# cp -R wordpress/wp-content/themes/iblog2 wordpress_new/wp-content/themes/ # cp -R wordpress/wp-content/themes/jonk wordpress_new/wp-content/themes/
# cp -R wordpress/wp-content/themes/sliding-door wordpress_new/wp-content/themes/

ファイル操作でできる移行準備が完了しました。
残りはプラグインの無効化とテーマのデフォルト設定です。

ここからは SQL の流し込みがシェル上の作業単純化に必要かと思いますが、管理サイトが少ないため直接手を下した方が確実と判断します。
参考までに DB 基底テーブルの構造を記述しておきます。

options:{
	active_plugins:{
		a:8:{
			i:0;s:19:"akismet/akismet.php";
			i:1;s:27:"counterizeii/counterize.php";
			i:2;s:25:"ktai_style/ktai_style.php";
			i:3;s:17:"openid/openid.php";
			i:4;s:39:"syntaxhighlighter/syntaxhighlighter.php";
			i:5;s:25:"wp-cumulus/wp-cumulus.php";
			i:6;s:19:"wp-json/wp-json.php";
			i:7;s:41:"wp-multibyte-patch/wp-multibyte-patch.php";
		}
	}
	current_theme:aeros
}

plugins では有効にするプラグイン数を a で、プラグインのナンバリングとリンクの文字列長を i s で、リンクする URI を文字列で指定しているようです。
これから派生するテーブルもあるので、構造を把握せずに直接変更するのは怖いです。

◆アップデート
各サイトでプラグインとテーマを操作します。
準備が出来たらファイルを完全移行します。

# mv wordpress wordpress_old
# mv wordpress_new wordpress
# chown -R www:www wordpress

あとはテーマやプラグインを元に戻せば完了です。

Powered by WordPress