1. ボトルネックの探し方
プロファイリングの考え方とツール紹介

2. 自己紹介
清水 佑吾
@yamionp
株式会社 gumi 勤務
Python歴約2年半
サーバーさわりはじめて約10年

3. 関わったもの
HTML + FlashLite
Cocos2d-x

4. アジェンダ
最適化について
ツール紹介
事例紹介

5. 使用環境
Python 2.7
Django
MySQL 5.5/5.6 (RDS)
Redis
RabbitMQ

6. 構成
DB
LB App KVS
MQ
Job

7. App
ログ
Job
エラーログ
Log

8. アジェンダ
最適化について
ツール紹介
事例紹介

9. 最適化してますか？

10. 最適化とは
システムより効率的に動作するよう変更すること

11. 最適化でよくある失敗
最初から性能チューニング
予想だけで修正

12. 予測するな、計測すべし

13. アジェンダ
最適化について
ツール紹介
事例紹介

14. ツール

15. 三種の神器
CloudWatch
JetProfiler
NewRelic

16. CloudWatch

17. カバーエリア
DB
LB App KVS
MQ
Job
全部

18. CloudWatch
AWSの提供するシステムモニタリングツール
CPU, Memory, Disk, Network I/O, LoadAverage, etc..
もっとも基本的な情報
障害時のアラートなども行える

19. JetProfiler

20. カバーエリア
DB
LB App KVS
MQ
Job MySQL専用

21. JetProfilerとは
MySQLに対するリアルタイム解析ツール
クエリやステートの種類/数/頻度/割合
スロークエリ
クエリ/テーブル毎の処理時間使用率, etc…

22. スレッド別

23. ステート別

24. テーブル別

25. クエリ種別割合

26. ロック状態

27. スロークエリ

28. NewRelic

29. カバーエリア
DB
LB App KVS
MQ
Job
アプリケーション
コード

30. NewRelicとは
アプリケーションに埋め込むプロファイラ
Java/.NET/node.js/PHP/Ruby/Pythonに対応
関数/メソッド毎の処理時間を調査可能
統計情報表示
色々なAPIを提供

31. サーバー概要
処理時間
リクエスト数
URL別遅い順 エラー率
平均レスポンスタイム

32. 処理割合
Python
外部API
Memcache
MySQL

33. URLごとの詳細
URL別リスト
URLごとの変化の推移
リクエスト数とレスポンスタイム
個別の最も遅いレスポンス

34. テキスト
APIでデプロイを記録
どのデプロイで変化があったかがわかる

35. DBもいける
処理時間
上位クエリ
上位クエリの推移グラフ
種類ごとの
割合グラフ
種類ごとの
レスポンスタイム

36. アジェンダ
最適化について
ツール紹介
事例紹介

37. ある日の夜
イベントリリース！
しばらくは問題なく動作していたが…
ページが開けない！と苦情が

38. CloudWatch
AppサーバーCPU使用
率もリクエスト数も問
題ないが．．．
DBのCPU使用率が張り
付いていた

39. 即JetProfilerを起動
ここが真っ赤だった

40. テキスト
クリック一つて即Eplain
グラフィカル＆レーティングしてくれる。
DBにくわしくなくてもいかにもダメそうな感じ

41. インデックスがなかった
特定クエリが処理時間の９割以上を占めていた
緊急メンテに入りインデックスを追加
インデックスをはったら5%以下に

42. ほとんど同じ状況で
別パターン

43. 無駄インデックス問題
特定クエリが処理時間の３割以上を占めていた
スローではないが一クエリ当たりの時間が多い
Explainしたら index merge
インデックスを削除したら100倍高速化

44. 教訓
負荷試験をしよう
負荷試験の結果で必要なインデックスだけを貼る
インデックスショットガン、だめ絶対
超オススメです

45. 最適化
十分早いが回数が多いクエリに複合キーなど
いらないインデックスを削除して高速化

46. ある日のNewRelic

48. 逆にmemcache速い！っと思ってしまった

49. Cache.get多すぎ
プレイヤーデータ->マスターデータへのプロパティ
で発生
DB分割しているとなりやすい
Join出来ないのでプロパティなどで動的につなげる
マスターデータに関してはjsonでappサーバーに配置
することで解消

50. ある日のNewRelic2

51. テキスト
Redis.getに2.5sかかった
redisのマスターでsave(メモリデータのダンプ)を止めappendonlyのみにし
スレーブでダンプするように変更する事でだいたい解消

52. Redis.get一回に2.5秒
平均では1ms(最低値)なので統計グラフには出ない。
NewRelicのTransaction Detail で発見
Redisのbgsave時に起こる（EC2だと起きやすい）

53. ほかに取れる統計情報

54. テキスト
どこに時間がかかっているか
Python:DB:Memcacheの割合が 40:1:1 程度

55. テキスト
スケーラビリティ
50req/mでも500req/mでもレスポンスタイムには変化が無い
ので遅いのは個々の処理を行っているコードや仕様の問題

56. ブラウザもわかる

57. サーバー側の処理時間の
2∼5倍はレンダリングまでにかかる

58. Androidの
絶望的遅さ
iOS（平均500ms）比で
Chromeで２倍
AndroidBrowserだと
３∼４倍強。

59. 質疑応答

60. ご静聴ありがとうございました