https://developers.freee.co.jp/entry/performance-tuning-in-json_serialization
こんにちは、freee会計でワークフロー機能の開発をしている @mitubaEX です。
先日 freee会計のパフォーマンスチューニングに取り組みました。本記事では、調査の流れ、改善の事例を紹介します。
freee では自社の経理業務に freee会計を利用しており、その中でも経費精算の機能はほぼすべての従業員が利用しています。そのため日々多くのフィードバックをもらえます。そのフィードバックの1つで、「経費精算の一覧を開くのが遅い」という報告をもらいました。幸い表示件数を指定できるので調整すれば遅くはならないのですが、一覧性が下がってしまうため有用な解決策ではありません。
そこでワークフローを開発しているチームで、このパフォーマンスイシューの調査を始めました。
まず事前調査として Datadog*1 で一覧画面を表示するリクエストの処理を確認しました。
一覧画面を表示するリクエストの処理詳細
上図の赤枠で囲んだ部分は DB アクセスを伴う処理で、それ以外の空白の部分がアプリケーションの処理になります。この情報から、DB の処理は遅く無くアプリケーションの処理にネックがある状態だと推測を立てました。もう少し詳細に見ると DB アクセスが前半部分と後半部分にあることから、前半部分が一覧データの取得部分で 後半部分が serialize 時の依存データの取得部分であると推測できました。この間には一覧画面に表示するデータの生成処理が存在しボトルネックになっていることが確認できたので、ここに着目し調査を進めました。
調査する際に行ったことは stackprof*2 、Datadog trace*3 によるボトルネックとなっている箇所の処理の把握です。
stackprof による調査では、一覧画面に表示するデータの生成処理を profiling するようにコードに変更を加え、検証環境にデプロイしました。その後データ量が多い事業所のデータを用いて該当箇所を動かして profile を出力しました。そうして取得された profile を Frame Graph で吐いたものを以下に示します。
出力した Frame Graph
この Frame Graph により、極端に遅い処理に当たりを付けることができます。
次にDatadog trace を該当箇所に仕込み、どれくらい時間がかかっているかも測定しました。すると全体の 92.1%を一覧画面に表示するデータの生成処理が占めていました。
Datadog trace の結果