Code Profilingとは
Wikipedia より:.Code profiler は、一般に、ただファンクションコールの頻度と持続時間だけを測るパフォーマンス分析ツールであるが、広範囲のパフォーマンスデータを集めることができるいっそう包括的な profilers に加えて他の特定のタイプの profilers (例えばメモリ profilers )がある。あなたがcode profilingを使わないなら、あなたはどんなパフォーマンス問題に気付かないかもしれない。 一般的にプログラマーがPHPのprofilingをする場合、WordPressも含めて xdebug が使われている。もしあなたが wordpress テーマを開発するのであれば、通常あなたが必要とするprofilingツールは MySQL profiler で十分だ。
WP MySQL Profiler
テーマと plugin 双方の開発者のためにこの単純な MySQL Profiling plugin を作った。 プラグインを一度インストールするだけで、 MySQL 統計値はページフッターにおいて利用可能になる。Installation
- WP MySQL Profiler をダウンロードし展開する
- wp-includes directoryにある wp-db.php を wp-db-backup.php にリネームする.
- 展開した wp-db.php をwp-includes directoryにアップロードする
- wpSqlProfiler.php を wp-content/plugins/ にアップロードする
- wp-config.php のdefine (‘WPLANG’, ”); を探し、次のコードを追加する
define('SAVEQUERIES', true);
- 管理パネルから “WP MySQL Profiler” plugin を有効にする
Usage
admin としてログインしているとき、あなたはページフッターにおいて MySQL クエリーの細部を見るであろう。この時クエリーと時間全体の両方を監視する必要がある。 毎回テンプレートにコードを加えるたびに、最適化された機能、あるいはコードスニペットが使われたかどうか調べるためにprofileしなくてはならない。
もし負荷が高い全体のクエリーに気付いたなら、クエリーががどこから始まったか調べるために(いっそう低階層まで) backtrace をチェックし 最適化されていないコードを取り除くか、別のコードに置き換えることが必要です。
The Backtrace
profiler からの出力で3番目のが最も有用なインフォメーションを与えている。上記の例で、MySQL のクエリーを生み出すことに関与した関数を示している。最初にthemes/default/single.php の7行目にある get_header() がwp_head()がcallされさらに、wp_head() は kubrick_header_display() から、最後に functions.php の83行目のget_option() からcallされている。
リンク”Show Full Trace”に注目してください。シンプルにするために、 profiler はデフォルトですべてのファンクション・コールを示すわけではないが、その代わりに、 plugins とテーマからのファンクション・コールを決定しようとする。plugins とテーマをコーディングするとき、ファンクション・コールがその中(pluginやテーマ)に由来するという状態であり、関係していると想定することは十分意味のあることだ。
Final Steps
もし、テスト環境ではなく本番環境で最適化をしているなら、公開する前に次のことを確実に実施しなければならない。
- wp-db.php を削除し保存してあった wp-db-backup.php を wp-db.php にリネームすること
- wp-config.phpに追加したdefine(‘SAVEQUERIES’, true) を削除すること
- MySQL Profiler pluginをコントロールパネルから無効にすること
原文:MySQL Profiler Plugin for WordPress
0 件のコメント:
コメントを投稿