Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Ruby/Rails Benchmarking and Profiling with TDD
Search
Yasutomo Uemori
PRO
September 15, 2019
Programming
0
18
Ruby/Rails Benchmarking and Profiling with TDD
大阪Ruby会議02での発表資料です
https://regional.rubykaigi.org/osaka02/
Yasutomo Uemori
PRO
September 15, 2019
Tweet
Share
More Decks by Yasutomo Uemori
See All by Yasutomo Uemori
いまどきのゲームサーバアーキテクチャ
wakaba260
PRO
1
88
オンラインゲームのRails複数db戦略
wakaba260
PRO
0
37
Active job meets kubernetes
wakaba260
PRO
0
14
GCP・GKEで作るスケーラブルなゲーム開発環境
wakaba260
PRO
0
27
サービスクラス、その前に
wakaba260
PRO
0
18
Rails on Dockerとの戦い
wakaba260
PRO
0
10
Rubocopとの付き合い方
wakaba260
PRO
0
12
Rails api way in aiming
wakaba260
PRO
0
13
ゲーム会社でのRuby : rails活用事例
wakaba260
PRO
0
25
Other Decks in Programming
See All in Programming
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
5
3.6k
ECSのサービス間通信 4つの方法を比較する 〜Canary,Blue/Greenも添えて〜
tkikuc
11
2.3k
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
460
Tuning GraphQL on Rails
pyama86
2
1.2k
qmuntal/stateless のススメ
sgash708
0
120
Identifying User Idenity
moro
6
8.8k
AWS IaCの注目アップデート 2024年10月版
konokenj
3
3.2k
PLoP 2024: The evolution of the microservice architecture pattern language
cer
PRO
0
2k
gopls を改造したら開発生産性が高まった
satorunooshie
8
260
シェーダーで魅せるMapLibreの動的ラスタータイル
satoshi7190
1
190
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
150
アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile
goyoki
7
3k
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
The Art of Programming - Codeland 2020
erikaheidi
51
13k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Building an army of robots
kneath
302
42k
Designing for Performance
lara
604
68k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
355
29k
Building Better People: How to give real-time feedback that sticks.
wjessup
363
19k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Thoughts on Productivity
jonyablonski
67
4.3k
Transcript
Ruby/Rails Benchmarking and Profiling with TDD 2019/09/14 Osaka Ruby Kaigi02
Yasutomo Uemori (wakaba260)
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"] }
突然ですが
Ruby/Railsの プロファイルや ベンチマーク
とったことある人?
今日の話はこんな人向けの話 - Ruby/Railsのベンチマークやプロファイリングに興味がある - パフォーマンス改善にどう手を付けていいかわからない ⇛ 主に初心者向けの話
Agenda 話すこと - Benchmark and Performance Testing - チューニングを行ったときの取り組み 話さないこと
- Rackサーバのチューニング - 改善をしたときの実装内容
Benchmark and Performance Testing
はじめに大事なこと
推測するな 計測せよ
プログラミングで時間がかかっている場所を 推測してはいけない。
どうやって 計測しよう🤔
Testing そうだ、テストを書こう
なぜTestを書くのか 我々は普段からアプリケーションに対しテストを書いている - エラーがないこと - バグが修正されたこと - 仕様どおりに動くこと こういったことを再現性高く保証するためにテストがある ⇛ パフォーマンスについてもテストを書きたい
Red Green Refactor Standard TDD
Benchmark Profile Refactor Performance TDD
Benchmark Profile Refactor 実行速度を計測
Benchmark Profile Refactor 原因箇所を特定
Benchmark Profile Refactor コードを改善
Benchmark Profile Refactor 改善されたことを確認
Benchmark Profile Refactor Measure Measure Improve
Benchmark Profile Refactor Measure Measure Improve 計測、計測、そして改善
💎今回テストを書くのに使ったgemたち ・Testing:RSpec ・Benchmark:module Benchmark ・Profile:https://github.com/tmm1/stackprof
Benchmark プロファイリングとあわせてベンチマークは必ずとっておこう - 実際にどのぐらい時間がかかるか?を把握する - プロファイリングを有効にすると、実行速度自体が下がる - 一回だけの実行ではばらつきが出やすいのでウォームアップや実 行回数もポイント
Benchmark module ・公式のベンチマークライブラリ ・簡単な計測ならこれだけで十分
Profiling 速度計測後はプロファイリングを行い、ボトルネックを特定する - 速度を計測したあと、どこが遅いかを推測で直さない - 利用しているミドルウェアや外部サービスが遅いなどもある程度わ かる
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
Stackprof
Stackprof 総サンプリング回数
Stackprof そのメソッドが呼び出しているメソッドの時間も含めた、 TOTALのサンプリング回数
Stackprof 純粋にそのメソッドの サンプリング回数
Stackprof 処理に時間がかかっている箇所
Stackprof 呼び出している処理のため、 時間がかかっている箇所
Stackprof-webnav
Stackprof-webnav 行単位で時間がかかっている箇所を表示できる
Stackprof-webnav 一番時間がかかっている場所を特定!
Stackprof --flamegraph ・上記のようなflamegraphのhtmlを生成してくれる ・呼び出しのスタックトレースや時間などが可視化されるので便利
実践 https://github.com/yuemori/performance_test_app demo1 demo2
最低限のテストは 出来るようになった
Problem ?
Problem めんどくさい
Problem めんどくさい ・手動実行に頼っている ・目視確認に頼っている ⇛ 一度直った問題が再発してないかを確認しにくい ⇛ もっと複雑なケースだとテストケースの再現性も問題
Performance Spec
Performance Spec
Performance Spec
詳細 https://github.com/yuemori/performance_test_app
余談 既にそういったgemがあることに後から気づいた - https://github.com/piotrmurach/rspec-benchmark - https://github.com/rails/rails-perftest また必要になったときにはこれらを使うかどうかも検討したい
ここまでのまとめ 手早くパフォーマンス改善を行うためにはどうしたらいいか - パフォーマンスチューニングにおいては計測が重要 - いろんなgemを使って計測を楽にする - 計測とチューニングのサイクルを確立する
パフォーマンス 改善時のとりくみ
パフォーマンス改善時の取り組み - 改善箇所の調査 - パフォーマンステスト - パフォーマンス改善方法論の共有
社内テスト内容から遅いAPIの調査 - 改善箇所を検討するために遅いAPIはどこかを調査 - アクセスログからレポートを作成 - 指標 - 総リクエスト数 -
平均レスポンス速度 - 最大レスポンス速度 - 50%、90%、99%、99%...のレスポンス速度
社内テスト内容から遅いAPIの調査
・・・どこから手を付けていこう?🤔 社内テスト内容から遅いAPIの調査
社内テスト内容から遅いAPIの調査:チューニングの検討 - サービスとして遅い箇所が問題になるもの - 例)毎回ログインに時間がかかる - 共通処理で遅いもの - 例)毎回呼び出される認証が遅い -
遅い原因が他の問題を引き起こすもの - 例)N+1問題が原因なためDBへの負荷が懸念される
呼び出し頻度は少ないが取得系なので、 かなり酷いN+1なことが予想されるので直したい 社内テスト内容から遅いAPIの調査
同じくN+1っぽいが、ほとんど呼ばれないため 優先度を下げる 社内テスト内容から遅いAPIの調査
平均速度は上位に比べると早いが、 速度劣化の仕方が激しいので原因を見ておきたい 社内テスト内容から遅いAPIの調査
気になるほど遅いわけではないが、 呼び出し回数が飛び抜けて高いのでもう少し早くしたい 社内テスト内容から遅いAPIの調査
社内テスト内容から遅いAPIの調査:計測方法 - ログから計測 - 今回はStackdriver + BigQuery + DataPortal -
構造化ログを出しておくことで集計が容易になる - サービスの利用 - NewRelicやDatadogなど - productionではおすすめ - CIやローカルで実行するのに難がある
パフォーマンステスト - 紹介した実装をベースにテスト環境を整備 - DBのボトルネック調査にクエリレポートを追加実装 - ActiveSupport::Notificationsを使ってクエリをトレース
パフォーマンステスト:クエリレポート - railsの提供するイベントから計測、集計 - テスト時に実行されるSQLのレポートを作成して可視化
パフォーマンス改善方法論の共有 チューニングを個人に依存しないようにしたいと考えていた - 実際にチューニングを行ったときのことをチーム内勉強会で共有 - ドキュメントの作成 ⇛ 方法論を共有することでチューニングをチームのものにする💪
パフォーマンス改善方法論の共有:ドキュメントの作成
パフォーマンス改善方法論の共有:ドキュメントの作成
パフォーマンス改善方法論の共有:レビュー - パフォーマンス改善のPRを出した時はdescriptionに結果を記載 - 改善時にチェックしたポイントをわかりやすくする - before/afterを掲載して改善されていることを伝える
パフォーマンス改善方法論の共有:レビュー
パフォーマンス改善方法論の共有:レビュー
まとめ - パフォーマンス改善の心得:推測するな、計測せよ - パフォーマンスのテストコードを書いて改善を楽にしよう - パフォーマンス改善は楽しいので是非Tryしてみてください
ご静聴 ありがとうございました