problems • 性能問題が起きてるけど原因が分からない人 People who are having performance problems but don't know why • 性能問題が起きてる気がするので勘で対応している人 People who feel like having a performance problem and is dealing with it on a hunch • 性能問題が起きてるか分からない人 People who don't know if they're having performance problems • 3
underneath the app as well • アプリケーションを動かす基盤を含めて把握が必要 You need to understand the infra that the application works ◦ フレームワーク Framework ◦ ランタイム（アプリケーションサーバなど） Runtime (include Application Server, etc) ◦ オペレーティングシステム Operating System 12 F/W Runtime OS スタック Stack アプリ App
分析に必要な全ての事実を計測 Measure all the facts needed for analysis ◦ 何の情報を計測するか What information is being measured ◦ いつ情報を計測するか When to measure the information ◦ どこへ情報を記録するか Where to record the information 15
each process ◦ 処理のどこが遅くなっているかの事実が分かる Being able to see the facts about what part of the process is slowing down • システム全体の視点 Perspective in whole system ◦ なぜ遅くなっているのか原因が分かる Being able to see why it's slowing down 16
on each process A. HTTPをリクエストする（クライアント） Request HTTP (client) B. HTTPリクエストを受ける Receiving HTTP requests C. ネットワーク操作（接続、問い合せ、切断など） Network operations (connect, query, disconnect, etc.) D. スレッド操作（処理中、待機、スリープなど） Thread operations (in process, wait, sleep, etc.) E. ファイル操作（読み込み、書み込みなど） File operations (read, write, etc.) 17 A B B C D E リクエスト Request レスポンス Response
in whole system • リソースの全体量、使用量、残量や待ち数を記録 Record the overall amount of resources, usage, remaining and number of waits • バックグラウンドで処理されるものを記録 Record what is processed in the background • OSやプロセスの情報を記録 Record OS and process information • 毎秒～10秒毎のように定期的に記録 Record it periodically, like every second or 10 seconds 18 残量 Remain 使用量 Usage リソースプール Resource Pool
for HTTP, DB, etc • HTTPなどの処理数とそれらの受付待ち数 Number of HTTP, etc. processes and their waiting lists • プールの使用量（コネクションやスレッドなど） Pool usage (connections, threads, etc.) • ランタイムのバックグラウンド処理の統計 Run-time background processing statistics • CPU使用率、IO時間、OSのメモリ使用量など CPU usage, IO time, OS memory usage, etc 19 各処理の視点 Perspectives on each process システムの視点 Perspective in whole system
of time when the problem occurred • 何も問題が起きていない期間 A period of time in which nothing has gone wrong 20 正常期間 Normal Period 異常期間 Abnormal Period 記録期間 Recording period 正常期間 Normal Period
can check it again and again ◦ ファイル File ◦ ミドルウェア/サービス（Prometheus/Elasticsearch/Datadog） Middleware or Services (Prometheus/Elasticsearch/Datadog) • ダメ：すぐに消えてしまうようなところ（Shell） No Good : Where it's going to disappear quickly (Shell) 21
for the problem ◦ 計測結果を可視化 Visualization of measurement results ◦ 正常期間と異常期間を比較する Comparing normal and abnormal periods ◦ 情報が足りなかったら計測へ戻る Return to measurement when the acquired information is insufficient 23
process 24 • システム全体の視点 Perspective in whole system DB処理 API呼出 時間 time 開始 Start 終了 End 3:24:10 3:24:20 3:24:30 使用中 usage 割当待ち waiting lists リソース状況 Resource Status 3:24:23 3:24:34
25 • 異常期間 Abnormal Period DB API 呼出 3:24:10 3:24:20 3:24:30 使用中 usage 割当待ち waiting lists D B API 呼出 1:01:10 1:01:20 1:00:30 使用中 usage コネクションプール Connection Pool 処理 Processing 3:24:23 3:24:34 1:01:12 1:01:17
right down to the insides • 必要な情報は全て記録する record all the information we need • 可視化して正常期間と異常期間を比較する Visualize and compare normal and abnormal periods • 根拠のある改善を行う Making Evidence-Based Improvements 26
• アプリケーション Application • アプリケーションサーバ（フレームワーク含む） Application Server (Inc. Framework, etc) • Java 仮想マシン Java Virtual Machine • オペレーティングシステム Operating System 28 Windows Linux Mac Java VM Quarkus Wildfly Spring App App App
HTTPやDBなどの処理期間 Processing time for HTTP, DB, etc • HTTPなどの処理数とそれらの受付待ち数 Number of HTTP, etc. processes and their waiting lists • プールの使用量（コネクションやスレッドなど） Pool usage (connections, threads, etc.) • ガベージコレクション、クラスロード、コンパイル Garbage Collection, Loading class, Compile, etc. • CPU使用率、IO時間、OSのメモリ使用量など CPU usage, IO time, OS memory usage, etc 29 各処理の視点 Perspectives on each process システムの視点 Perspective in whole system 大抵のFWが提供 Most frameworks provide
JVM events ◦ GC、クラスロード、JITコンパイルなどの実行時に出力 Output during GC, class loading, JIT compilation, etc when these are processing • 以前は取りたいログ毎にVM引数が存在 Previously, there were VM arguments for each log you wanted to get 31 java -Xlog:gc=trace:file=gctrace.txt:uptimemillis,pid:filecount=5,filesize=1M App [5ms][34164] MarkStackSize: 4096k MarkStackSizeMax: 16384k [21ms][34164] ConcGCThreads: 2 offset 16 [21ms][34164] ParallelGCThreads: 8 [22ms][34164] Initialize mark stack with 4096 chunks, maximum 16384
to manage metrics exposure, etc ◦ JVMはGC、クラスロード、JITコンパイルなどの統計を提供 JVM provides statistics on GC, class loads, JIT compilation, etc. ◦ フレームワークはリソース量、処理待ち数などを提供 App framework provides such as amount of resources, processing waits, etc. 32 @MXBean public interface Metrics {} public class MetricsImpl implements Metrics {}
◦ JVMの主要な分析に必要なほぼ全てのメトリクスを記録 Record nearly all the metrics needed for key JVM analyses ◦ アプリ独自のメトリクスも作れる。対応FWもある You can also create app-specific metrics. Some FW support JFR 34 Recording r = new Recording(); r.start(); r.stop(); r.dump() java -XX:StartFlightRecording App
Just In Time Any code that isn't compiled is very slow! 起動直後はスレッドプールが準備できてないからだろ。 That's because the thread pool isn't ready right after startup. コネクションプールが用意できてないからに決まってるだろ It's because they don't have a connection pool available.
and other APIs • SpringBoot 2.3.4 on OpenJDK 14 SpringBoot 2.3.4 on OpenJDK 14 • 全てのイベントを記録するようにJFRを設定 Set JFR to record all events • HTTPとJDBCを記録するように独自イベントを作成 Create your own events to record HTTP and JDBC 43
2回目以降のリクエスト Second and subsequent requests 処理期間は10-15ms Processing time is 10-15ms 処理期間は800msだが、400ms差がある The processing time is 800ms, but there is a 400ms difference
it gets processed. JITは処理され続けている JIT continues to be processed. 処理スレッド processing thread 処理前のFWの処理が400ms掛っている It is taking 400ms to process the FW before processing
the thread is ready to go • コネクションプールでは遅延していない No delays in connection pools • JIT されていなくても処理は速い Even if it's not JIT'd, it's still fast • 処理に必要なクラスのロードに時間が掛かっている It's taking a long time to load the classes needed for processing 49
chiroito
aki_i
ahana
hokaccha
shotakitazawa
hayaosuzuki
yamamuteki
soracom
kentaro
aszx87410
yujioshima
changeworld
toshimaru
mongodb
jensimmons
holman
jakevdp
trallard
marktimemedia
brettharned
frogandcode
jcasabona
colly
notwaldorf
brianwarren
