Improvement with xhprof and php-quick-profiler

Transcript

1. Improvement with xhprof
   and php-quick-profiler
   2017.02.17
   社内勉強会
   @nakamura_tsuyo4
   

   View Slide

2. Agenda
   経緯
   調査するに至った経緯
   使ったツール
   調査する時に使ったツールや設定
   等
   調査〜結果〜考案
   調査結果から考えられる原因や改
   善策など
   対策
   最終的にどんな施策を行ったか
   結果
   行った施策がどうだったかの評価
   まとめ
   振り返って見てどこが良かったか、
   まだ改善の余地はあるか等
   

   View Slide

3. 経緯
   ▪ ガイア砲ショック 当時の対応はホント泣けた
   ▪ あらゆる面を改善していかなきゃいかん
   ▪ PHPのPerformanceが低すぎる問題を少し手をつけるか
   ▪ `pmap`コマンドからサーバで動いているプロセスのメモリマッピングを見
   せて貰った
   ▫ `anon`=匿名メモリが多かった
   ▫ php-fpmの再起動直後と数日運用してからの`pmap`の結果から
   やっぱり`anon`=php側でメモリを多くくってるなぁーと分かった
   ▪ PHP5.6に最近したし、FWもFPMもnginxも比較的新しいし、自分たちで
   作ったどこかの処理が原因なんだろうなー
   ▪ 時間取って向き合うと決める
   非公開
   非公開
   

   View Slide

4. ▪ Newrelic使ってるけどFuel対応してなくて詳細が見えない
   ▪ 色々ググりながら試行錯誤
   ▪ `xhprof`と`php-quick-profiler`の２つを使って行くことが良さげ
   ▪ `xhprof`はpeclからinstall
   使ったtool
   xhprof
   php-quick
   -profiler
   

   View Slide

5. xhprof
   ▪ `xhprof`はpeclからinstall
   ▪ Php-fpmのconfigで有効化
   ▫ /etc/php.d/xhprof.ini ->
   ▫ xhprofのweb設定------>
   ▪ public/index.phpの改修---->
   [xhprof]
   extension=xhprof.so
   xhprof.output_dir="/var/log/xhpro"
   Cp -a /usr/share/pear/xhprof_lib /user/local/nginx/xhprof/ (http公開領域)
   Cp -a /usr/share/pear/xhprof_html /user/local/nginx/xhprof/ (http公開領域)
   if (function_exists('xhprof_enable')) {
   xhprof_enable();
   }
   // Boot the app...
   require APPPATH.'bootstrap.php';
   

   View Slide

6. php-quick-profiler
   ▪ 元々fuelphpではconfigの変更だけで利用可
   ▫ config/db.php ----------------> 'profiling' => true,
   

   View Slide

7. other
   ▪ Xhgui
   ▫ うまくinstallできず断念
   

   View Slide

8. Profiling
   Performance
   ・php-quick-profiler
   ・xhprof
   

   View Slide

9. Result - php-quick-profiler
   ▪ どの画面を表示しての定常的にMemory Usedが大きい...
   ▫ アクセスの度に動く共通ロジックの中が怪しいなぁ
   非公開
   

   View Slide

10. Result - xhprof
    ▪ 一番重い赤の部分を発見
    ▫ でもFWのcore部分で改修するにも影響範囲がデカイ
    ▪ その手間=赤マル部分で毎度通過するメソッドを発見
    ▫ Coreクラスを継承している子クラスが動いてた
    

    View Slide

11. Result - xhprof
    ▪ 前のページの赤マルで囲った処理はEWall%でソートしても上位にあがる
    ▫ 改善すると効果高いかも
    ▪ `preg_match`関数も重い
    非公開
    非公開
    

    View Slide

12. Coreに手をつけるのは最終手段
    影響範囲も大きくなってリリースまでのリードタイム
    も長くなる。そもそももっと出来ることがあるはず
    だ!!
    対応方針 2つ
    共通ロジック箇所を見直す
    アクセスの度に稼働するロジックを見直すと当然
    効果が高いし、全体的に PHP遅い評価だったの
    で見直すべき所はこの辺だなー
    

    View Slide

13. 対応 -1-
    ▪ アクセスの度に動くAgent classの見直し
    ▫ xhprofの指摘箇所
    ▫ Coreクラスのextendを止めた
    ▫ 親クラスのmethodを使ってないし
    ▫ FWの仕様でAutoloader設定されているAgentクラスは親クラスを辿
    り_initが毎回自動で走るようになってた
    ■ 使って無いのに無駄に動いている
    

    View Slide

14. 対応 -2-
    ▪ `preg_match`関数でなくても良い箇所は`strpos`に置き換えた
    ▫ xhprof指摘箇所
    ▫ 公式より
    ▫ Tip Do not use preg_match() if you only want to check if one
    string is contained in another string. Use strpos() instead as it
    will be faster.
    

    View Slide

15. 対応 -3-
    ▪ Cookieの活用
    ▫ どうしても`preg_match`を使わなければいけない場面はあるので
    cookieを活用して`preg_match`の利用頻度を下げた
    

    View Slide

16. 結果
    

    View Slide

17. 結果
    

    View Slide

18. 結果
    

    View Slide

19. 結果
    

    View Slide

20. まとめ
    ▪ Agent Classの改修が結果的に一番効果あった
    ▪ Coreクラスの部分を除外して考えた事でリリースまでの
    リードタイム短縮になって結果良かった
    ▪ 絶対に改善するぜという心意気重要!!
    ▪ そこまで難しいツールで無かったのでもっと早くやれば良
    かったという結果論
    ▪ 定常的に見える化するとよりよいなぁ
    ▫ チームで改善ができる
    

    View Slide

21. THANKS!
    Any questions?
    

    View Slide