前回のOS編はほぼ改善なしで、相変わらずトップページが3秒かかる状態。早速今回はDB周りで改善余地がないかを見ていこうと思う。まずDBがローカルかリモートかで変化するか確認したところ、mysqlをwordpressが動いているサーバと一緒にするだけで、処理時間が1秒超縮まり、2秒弱で処理できるようになった。もともとクラウドの内部通信は品質低いと思っていたが、これほどとは。。。

とはいえ、mysqlをローカルにしか置けないというのも困るので、DBとの接続確立が遅いのか、データ転送が遅いのかを一応絞り込む。mysql接続をphpのmysql_pconnect()に置き換えて改善するかどうか。結果としてはmysqlの永続接続にしてもまるで改善が見られなかった。つまり遅いのはmysqlのデータ転送ということになる。

現時点では、数える程度のページビューしかない過疎サイトなので、1号機にwordpressとmysqlを一緒に配置してしまう。負荷低いのに何で2台も使っているの、とか悲しくなる事は聞かないようにｗ2号機の方もwordpressと非同期レプリケーションによるスレーブDBを用意して、ローカルのスレーブDBを参照できるようにする。

当然、2号機に更新が入ってしまうと2つのDB間の整合性が崩れるので、スレーブDBには読み出し専用アカウントを用意して接続に使う。『Count per Day』を停止させれば、読み出し専用アカウントでも問題なくページの表示を行えたので、とりあえずこの構成で。

DBの通信をチューニングするにはDBのデータをキャッシュするのが効果的。wordpressプラグイン、もしくはproxy辺りのキャッシュでmysqlへの通信を減らせたら2号機も1号機側のマスターDBを見るように戻すつもりだ。クラウドの内部通信はメンテなら問題ないけど(遅いけど)、サービスの処理中では使わない方がよさそうということで。まだまだ遅いとはいえ、今回のチューニングでトップページの表示は2秒弱に改善した。次回へ続く。