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
俺たちの!パフォーマンス計測
Search
trunkatree
February 10, 2020
Programming
0
1k
俺たちの!パフォーマンス計測
20200210 LLRエンジニア交流会 LT資料
trunkatree
February 10, 2020
Tweet
Share
More Decks by trunkatree
See All by trunkatree
Terraform Workspacesの弱点をcountやmovedでカバーしつつ開発を進めた話
trunkatree
0
1.4k
Other Decks in Programming
See All in Programming
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
150
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.3k
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
2.1k
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
130
技術同人誌をMCP Serverにしてみた
74th
1
640
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
190
WebViewの現在地 - SwiftUI時代のWebKit - / The Current State Of WebView
marcy731
0
120
#QiitaBash MCPのセキュリティ
ryosukedtomita
1
1.3k
ニーリーにおけるプロダクトエンジニア
nealle
0
840
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
290
iOS 26にアップデートすると実機でのHot Reloadができない?
umigishiaoi
0
130
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
How GitHub (no longer) Works
holman
314
140k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Building Adaptive Systems
keathley
43
2.7k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Site-Speed That Sticks
csswizardry
10
690
Gamification - CAS2011
davidbonilla
81
5.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Transcript
俺たちの!パフォーマンス計測 2020.02.10 LLRエンジニア交流会 LT
遠藤 幹太 Mikita Endoh / @trunkatree 株式会社ROBOT PAYMENT / SRE
Team - 北の自然が好きです
もちろん パフォーマンス 計測してます
None
None
None
レスポンスタイム グラフ あります
None
でも、 これって 本当にあてになるの?
なぜそう思うか →
- ユーザーの利用頻度は一定じゃない - 月末月初が多い、など - 機能によってバラツキがある - よく使われるところ、たまにしか使われないところ - パフォーマンス性能にもバラツキがある
- オプション機能がいろいろある - 使う企業、使わない企業
- パフォーマンスの良くない機能が使われたからメトリクスが悪化した? - 何かよくない原因があってメトリクスが悪化した? - 一部機能を使った一部ユーザーに対してだけレスポンスが悪い? - 全体的にレスポンスが悪い? - パフォーマンス改善施策をリリースしたけど、結果どうなったの?
実際のところどうなの?
より ユーザーに寄り添った 計測がしたい!
→
各webトランザクションごとのメトリクスを確認できる
今どういう状況か? は、これを見ればいいね!
New Relic の細かいメトリクスは1週間ほどしか保存されない
では 中長期的な推移は?
じゃあ 自分たちで 保存しておこう
ということで、 簡単に つくりました →
New Relic のAPIからメトリクスをとってきて RDS に保存
- monitorサーバで cron で日次でシェルスクリプトを動かしています - 今はRDBに保存していますが、時系列DBなども考えていきたいです
日次で、各webトランザクションごとの - リクエスト数 - Apdex(ユーザー満足度) - レスポンスタイム - 標準偏差 -
5パーセンタイル - 50パーセンタイル - 90パーセンタイル - 95パーセンタイル - 99パーセンタイル をとってきて保存
今は で見れます
今後、うまいこと可視化していきたいですね - ヒートマップをつくる? - どこがよくないのか? が視覚的にわかりやすい - いい感じのパフォーマンス指標をつくる、算出する - これを見ればわかる!
というような
etc. - 全ユーザーが使う機能だけを対象にパフォーマンス指標を算出する - 日常的に使われる機能だけを対象にパフォーマンス指標を算出する - 中長期的な推移を観測し傾向を把握する - パフォーマンス改善施策をリリースした際に、結果どうだったか -
どの機能にどう影響が出ているかを把握する
厳密に言えば、 「SLO」は ユーザー体験を正確に表現 できていないと意味がない
こういった 細かい計測が必要 なのではないでしょうか?
Thank you. We are hiring !