重要
JPデータセンターアカウント: この機能からのメール通知は、SendGridのEUエンドポイントを介して処理されます。これは、EUのデータプライバシー管理に関する日本の十分性認定に準拠しています。
Performance Risks inbox New Relicのテレメトリーデータの上にインテリジェントなレイヤーを追加し、アプリケーションのパフォーマンスの問題を継続的にスキャンして、本番環境のインシデントに発展する前にそれらを提示します。組み込みのアナライザーを使用して、設定可能な閾値でパフォーマンスの異常を自動的に検出し、類似した問題をグループ化することで、最も影響の大きい問題の解決にまず集中できるようになります。
カバレッジとスコープ
Performance Risks inbox アプリケーションスタック全体にわたる包括的な監視を提供します:
- APMサービス
- ブラウザ アプリケーション
- データベース操作
主なメリット
- プロアクティブな問題検出: パフォーマンスの問題が本番環境のインシデントに発展する前に特定します
- 平均解決時間(MTTR)の短縮: インテリジェントなグループ化により、最も重大な問題にまず集中できるようになります
- エンジニアリングの生産性向上: 手動でのパフォーマンス調査に費やす時間を減らし、イノベーションにより多くの時間を費やすことができます
- アプリケーションの信頼性向上: エンドユーザーに影響が及ぶ前にパフォーマンスのリスクに対処します

パフォーマンスリスクインボックスはどのように機能しますか?
Performance Risks inbox 最も一般的なパフォーマンスの問題を検出するために、以下のアナライザーを使用します:
使用事例
Performance Risks inbox インフラストラクチャコストの削減とアプリケーションパフォーマンスの向上という2つの重要な領域に対処するのに役立ちます。以下は、Performance Risks inboxがこれらの領域にどのように対処できるかを示すサンプルのユースケースです。
インフラストラクチャコストを削減
非効率的なコードパターンは、インフラストラクチャのコストに直接影響する不要なリソース消費につながります:
- N+1クエリ: 単一の最適化されたクエリを実行する代わりに、アプリケーションはリストを取得するために1つのクエリを実行し、その後、そのリスト内の各アイテムに対して個別のクエリを実行します。大規模な環境では、1つのクエリで同じ結果を返せるにもかかわらず、ユーザーが100回のデータベースクエリの完了を待つことは、データベースの負荷とリソース使用量の両方を不必要に増加させます。
- 大規模なHTTPペイロード: アプリケーションが大規模なAPIを呼び出し、ユーザーのインタラクションごとに完全なレスポンスを送信する場合、そのデータがインタラクションに必要でなかったとしても、cloudプロバイダーは各呼び出しの帯域幅とデータ転送に対して課金します。
アプリケーションパフォーマンスを改善
パフォーマンスの問題は、アプリケーションの速度と応答性に直接影響します:
- 順次データベースクエリ: ユーザーが2つの関連性のないデータをrequestsする場合、アプリケーションは最初のデータを取得し、それが完了するのを待ってから2つ目のデータを取得することがあります — 両方のクエリが独立しており、同時に実行できるにもかかわらずです。ユーザーは、はるかに早く返された可能性のある結果を必要以上に長く待つことになります。
- 遅いHTTPレスポンス: ユーザーがアプリケーションを操作した際に、長時間にわたってローディング状態が表示される場合、多くの場合、基盤となるAPIのパフォーマンスが低いことが原因です。ユーザーは、結果が表示されるまで遅いレスポンスを待たされます。