wordpressを自宅環境からクラウド環境に移設した。クラウド上でwordpressを本番稼働させながら、諸々の整備を進めているため、わりと頻繁にchef-clientを実行したりしているのだが、その際のHTTPレスポンスが著しく劣化しているような気がしていた。実際、chef-clientしつつブラウザで触ってみると、ほぼレスポンスできてないに等しい状態が数分続く事になっている(chefの処理も遅い)。

これはさすがにまずいだろうとスループットを計測してみたところ、通常状態でもトップページの処理時間が3秒を越えており絶望的な数値。。。いくら過疎サイトとはいえ、これではお話にならないので真面目にチューニングする事にした。

まずはそのチューニングのゴールと意義を説明しておく。現時点では日々数える程度のページビューしかない過疎サイトではあるが、一応レスポンスタイムは100msec前後を目指したい。単純なロジックであればそれくらいは難しくないのと、キリがいいからｗ

では、そんな過疎サイトにもかかわらず、なぜレスポンスをそれほど気にするのか。ここで言う過疎というのは、あくまで人間的なアクセスに対する表現で、その裏では世界中から日常的に機械的なアクセスが来ている。怪しいリクエストも少なくないが、各種検索サイトのクローラーも含まれているので、これらのリクエストを無下に扱う訳にはいかない。この手の機械リクエストを捌きつつ、わずかな人間的なリクエストにも最速でレスポンスするためにチューニングが必要になるのですね。自己満足のため、という訳ではなかったｗ

第一回はOS編ということなんだけど、気になっていたのはxen-toolsの存在。GMOクラウドはxenベースなので、このパッケージを入れる事が義務づけられている。しかも、以下のページを見ると、
GMOクラウドサポートサイト『ISOから仮想サーバーの作成はできますか？』

Xen-Toolsをインストールしない場合、VMのパフォーマンスが低下するほか、メンテナンス時にライブマイグレーションを実施できず、サーバの断が発生する可能性がございますのでご注意ください。

こんな感じで、わりと強めに脅されているんですよね。このパッケージ内でどのような事が行われていて、どういう改善効果が見込めるかはちゃんと調べていないんだけど、どうせ入れる必要はありそうなので、その上で評価する。という訳で、centos6用のrpmをcentos7に無理矢理インストールしてみた。手順に倣って、xen-pv-drv-isoを該当インスタンスにアタッチする。

アタッチ後に該当インスタンス上で以下作業。

sudo su -
mount /dev/cdrom /mnt
cd /mnt/Linux
rpm -ivh --nodeps xe-guest-utilities-6.2.0-1137.x86_64.rpm xe-guest-utilities-xenstore-6.2.0-1137.x86_64.rpm
systemctl start xe-linux-distribution
systemctl enable xe-linux-distribution
ps aux | grep xe-daemon

これで『xe-daemon』というプロセスが起動していれば一応正しく動作しているんだと思う。centos7の現時点(2015年11月)のディストリビューションだと/usr/sbin/xe-linux-distributionが/etc/redhat-releaseを正しくparseしてくれないのでちゃちゃっと直しておくこと(135行目辺り)。何となくこの辺見てるとcentos7で動かす事も視野に入ってそうな気がしなくもないんだけどね。

そもそもcentos6のパッケージなのでchkconfig環境の方にも設定が入ってしまうが、systemctlで操作できるので、そちらで管理した方がよさそう。chkconfig側でも作業できなくなくはないのだが、/etc/init.d/xe-linux-distributionの動きがやや怪しく、動作確認する上でかなり混乱させられてしまった。

ともあれ動かすには動かしてみたが、残念ながら性能的には大した改善は見られなかった。あまり緻密に計測はしていないが、ざっくり50msec前後早くなったかなあという程度。3秒とかひどい分母の状態からしたら、まさに焼け石に水。これはこれで運用上必要かもしれないが、性能面での改善効果は微々たるものと判断。次回へ続く。