php-eaccelerator のキャッシュをtmpfsにする

php-eaccelerator (eAccelerator) のキャッシュをtmpfsというファイルシステムに変更してみました。 tmpfsとは、メモリ上に作成するファイルシステムで、アクセススピードの向上が期待できそうだと思ったからです。

php-eaccelerator のキャッシュが、/var/cache/php-eaccelerator に作られている場合は、tmpfs を作成して、この /var/cache/php-eaccelerator にそのtmpfsファイルシステムをマウントします。手順は次の通りです。

キャッシュディレクトリの場所は、php-eaccelerator の設定ファイル /etc/php.d/eaccelerator.ini に次のように記述されています。 eaccelerator.cache_dir = “/var/cache/php-eaccelerator”

1．キャッシュを一旦削除する [root ~]# cd /var/cache/php-eaccelerator [root ~]# rm -fr * 2．tmpfsを作成してマウントする

サイズは、現在のキャッシュサイズを30MBに設定していますので、64MBとします。

[root ~]# mount -t tmpfs -o size=64m /dev/shm /var/cache/php-eaccelerator

これだけです。 ちなみに作業の間は、httpdを落としておいた方がいいでしょう。

2012年9月9日 22:00　SATOSHI　カテゴリ: php, WordPress　タグ: , , , , , 　コメントは受け付けていませんm(__)m　

PHP～パフォーマンス向上策(続報２)

『PHP～パフォーマンス向上策(続報)』に記載した eaccelerator.shm_size の設定を、デフォルトの「OSに任せる」設定戻しました。

eaccelerator.shm_size = “30” ↓ eaccelerator.shm_size = “0”

これで、現状は 32MB が割り当てられています。 この値については、冒頭の記事掲載当初は 32MB の指定はできなかったように記憶していますので、恐らく ServersMan@VPS がバッファキャッシュを使えるようになったことが背景にあるのだと考えています。

2012年2月5日 10:06　SATOSHI　カテゴリ: php, WordPress　タグ: , , , , 　コメントは受け付けていませんm(__)m　

PHP のパフォーマンスチューニング

LAMP環境(Linux-Apache httpd-MySQL-PHP)におけるWebアプリケーションのパフォーマンスチューニングにおいて、ここではPHPに関するポイントを整理しておきたいと思います。 なお、記事投稿時点でのPHPは、バージョン5.3.9です。

1．実行コードキャッシュ

コンパイル言語ではなくインタープリター言語であるPHPでは、同じコードの構文解析・コンパイルを繰り返さないことがパフォーマンス上の重要なポイントです。

そこで、構文解析・コンパイル後のコード(実行コード)をキャッシュすることで、同じコードを使用する二度目以降のリクエストについては、キャッシュされた実行コードを使用することができるようになります。

そのような実行コードのキャッシュ機能は、

eAccelerator APC(Alternative PHP Cache)

を利用することで実現できます。

eAcceleratorについては『PHP～パフォーマンス向上策』『PHP～パフォーマンス向上策(続報)』をご覧ください。

2．PHPの設定

下表のように、php.iniのパラメータのいくつかを適切に設定することが重要です。

phpiniの変更後は、httpdを再起動もしくは設定再読込をして、設定を反映させる必要があります。

php.iniパラメータ 設定の説明 設定例 register_globals 無効にする。 register_globals = Off magic_quotes_gpc 無効にする。 magic_quotes_gpc = Off magic_quotes_runtime 無効にする。 magic_quotes_runtime = Off magic_quotes_sybase 無効にする。 magic_quotes_sybase = Off always_populate_raw_post_data 無効にする。 always_populate_raw_post_data = Off output_buffering 有効にする。推奨設定値は4096バイトとなっています。 output_buffering = 4096（単位：バイト） realpath_cache_size 必要に応じて設定する。PHPがオープンするファイル数が多い場合には、この値を増やすとファイル操作のパフォーマンス向上の効果が期待できます。 realpath_cache_size = 16k（単位：バイト） realpath_cache_ttl 続きを読む »

2012年1月15日 16:11　SATOSHI　カテゴリ: php　タグ: , , 　コメントは受け付けていませんm(__)m　

レスポンス悪化のため、CentOS 32bitに戻しました！

