Ruby/Rails Benchmarking and Profiling with TDD
2 likes1,214 views
大阪Ruby会議02での発表資料です https://regional.rubykaigi.org/osaka02/
![me.inspect
=> {
“HN”: "wakaba260",
“name”: "Yasutomo Uemori",
“company”: "株式会社Aiming",
“twitter”: "https://twitter.com/wakaba260yen",
“github”: "https://github.com/yuemori",
“skills”: ["rails api", "docker", "kubernetes", "GCP"]
}](https://image.slidesharecdn.com/rubyrailsbenchmarkingandprofilingwithtdd-190915055013/85/Ruby-Rails-Benchmarking-and-Profiling-with-TDD-2-320.jpg)
Ruby/Rails Benchmarking and Profiling with TDD
- 1. Ruby/Rails Benchmarking and Profiling with TDD 2019/09/14 Osaka Ruby Kaigi02 Yasutomo Uemori (wakaba260)
- 2. me.inspect => { “HN”: "wakaba260", “name”: "Yasutomo Uemori", “company”: "株式会社Aiming", “twitter”: "https://twitter.com/wakaba260yen", “github”: "https://github.com/yuemori", “skills”: ["rails api", "docker", "kubernetes", "GCP"] }
- 3. 突然ですが
- 5. とったことある人？
- 7. Agenda 話すこと - Benchmark and Performance Testing - チューニングを行ったときの取り組み 話さないこと - Rackサーバのチューニング - 改善をしたときの実装内容
- 9. はじめに大事なこと
- 10. 推測するな 計測せよ
- 12. どうやって 計測しよう🤔
- 14. なぜTestを書くのか 我々は普段からアプリケーションに対しテストを書いている - エラーがないこと - バグが修正されたこと - 仕様どおりに動くこと こういったことを再現性高く保証するためにテストがある ⇛ パフォーマンスについてもテストを書きたい
- 24. Benchmark プロファイリングとあわせてベンチマークは必ずとっておこう - 実際にどのぐらい時間がかかるか？を把握する - プロファイリングを有効にすると、実行速度自体が下がる - 一回だけの実行ではばらつきが出やすいのでウォームアップや実 行回数もポイント
- 27. Stackprof a sampling call-stack profiler for ruby 2.1+ ・mode, interval, outを指定してサンプリング対象のコードを ブロックで呼び出すだけ ・CPU Clock Time: CPUの利用時間。 Wall Clock Time: 開始から終了までの時間。Railsの場合はこれ 参考：https://scoutapm.com/blog/profiling-rails-with-stackprof
- 28. Stackprof
- 34. Stackprof-webnav
- 40. Problem ?
- 41. Problem めんどくさい
- 43. Performance Spec
- 44. Performance Spec
- 45. Performance Spec
- 48. ここまでのまとめ 手早くパフォーマンス改善を行うためにはどうしたらいいか - パフォーマンスチューニングにおいては計測が重要 - いろんなgemを使って計測を楽にする - 計測とチューニングのサイクルを確立する
- 49. パフォーマンス 改善時のとりくみ
- 50. パフォーマンス改善時の取り組み - 改善箇所の調査 - パフォーマンステスト - パフォーマンス改善方法論の共有
- 51. 社内テスト内容から遅いAPIの調査 - 改善箇所を検討するために遅いAPIはどこかを調査 - アクセスログからレポートを作成 - 指標 - 総リクエスト数 - 平均レスポンス速度 - 最大レスポンス速度 - 50%、90%、99%、99%...のレスポンス速度
- 54. 社内テスト内容から遅いAPIの調査：チューニングの検討 - サービスとして遅い箇所が問題になるもの - 例）毎回ログインに時間がかかる - 共通処理で遅いもの - 例）毎回呼び出される認証が遅い - 遅い原因が他の問題を引き起こすもの - 例）N+1問題が原因なためDBへの負荷が懸念される
- 59. 社内テスト内容から遅いAPIの調査：計測方法 - ログから計測 - 今回はStackdriver + BigQuery + DataPortal - 構造化ログを出しておくことで集計が容易になる - サービスの利用 - NewRelicやDatadogなど - productionではおすすめ - CIやローカルで実行するのに難がある
- 60. パフォーマンステスト - 紹介した実装をベースにテスト環境を整備 - DBのボトルネック調査にクエリレポートを追加実装 - ActiveSupport::Notificationsを使ってクエリをトレース
- 65. パフォーマンス改善方法論の共有：レビュー - パフォーマンス改善のPRを出した時はdescriptionに結果を記載 - 改善時にチェックしたポイントをわかりやすくする - before/afterを掲載して改善されていることを伝える
- 68. まとめ - パフォーマンス改善の心得：推測するな、計測せよ - パフォーマンスのテストコードを書いて改善を楽にしよう - パフォーマンス改善は楽しいので是非Tryしてみてください
- 69. ご静聴 ありがとうございました