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
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
2
150
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
160
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
790
効率的な開発手段として VRTを活用する
ishkawa
0
140
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
530
AI駆動のマルチエージェントによる業務フロー自動化の設計と実践
h_okkah
0
150
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
190
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
190
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
14
4.6k
Hypervel - A Coroutine Framework for Laravel Artisans
albertcht
1
130
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
650
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
130
Featured
See All Featured
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
6
300
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Building an army of robots
kneath
306
45k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Docker and Python
trallard
44
3.5k
KATA
mclloyd
30
14k
How STYLIGHT went responsive
nonsquared
100
5.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Designing for Performance
lara
610
69k
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 !