当サイトはServersMan@VPSで運用していますが、CentOS 64bit版が提供されたことで、32bit版から64bit版へ移行したのですが、5月初旬の移行当初は問題はありませんでしたが、次第に各種コマンド、当ブログを含めた各種サービスのレスポンス(パフォーマンス)が悪化することが徐々に多くなり、現在はほぼ常時レスポンスが悪い状況になりました。

 

32bit版と比較して64bit版は、概ね十倍程度から時には数十倍掛かります。 例えば、sshログイン/ログアウト、yum、ll、WordPressブログなどが主なものです。

 

ちなみに、私は32bit版と64bit版の2サーバ(両方ともStandardプラン)を使用していますので、同時にレスポンス比較ができます。双方、インストールパッケージや起動サービス等の環境は同等です。

 

DTIのServersMan@VPSサポートからは、仮想サーバ収容機器レベルでの負荷状況について、「64bit版ホストOS側で、Load Averageに関しては、その他の機器に比べ、平均して高い状態ではございましたが、常に動作に影響を与えるほどの負荷は生じておりませんでした」との回答がありましたが、十倍～数十倍のレスポンスが掛かる点については「内部情報のため、詳細な値は控えさせていただきたく存じますが、各機器の状況を比較した結果でございます」と論理的根拠を示してもらえませんでした。

 

実際に私と同じオペレーションをしていないにも関わらず、回答結論の論理的説明を求めても、そのレベルです。

 

一般的なWebサイト上での報告にあるパフォーマンス評価でも、他社VPSと比較して、外からのNWレスポンスなどは良い方との評価もありますが、UnixBenchなどは総じて悪い結果でバラツキも大きいようです。コストパフォーマンスは悪くないと思いますが、OpenVZによる「ホストOS上での仮想化」のデメリット(リソースの取り合いによる弊害)が表出したのでしょう。やはり「ハイパーバイザー上での仮想化」の方が安定的なサービス提供に剥いているという通説通りなのでしょう。仮想サーバの高密度化が可能なので、コストダウンをしやすいのですが、そのあたりを十分理解した上で、各社VPSサービスの仕様を認識すべきだと思います。

 

なお、回答の中には、/proc/user_beancounters の failcnt がカウントされている点にも言及がありましたが、32bit版の方がfailcntのカウントは大きな数値になっていますし、レスポンス悪化の一因と断定する根拠は提示されませんでした。内部機密情報だそうです。

 

64bit版ホストOSは、多くの人が64bit版を使用する(移行する)ケースが多いのでしょう(私見です)。その分、32bit版ホストOSは空いているのかも知れません(これも私見です)。

 

などと考えた結果、当サイトの運用基盤を32bit版に戻しました。

 

レスポンス(パフォーマンス)は。。。まあ普通です。。。

 

2011年6月11日 09:58　SATOSHI　カテゴリ: ServersMan@VPS　タグ: , , 　コメントは受け付けていませんm(__)m　

WEBO Site SpeedUpの悪影響？

WEBO Site SpeedUpの導入を行ったあと、WordPressに良くない変化が認められましたので、報告します。

(1) WordPressのダッシュボード表示 ダッシュボードトップ画面で、いくつかのウィジットが表示されなくなった。

(ウィジットの表示状況) 現在の状況 ・・・OK 最近のコメント ・・・OK 被リンク ・・・表示されなくなった クイック投稿 ・・・OK 最近の下書き ・・・表示されなくなった WordPress 開発ブログ ・・・表示されなくなった WordPress フォーラム ・・・表示されなくなった プラグイン ・・・表示されなくなった

(2) ScrollTo Top プラグイン ページトップへ戻るための ScrollTo Top プラグインによるアイコンイメージが表示されなくなり、機能しなくなった。

原因が WEBO Site SpeedUp にあるかどうかは明確ではありませんが、WEBO Site SpeedUp の導入を境にして発生しています。 WEBO Site SpeedUp のバージョン1.4.0 が、WordPress 2.9.2 までしかテストしていないようですので、バージョン3 に未対応に当たる部分なのかも知れません。

ただ、WEBO Site SpeedUp の効果はバージョン3でも認められるので、今しばらくは使用していこうと思っています。

～～～～～～～～～ ウィジットの表示関数は、次のファイルに記述されている 続きを読む »

2011年4月3日 21:19　SATOSHI　カテゴリ: WordPress　タグ: , , , 　コメントは受け付けていませんm(__)m