INPとは何か？
2024年3月12日、Googleは新しいCore Web Vital指標である Interaction to Next Paint (INP) を開始することを発表しました。INPは、FID（First Input Delay）に代わるもので、Googleによるサイトのパフォーマンス評価の方法を変え、最終的に検索エンジンの検索結果に影響を与えます。 TL;DR：3月12日以降にあなたのサイトが悪影響を受けないよう、今日からINPに最適化する必要があります。 INPへ変更した経緯 FID（First Input Delay）は、Webページがユーザーの最初のアクションに対してどれだけ速く反応するかを測定するために設計されました。一般的に良いとされるFIDスコアは、100ms以下とされています。 しかしChromeの使用データによると「ユーザーのページ滞在時間の90%は読み込み後に費やされる」ため、FIDではユーザー体験のすべてを把握することはできません。 そこで INPは、最初のインタラクションだけでなくページ上のユーザージャーニー全体にわたってクリック、タップ、キーの押下を観察するように設計することで、ページの全体的な知覚応答性を測定することが可能になっています。 最終的なINPの値は、ユーザーがアクションを実行してから視覚的なフィードバックを受け取るまでに観測された最長時間として計算されます。 ユーザーインタラクションの例としては、製品をカートに追加するボタンのクリック、展開可能なアコーディオンのクリック、折りたたまれたナビゲーションメニューのタップ、入力フィールドへの入力などがあります。 INPは、特定のアクションが実行された後、視覚的フィードバックが表示されるまでの時間（つまり、次のペイント-ここでペイントとは、ブラウザがスクリーンにピクセルを追加するプロセスのことです）に焦点を当て、インタラクションの最終的な効果（ネットワークリクエストやUIの更新など）は除外します。 開発ツールにおけるINPの調査 Chrome、Brave、Edge、ArcなどのChromiumベースのブラウザを使用して、INP測定値に寄与するアクションとイベントを調査する方法を見てみましょう。 INPが計測する以下のユーザーインタラクションのいずれかを受け付けるウェブページを選択します（スクロールやポインタの移動などは計測されない） マウスでのクリック タッチスクリーンを使ってデバイスをタップする 物理キーボードまたはオンスクリーンキーボードのキーを押す 今回は、Sentry Docsのホームページで “web vitals “を検索したときに何が起こるかを調査することにしました。 開発ツールパネルを開き、「パフォーマンス」タブをクリックします。 Webサイトのターゲット層にもよりますが、古いマシンや低速のインターネット上でのユーザー体験を分析するために、CPUやネットワーク速度を調整することはしばしば有用です。 より遅いCPUやネットワークをシミュレートしたい場合は、それに応じてオプションを設定してください。 記録ボタンをクリックし、ページ上でいくつかのインタラクションを実行します。 録画を停止し、プロファイルがロードされるのを待ちます。 すると、色分けされたブロックとラベルの付いたレーンの形で、多くのデータが表示されます。 INPの要因を分析する際に最も重要なレーンは、”Interactions”(ページ上で実行されたユーザーインタラクション)と “Main”(ブラウザのメインスレッド)です。 文脈上、メインスレッドは “ブラウザがユーザーイベントとペイントを処理する場所 “です。デフォルトでは、ブラウザはメインスレッドを使用して、ページ上のすべてのJavaScriptの実行、ページのレイアウト、あらゆる変更の再計算、メモリの確保と解放（ガベージコレクション）を行います。 つまり、長時間実行されるJavaScript関数がメインスレッドをブロックする可能性があり、レスポンスの悪いページや悪いユーザーエクスペリエンスにつながります。GoogleはINPメトリックを導入することで、開発者にこれを解決するよう促しています。 記録されたパフォーマンスプロファイルを見ると、メインスレッドのブロックが赤くハイライトされていることがあります。タスクにカーソルを合わせると、実行にかかった時間が表示され、そのタスクブロックの下には、そのタスクを構成する個別のイベントや関数呼び出しがすべて表示されます。 マウスやトラックパッドでズームイン/ズームアウトしたり、ウィンドウの右側にあるスクロールバーを使ってスタックを上下にスクロールすることができます。 レーンの下にあるサマリー・タブは、各タスクでどれだけの時間が異なるプロセスに割り当てられたかを示しています。 これはタスクによって異なりますが、通常は「スクリプティング」（つまりJavaScriptの処理）と「ローディング」に最も長い時間がかかっていることが明確になります。 では、メインスレッドのアクティビティと、インタラクションレーンを確認してみましょう。 この例では、Sentry Docsホームページの検索入力に “web vitals “と入力した状態です。 […]
【Sentry】モバイルアプリのパフォーマンス改善方法
何千ものモバイル開発者チームと協力してきた経験に基づいて、Sentryではモバイルモニタリングの成熟曲線を開発しました。 私たちは、チームが安定性を達成し、クラッシュの消火と修正がなくなると、ワークフローの合理化にシフトし、最終的にはモバイルアプリのパフォーマンスの最適化に集中するようになるという仮説を立てました。 先日のワークショップで、私たちはモバイル開発者たちに、D彼らがカーブのどこに位置するかを尋ねました。 するとその結果は驚くべきものでした。 ほとんどの開発者（41％）は「安定性の確保」の段階にいました。 また、4分の1近く（24％）が現在パフォーマンスを最適化しています。 集中力とリソースは必要ですが、パフォーマンスの改善はモバイルアプリの成功に不可欠です。開発者が成熟度カーブを上れるよう、当社はモバイル・パフォーマンスの問題を検出して修正する方法を改善しています。これらの改善は、4つの重要な要素に分けることができます。 TTID / TTFDを使って遅い画面を最適化する アプリの起動が遅い根本原因を特定する アプリケーションの応答性を向上 モバイル・サービス・ビューで主要メトリクスを確認 TTID / TTFDを使って遅い画面を最適化する モバイル画面のロード時間、特にTTID（Time to Initial Display）とTTFD（Time to First Display）に焦点を当てたトラブルシューティングのワークフローを開発しました。 TTIDは、ユーザーにアプリがロード中であることを知らせる最初のフレームを表示するのにかかる時間です。 TTFDは意味のあるコンテンツが画面に表示され、アプリが完全にインタラクティブになるまでの時間です。ニュース記事をスクロールしたり、おしゃれな洋服を買ったりするのに、数秒待たされるのは誰だって嫌ですよね。 TTIDとTTFDのどちらかが遅いと、ユーザーはすぐに離脱してしまいます。 TTIDとTTFDは、プロダクションでの遅いメトリクスに寄与する作業を強調します。Sentry の Screen Loads を使用すると、トラフィックが最も多いユーザー画面を確認し、リリース間で TTID と TTFD を比較できます。 これにより、新しいリリースで導入された潜在的なパフォーマンスのボトルネックが強調されるため、速度低下の原因となっているコード変更、依存関係、または資産を調査することができます。以下のスクリーンショットのように表示されます。 また、単一画面の画面ロード・サマリー・メトリクスを見たり、モバイル・デバイス・クラスでフィルタリングして、リリース全体の平均TTID / TTFDを見ることもできます。 サマリー・グラフの下には、最も時間のかかるスパンが表示されます。これらについては、データのフィルタリングも可能です。 これにより、どの操作が TTID または TTFD の遅さの原因となっているかを知るために必要なコンテキストが得られます。以下のスクリーンショットをご覧ください。 Screen Loadsは現在、すべてのAndroidおよびiOSユーザーに提供されています。 アプリの起動が遅い根本原因を特定する 当社の新しいモバイルパフォーマンスアップデートは、アプリの起動が遅い根本原因の特定にも役立ちます。 モバイルアプリの起動シーケンスとは、アプリの起動からTTIDまでのステップを指します。迅速なアプリの起動は、ユーザーに好印象を与え、高い満足度、継続率、コンバージョン率を確保するために非常に重要です。 コールドスタート（アプリが初めて起動されるとき）であれ、ウォームスタート（アプリがバックグラウンドからフォアグラウンドに移動するとき）であれ、アプリの起動時間はAppleやGoogle Playストアでのアプリのランク付けや発見にも影響します。 Sentryでは、SentryのパフォーマンスナビゲーションバーでApp Startを使用して、最近リリースされたアプリバージョンのパフォーマンスを監視できるようになりました。 下の例のように、あるリリースと次のリリースのコールド（またはウォーム）スタート時間を比較し、両方のリリースのイベント […]
パフォーマンス監視機能によってアプリの安定性を向上させ、エンジニアの負担を軽減した理由
オランダに本社を置くVisma社のYukiは、中小企業や会計事務所に使いやすい自動化された会計・税務サービスを提供しています。 顧客は財務書類をYukiに送り、Yukiのソフトウェアが自動的に書類を処理し、財務報告や税務申告を行うというものです。 多くの税務・会計ソフトウェアプラットフォームと同様に、Yukiは四半期ごとに約2週間の激務を経験します。 閑散期には機能が長期間使用されないため、バグやパフォーマンスの問題はエンジニアがその場でQAを行い、本番環境で監視していても、気づかれることはありませんでした。 スローダウンは使用量のピーク時にのみ現れ、ただでさえストレスの多い時期にユーザーのフラストレーションを引き起こし、開発者はすべての問題を優先度0（p0）として扱う必要がありました。 チームは迅速に問題を解決していましたが、会社の成長に伴い、自前のロギングおよびモニタリングツールだけでは対応できなくなりました。 エンジニアたちは、パフォーマンス課題を可視化できず、原因の特定が困難となり、反応も鈍かったのです。 影響を受けたユーザー数を確認できないため、最初に修正すべき優先順位を決める方法がありませんでした。 その代わり、エンジニアがコードを見て、それがどのくらいの影響を持つモジュールなのか推測し、問題がクリティカルかどうかを判断することに頼っていました。 「私たちのプラットフォームが成長するにつれ、速度低下に関する顧客からの苦情が増えました。しかし、これらの速度低下を解決するために、エンジニアはローカル環境で問題を再現することができないため、顧客チケットと電子メールの間を往復しなければならず、解決まで期日を要し、フラストレーションも蓄積していきました。」 チームは、顧客が書き込む前にエラーやパフォーマンスの問題を自動的に特定し、トリアージを支援し、解決するソリューションを探し始めました。 課題 エラーの影響に関するグループ化、アラート、メトリクスがない エンジニアにコンテキストがなく、トラブルシューティングが困難で時間がかかる パフォーマンスの問題は表示されるが、根本的な原因を特定するのは難しい ユーザーへの影響を可視化できない 従来のAPMベンダーよりもSentryが適していた Yukiは、いくつかの他のアプリケーションパフォーマンス監視（APM）ツールを比較検討しました。 しかし最終的にエラー追跡とパフォーマンス監視のためにSentryを選択しました。その決め手は、開発者エクスペリエンスの向上、SlackとAzure DevOpsとの連携、および.NETの強力なサポート体制です。 他のソリューションとは異なり、Sentryはカスタマイズをあまり必要としなかったため、エラーや速度低下、エンジニアが気にするメトリクスをすぐに監視することができました。 「私たちが評価した他のツールは圧倒的で、ハイレベルな指標しか示してくれませんでした。データだけで行動を起こすのは難しいのです。しかしSentryはセットアップが簡単なだけでなく、UXもわかりやすい。不必要な情報は適切にカットし、例外や遅いクエリなど、修正すべき点を正確に示してくれます。」 さらにYukiは、ユーザーへの影響やエラーの発生時期などのデータにアクセスすることで、重大性に基づいて問題に優先順位を付け、ログを探し回ったり、顧客と電子メールでやり取りしたりすることなく、それらの問題に対処することができるようになりました。 「問題が発生した場合、正確なバージョン、リリース、完全なURLがわかります。この情報を得ることで、開発者のエクスペリエンスは一変し、何が問題なのか、どこで問題が発生したのかを突き止めるのが非常に簡単になりました。」 すぐに使える.NET SDKサポート カスタムSlackアラート DBクエリと外部API統合のパフォーマンスを監視する機能 ダッシュボードとクエリの活用による迅速な改善 YukiはDB中心のアプリケーションで、より分散されたアーキテクチャに移行する計画があります。 これを念頭に、Yukiは分散サービス全体をトレースし、DBクエリと外部APIに関するパフォーマンス・インサイトを提供するソリューションを必要としていました。 「私たちは多くのサードパーティのAPIに依存し、複雑なクエリを書いています。1つのクエリが遅いと、アプリケーションのさまざまな領域に影響を及ぼす可能性があります」とJeroen氏は説明する。 パフォーマンス・クエリ・モジュールを使用することで、Yukiは、トップ・リグレッション・クエリと、それらがどのAPIエンドポイントから発生しているかを確認することができます。以前は、スローダウンが起きていることを特定するだけでなく、スローランニングしているクエリを見つけるためにエンドポイントごとに時間をかけて確認する必要がありました。 特に、クエリのロード時間が大幅に増加したクエリを検出したケースです。 Arjan氏は、パフォーマンス監視を使って、画像処理に関連する.NETライブラリ内で最近行われた変更までさかのぼりました。 リクエストの URL をすべて見ることができたため、問題を絞り込み、例外をスローする画像フォーマットを特定することができました。 「私たちは、特定の画像タイプのレンダリングに問題があることを知っていました。Sentryは、すべてのメタデータを含む完全なクエリー文字列を提供してくれたので、どの画像タイプが影響を受けているかを正確に突き止めることができました」とArjanは解説します。 以前であれば、問題のクエリは請求書のロードに使用されるコンポーネントを含む多くの異なるコンポーネントと相互作用していたため、Arjan氏のチームは修正パッチの適用を急いでいたことでしょう。しかし、Sentryでその影響を確認できたため、ホットフィックスをプッシュするためにすべてを停止する必要がない、孤立した問題であることがわかりました。 「2週間のリリースサイクルの間にパッチを当てる必要はありませんでした。Sentryのおかげで血圧が下がり、エンジニアが時間を集中させるべき優先順位を効果的に決めることができます。」 もう一つの例は、UIの新バージョンを作成しているときに、TPMメトリクスを使って多用されているエンドポイントを特定したときのことです。 調査の結果、そのエンドポイントは10秒ごとにタイマーを使ってデータベースからステータスをフェッチしていることがわかりました。 彼らはクエリを最適化して書き換え、ラウンドトリップを減らし、古いデータにはキャッシュを適用することができ、スピードが大幅に向上しました。 Slackでクリティカルな接続問題を検出する Yukiは会計を自動化しているため、成功の尺度の1つはアプリで費やされた時間です。このため、開発チームは、ユーザーに影響を与える問題をすべて取り除き、サイト・パフォーマンスを最適化することで、ユーザーが可能な限り速く出入りできるようにしています。 SQLサーバーのDB接続に失敗したことを知らせるアラートをSlackに設定しました。 以前は、Yukiはこのような問題について、サポートチームや顧客からの電話で聞くだけでした。パフォーマンスの問題があった場合、彼らの唯一の手段は、潜在的な問題がないかインフラを検査することだったのです。 「私たちのシステムは大きすぎて、どこが遅いのか、あるいはサーバーの接続数が多すぎて新しい接続を受け付けられないのかを知ることはできません。私たちのインフラ監視ツールはAPIエンドポイントを教えてくれますが、問題がどこにあるのかを突き止めるには十分ではありません。」 適切なロギングがなければ、システムの負荷や使用状況について把握することは困難です。Sentryをインストゥルメント化して以来、Yukiは顧客ベースの5%以上がアクセスできない2つのDB接続エラーを検出し、修正しました。 一旦警告が出されると、彼らはSentryで1分あたりのトランザクション（TPM）の指標を見ながら応答時間を追跡し、顧客が書き込みを始める前に問題を修正し、全員が請求書と税務情報にアクセスできるようにしました。 「私たちはサポートよりも早く、アラートとそれを解決するためのコンテキストを得たので、すぐにシステムをリブートしました。」 2日から2時間の短縮。コントロールの回復、問題の解決、不安の軽減 Sentryを導入して以来、Yukiのエンジニアリングチームは、より透明性の高いワークフローを実現し、開発者が自分のコードのパフォーマンスを管理できるようになりました。 「Sentryはリリースをプッシュするたびに不安を取り除いてくれます。以前はコントロールできませんでした。Sentryを使えば、問題を見つけるだけでなく、より深く掘り下げて解決するためのデータが得られるのです。」 […]
すべての開発者のためのパフォーマンス監視 ウェブ・バイタルと機能回帰の問題
パフォーマンス・モニタリング・ツールから適切な洞察結果を出すのは、フラストレーションが溜まるものです。一般的なモニタリングツールを使用すると、必要以上のデータが返されてしまい、そのデータを実際のソースコードで確認するまでに大変な手間がかかります。 Sentryが提供するパフォーマンス・モニタリングは、集中すべき課題をピンポイントで検出することで不要なデータを除外し、原因のコード行番号を的確かつ素早く表示します。その結果、より少ないノイズ、より実用的な結果として得ることができます。 本日、Web/モバイル/バックエンドの開発者がアプリのパフォーマンス問題を発見し、解決するための2つの新機能「Web Vitals」と「機能回帰問題」を発表します。 Web Vitals は、パフォーマンススコアから遅いコードまで確認可能 Web Vitalsは、ページの品質を測定するために、読み込み速度、インタラクティブ性、視覚的安定性のような指標として有効なもののみに統一しています。これらの指標を使用して、Web Vitalsメトリクスの加重平均を使用して計算された100点満点の正規化スコアであるSentry Performance Scoreを開発しました。 Sentryのパフォーマンス・スコアは、Google の Lighthouse のパフォーマンス・スコアと似ていますが、1つだけ重要な違いがあります。 それは、Lighthouseは管理されたラボ環境からデータを収集するのに対し、Sentryは実際のユーザー体験からデータを収集します。 私たちは、ラボ環境でしか関連性のないコンポーネントを除外しながら、Lighthouseにできるだけ近いスコアになるようにモデルを作成しました。 Web Vitals が最大の改善機会を特定する 全体的なパフォーマンス・スコアを向上させるには、パフォーマンスの改善が必要な個々の主要ページを特定することから始める必要があります。 これを簡素化し、すぐに本題に入るために、1つのページが全体のパフォーマンス・スコアに与える影響を示す「機会（Opportunity）」ごとにページをランク付けします。 それでは実際にSentry独自の課題の詳細ページをお見せします。この例では、Webアプリで最もアクセス機会の多いページを表示しています。これは当社の製品で最もよくアクセスされるページであるため、このページのパフォーマンスを向上させることは、Sentryの使用体験全体を大幅に改善することになります。 問題のあるページを特定したら、ユーザー体験が悪かったイベントを探します。 以下に、実際のユーザーが問題の詳細ページを読み込んでいることを示すイベントを表示します。 上のスクリーンショットでは、パフォーマンス・スコアが100点満点中9点（悪い）となったユーザーが表示されていますが、これは主に10秒以上のLargest Contentful Paint（LCP）が原因です。 このような最悪のケースは、ローカル開発中や理想的な条件下（ユーザーが高速ネットワーク接続やハイスペックなデバイスを使用している場合など）では明らかにならないパフォーマンスの問題を浮き彫りにしています。 これらのイベントの中には、『▶️（リプレイ）』ボタンがあることにお気づきでしょう。利用可能な場合は、そのページでのユーザーの実際の体験をビデオのように再現して見ることができます。アプリのパフォーマンスを最適化する場合、これらのリプレイは、ユーザーが劣悪な体験をしている場所を解析するのに役立ちます。 スパンウォーターフォールは、最も価値のあるオペレーションを強調します。 LCPが遅くなった原因を調べるには、イベントの「トランザクション」ボタンをクリックすると、ページ・ロード中に発生した操作の詳細な内訳が表示されます。これらの操作を「スパン」と呼びます。 最も関連性の高いスパンは、赤いLCPマーカーの前に発生するスパンで、これらのスパンはLCPブロックの可能性があるためです。LCPマーカーの後に発生するスパンは、ページ全体のパフォーマンスには影響を与えますが、最初のページロードには影響を与えません。 明らかにパフォーマンスのボトルネックになっているように見える最初のスパンは、app.page.bundle-loadスパンで、JavaScriptバンドルのロードにかかる時間を測定します。この場合、バンドルのロードだけでほぼ6秒、つまりLCPの総所要時間の約60％を要しています。 JavaScriptバンドルのロード時間は、主にそのサイズに依存します。バンドルのサイズを小さくすれば、ページ読み込み時間は大幅に改善されます。 しかし、バンドルの読み込み時間を50%短縮しても、LCPは12秒から7秒にしか短縮されません。 次の明確な改善箇所は、このui.long-task.app-initスパンに1秒近くかかっていることです。長いタスクのスパンは、ブラウザがJavaScriptコードを実行し、UIスレッドをブロックしている50ミリ秒以上の操作を表します。 これは純粋なJavaScriptの操作なので、さらに深く掘り下げて何が起こっているのか調べてみましょう。 ブラウザのプロファイリングは、ソースコードの原因となっている行を表示 従来までは、処理が長いタスクの原因となっているコードを特定することは困難でした。その理由は、プロファイラにアクセスできる開発環境で問題を再現する必要があったためです。 Sentryでは、これを解決するために本番環境（Chromiumベースのブラウザ）でブラウザJavaScriptプロファイルを収集するための新しいサポートを開始しました。これにより、実際のユーザーの問題をデバッグし、ユーザーベース全体で幅広いサンプルプロファイルを収集することができます。 以下の例では、ページ読み込みイベントに関連するプロファイルを開き、1秒ほどのタスクスパンの間に実行されたコードを見ることができます。 EChartsReactCore.prototype.componentDidMount関数の実行時間は558ミリ秒であり、これは長いタスクスパンの半分以上です。この関数は、オープンソースのEChartsビジュアライゼーション・ライブラリが提供するチャートをレンダリングするReactコンポーネントにリンクされています。これはまさに、Issues Detailsのページロード時間を短縮したい場合に注目すべき箇所のようです。 ここまでの流れを要約していきます。 まずパフォーマンス・スコアが低いページを特定します。 次に JavaScript バンドル・サイズを縮小して、特定の React コンポーネントを最適化することで、問題の詳細ページのパフォーマンスを大幅に改善できると判断しました。機会（Opportunity）スコアが高いページを見つけ、ページ読み込みイベントを分解し、プロファイルを使用して JavaScript パフォーマンスを深く掘り下げることで、製品の全体的なユーザー体験を向上させることができます。 Web […]
Sentry パフォーマンス – 関数回帰の問題： Pythonのプロファイリングの例
先日、アプリケーション全体で最も遅く、リグレッション（リリース後、パフォーマンスが低下）している関数を表示する機能を開始しました。 今回、新しいタイプのパフォーマンス・イシューで、関数レベルのリグレッションをデバッグできるようになりました。関数のリグレッション問題は、アプリケーションの関数がリグレッションしたときに通知されますが、単にリグレッションを検出するだけではありません。 関数リグレッションの問題は、Sentry Profilingをサポートしているプラットフォームであれば検出することができます。以下では、Pythonプロジェクトのバックエンドを例に説明していきます。 上のスクリーンショットは、Sentryのライブランニングサーバーコードのスローダウンを特定した、実際のFunction Regression Issueです。Redisに保存された顧客のレート制限をチェックする関数の持続時間が50%近くも後退したために発生しました。 上のグラフは関数の持続時間の経時変化を示し、下のグラフは呼び出し回数（スループット）を示しています。スループットもスローダウン期間中に増加していることがわかります。これは、負荷の増加がこの回帰の原因の1つである可能性を示唆しています。 上のスクリーンショットでは、同じ問題によって、どのAPIエンドポイントがリグレッションの影響を受け、どれだけパフォーマンスが後退したかといった他の重要な情報を見ることができます。このデータから、レート制限関数が多くのエンドポイントで広く使用され、呼び出された結果、バックエンド全体のパフォーマンスが大幅に低下したことがわかります。 回帰問題からプロファイルを確認して根本原因を見つける リグレッションした関数の問題では、リグレッションの前後にキャプチャされたプロファイルを簡単に確認できます。これらのプロファイルを比較することで、リグレッションの原因となった実行時の動作の変化を（コードレベルで）明らかにし、最も重要なコンテキストを提供します。 ここで実際に、リグレッションが発生する前にキャプチャされたプロファイル・イベントの例を見てみましょう。リグレッションが発生した関数は、サードパーティのredisモジュール内の2つの関数を呼び出していることに気づきました。 ConnectionPool.get_connectionとConnectionPool.releaseです。 これをリグレッション後に収集したプロファイルと比較したところ、これら2つの関数のうちの1つであるConnectionPool.get_connectionに以前よりも大幅に時間がかかっていることがわかります。 プロファイルの各関数フレームは、関数が定義された場所と実行された行番号のソース・コンテキストを提供します。この場合、redisモジュールでこのソースの場所を開くと、次の行（以下の画像参照）であることがわかりました。 この行はロックの取得を試みており、この行を実行したときの壁時間の大幅な増加は、複数のプロセスまたはスレッドが同時にロックを取得しようとしていることを示唆しています。このロックの競合がコード・レベルでのリグレッションの原因であることがわかります。 このロック競合の問題は、先にスループット・グラフで見たこと、つまりスループットが増加すると競合が起こりやすくなることとも一致しています。追加の調査を通じて、この関数のスループットの増加は、リグレッションの頃に始まったRedis接続数の増加に対応していることがわかりました。 今回の例を通じて、リグレッションした関数の問題が、プロファイリングデータを使ってリグレッションを引き起こしているコードに直接リンクするのに役立つことを説明しました。 今回の例はバックエンドのユースケースに焦点を当てていますが、この機能はSentry Profilingをサポートするどのプラットフォームでも機能します。 ファンクション・リグレッションの問題は、アーリー・アダプターの皆様には本日よりご利用いただけます。 結論 人々が使いたいと思うような差別化された製品を構築するためには、高性能なバーが不可欠です。ウェブ・バイタルとファンクション・レグレッション・イシューにより、すべての開発者がコードに接続することでパフォーマンスの問題を解決できる方法を提供していきます。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。