Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

サーバーサイドボトルネックの探し方

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

サーバーサイドボトルネックの探し方

  1. 1. ボトルネックの探し方 プロファイリングの考え方とツール紹介
  2. 2. 自己紹介 清水 佑吾 @yamionp 株式会社 gumi 勤務 Python歴約2年半 サーバーさわりはじめて約10年
  3. 3. 関わったもの HTML + FlashLite Cocos2d-x
  4. 4. アジェンダ 最適化について ツール紹介 事例紹介
  5. 5. 使用環境 Python 2.7 Django MySQL 5.5/5.6 (RDS) Redis RabbitMQ
  6. 6. 構成 DB LB App KVS MQ Job
  7. 7. App ログ Job エラーログ Log
  8. 8. アジェンダ 最適化について ツール紹介 事例紹介
  9. 9. 最適化してますか?
  10. 10. 最適化とは システムより効率的に動作するよう変更すること
  11. 11. 最適化でよくある失敗 最初から性能チューニング 予想だけで修正
  12. 12. 予測するな、計測すべし
  13. 13. アジェンダ 最適化について ツール紹介 事例紹介
  14. 14. ツール
  15. 15. 三種の神器 CloudWatch JetProfiler NewRelic
  16. 16. CloudWatch
  17. 17. カバーエリア DB LB App KVS MQ Job 全部
  18. 18. CloudWatch AWSの提供するシステムモニタリングツール CPU, Memory, Disk, Network I/O, LoadAverage, etc.. もっとも基本的な情報 障害時のアラートなども行える
  19. 19. JetProfiler
  20. 20. カバーエリア DB LB App KVS MQ Job MySQL専用
  21. 21. JetProfilerとは MySQLに対するリアルタイム解析ツール クエリやステートの種類/数/頻度/割合 スロークエリ クエリ/テーブル毎の処理時間使用率, etc…
  22. 22. スレッド別
  23. 23. ステート別
  24. 24. テーブル別
  25. 25. クエリ種別割合
  26. 26. ロック状態
  27. 27. スロークエリ
  28. 28. NewRelic
  29. 29. カバーエリア DB LB App KVS MQ Job アプリケーション コード
  30. 30. NewRelicとは アプリケーションに埋め込むプロファイラ Java/.NET/node.js/PHP/Ruby/Pythonに対応 関数/メソッド毎の処理時間を調査可能 統計情報表示 色々なAPIを提供
  31. 31. サーバー概要 処理時間 リクエスト数 URL別遅い順 エラー率 平均レスポンスタイム
  32. 32. 処理割合 Python 外部API Memcache MySQL
  33. 33. URLごとの詳細 URL別リスト URLごとの変化の推移 リクエスト数とレスポンスタイム 個別の最も遅いレスポンス
  34. 34. テキスト APIでデプロイを記録 どのデプロイで変化があったかがわかる
  35. 35. DBもいける 処理時間 上位クエリ 上位クエリの推移グラフ 種類ごとの 割合グラフ 種類ごとの レスポンスタイム
  36. 36. アジェンダ 最適化について ツール紹介 事例紹介
  37. 37. ある日の夜 イベントリリース! しばらくは問題なく動作していたが… ページが開けない!と苦情が
  38. 38. CloudWatch AppサーバーCPU使用 率もリクエスト数も問 題ないが... DBのCPU使用率が張り 付いていた
  39. 39. 即JetProfilerを起動 ここが真っ赤だった
  40. 40. テキスト クリック一つて即Eplain グラフィカル&レーティングしてくれる。 DBにくわしくなくてもいかにもダメそうな感じ
  41. 41. インデックスがなかった 特定クエリが処理時間の9割以上を占めていた 緊急メンテに入りインデックスを追加 インデックスをはったら5%以下に
  42. 42. ほとんど同じ状況で 別パターン
  43. 43. 無駄インデックス問題 特定クエリが処理時間の3割以上を占めていた スローではないが一クエリ当たりの時間が多い Explainしたら index merge インデックスを削除したら100倍高速化
  44. 44. 教訓 負荷試験をしよう 負荷試験の結果で必要なインデックスだけを貼る インデックスショットガン、だめ絶対 超オススメです
  45. 45. 最適化 十分早いが回数が多いクエリに複合キーなど いらないインデックスを削除して高速化
  46. 46. ある日のNewRelic
  47. 47. 逆にmemcache速い!っと思ってしまった
  48. 48. Cache.get多すぎ プレイヤーデータ->マスターデータへのプロパティ で発生 DB分割しているとなりやすい Join出来ないのでプロパティなどで動的につなげる マスターデータに関してはjsonでappサーバーに配置 することで解消
  49. 49. ある日のNewRelic2
  50. 50. テキスト Redis.getに2.5sかかった redisのマスターでsave(メモリデータのダンプ)を止めappendonlyのみにし スレーブでダンプするように変更する事でだいたい解消
  51. 51. Redis.get一回に2.5秒 平均では1ms(最低値)なので統計グラフには出ない。 NewRelicのTransaction Detail で発見 Redisのbgsave時に起こる(EC2だと起きやすい)
  52. 52. ほかに取れる統計情報
  53. 53. テキスト どこに時間がかかっているか Python:DB:Memcacheの割合が 40:1:1 程度
  54. 54. テキスト スケーラビリティ 50req/mでも500req/mでもレスポンスタイムには変化が無い ので遅いのは個々の処理を行っているコードや仕様の問題
  55. 55. ブラウザもわかる
  56. 56. サーバー側の処理時間の 2∼5倍はレンダリングまでにかかる
  57. 57. Androidの 絶望的遅さ iOS(平均500ms)比で Chromeで2倍 AndroidBrowserだと 3∼4倍強。
  58. 58. 質疑応答
  59. 59. ご静聴ありがとうございました

×