2011年12月7日水曜日

PHPのボトルネック調査方法[Web系一人AC2011]

昨日は、ツレと布団の取り合いに負けた結果、体調不良で死にました。OMG...。
いい年して何たる失態。すみませんでした。

気を取り直して今日の記事。
今日の記事はSymfony2...ではなく、PHPのボトルネック調査方法について、です。
検証用のコードが一部間に合わなかったため、予定を変更してお送りさせていただきます…。

皆さん、PHPで作ったWebシステムのボトルネックって、どうやって調査してますか?
割と「コレ!」と言う手段を聞かなかったので、ちょっと自分が調査するときのポイントをまとめてみました。
まずは、全体的にざっくりと、どんなツールを使って見ているのか?

それでは、本題に参りましょう。


■どのリソースが重たいのかチェック
ブラウザ上からどのリソースの取得に時間がかかっているのかを調査します。
ここで利用するのが、FireFoxならFireBug、Chromeならデベロッパーツールです。
(デベロッパーツール=右クリックして「要素を検証」を選ぶと出てくるアレ)
得に、Networkタブを良く利用します。
実際に読み込んだすべてのリソースを、どの順番でどのくらい時間をかけて読み込んだのか?等が見れます。
ここで、実際に読み込みに時間がかかっているリソースを絞り込みます。

■関連するログを追跡
基本ですが…。
サーバ上で取っているログを一通り追います。
とくに、MySQL環境にてマズいSQLが問題になっている場合、slow.logはとても参考になります。
まれに、slow.logにたくさんクエリログが残っているのに放置しているプロジェクトなんてものもあります…。オソロシイ。
SQLに問題がある場合、大抵ログからもはっきりと追えるので、ここで原因がはっきりすれば、DBまわりのチューニングを行い、実際の効果を一度見てみても良いと思います。
時間帯によって重い時間帯がある、と言う場合、munin等リソースをグラフ化して見れるツールを入れておくと役に立ちます。

■試験環境で再現する場合は、本番を想定した負荷をかけながらやる
処理の内容や使っているライブラリによっては、一定以上の負荷があって始めて再現するようなボトルネックも多くあります。
あらかじめ、JMeter等のツールを利用して、本番を想定した負荷をかけながらチューニングしていきます。
※試験環境によっては、JMeterで負荷をかけすぎると同じ回線/サーバの利用者に迷惑がかかる可能性もあるので、気をつけてくださいね。
※くれぐれも、本番稼働中のサイトや他所のサイトに打ち込まないように。

■Xdebugのプロファイラを利用する
PHPスクリプトに対するプロファイラです。
これで、実際のどのメソッドのどのコードで時間がかかっているのか?を調べることができます。
ボトルネックがありそうなコードを見つけたときに、すぐに生のソースを見て重たそうなコードを目視で調べて直す、という行動を取ってしまう人も結構見てきましたが、
実際のボトルネックは目に見えない部分にあるケースもあるので、ちゃんとプロファイラでチェックしたほうが、経験上回り道になりません。
Xdebugが導入済みなのであれば、php.iniのxdebug.profiler_enableをOnにすると利用できます。
※プロファイリングするときは当然、普段以上に負荷がかかるので、本番サイトでONにしないように。
また、プロファイラの吐いたログは、単体では可読性にかけるので、GUIで表示してくれるツールを利用します。
私は、Linux環境だということと、コールグラフ等がグラフィカルに表示されるのがうれしいので、KCachegrindを使っています。



JavaやObjective-c(これはWeb系ではありませんが…)だと、割とボトルネック調査やプロファイラの使い方についての記事が多いのですが、いまいちPHPには無かったので挙げてみました。
自己流の部分が多く、当然これが最善とは言えませんが、参考になれば、と思います。

0 件のコメント:

コメントを投稿