ASP.NET パフォーマンスの監視と最適化の概要
- 巴扎黑オリジナル
- 2017-04-08 14:01:051558ブラウズ
キーポイント:
インフラストラクチャ メトリックは、アプリケーション メトリックにリンクされている場合にのみ最も効果的です。
効率的なパフォーマンスの最適化の鍵はパフォーマンス データにあります。
一部の APM ツールは、すぐに使用できる ASP.NET のサポートを提供するため、ASP.NET を使い始めるには最小限の初期設定が必要です。
コード分析ツールを使用すると、プログラムのパフォーマンスを最も詳細に把握できます。
この軽量の分析ツールは、Web ページのパフォーマンスをリアルタイムで表示し、開発環境と運用環境の両方で使用できます。
「この Web ページを開くのが遅すぎる!」 Web サイトに関するこの苦情は、特に Web アプリケーションが徐々にデスクトップ アプリケーションに取って代わり始めて以来、頻繁かつ一般的です。 Web はグローバル配信などの理想的な機能をもたらしますが、それに対応するパフォーマンス レベルの課題ももたらします。
データの収集と使用の基本原則
ユーザーが「遅い」Web ページの URL を教えてくれた場合、どうすればよいでしょうか? Web ページを開くのが遅いという問題はどこから来るのでしょうか?最初からそんなに遅かったっけ？すべてのユーザーにとって遅いですか? Web ページを開くのが遅いという問題を解決し、1 週間後に再び遅くならないようにするには、このような問題が数多くあります。
パフォーマンスの最適化に関する情報はインターネットでも検索できますが、通常は、Jit、ガベージ コレクション、SQL クエリの最適化、ORM トラップなどの特定のトピックに関するものです。最適化を実装するという魅力的な見通しを考えると、次のような疑問が生じます。選択した最適化方法が、現在のパフォーマンス問題に対して実際に良い結果を生み出すかどうかは、どのようにしてわかるのでしょうか?
この作品には何かが欠けていることは間違いありません。パフォーマンスの問題を持続的に発見する方法が必要です。このアプローチを使用すると、システムの遅い部分を特定し、パフォーマンスの問題の診断をサポートする具体的な対策を講じることができます。パフォーマンスの問題がどこにあるのかを理解したら、パフォーマンスの改善が必要かどうかをさらに判断し、そのすべてを関係者に説明できます。
上記で見つかったパフォーマンスの問題については、正確に特定することがより効果的な対処方法です。そもそも問題は、Web ページの読み込みが遅いことではない可能性があります。タイムアウトが存在する場合 (たとえば、ロード バランサーが接続を処理する前に数秒待機する場合があります)、これがデッドロックの問題なのか、それとも応答時間の遅さの問題なのかを判断することはできません。両方の問題が引き起こす原因は同じであるためです。タイムアウト。これには、問題の本当の原因を見つけるためのデータが必要です。
パフォーマンスの問題を正確に特定することの重要性を説明するために、Web アプリケーションの応答遅延の原因となる可能性のあるトラブルシューティングのポイントをいくつか示します。
JavaScript の応答が遅いです
リソースの読み込みに障害があります
クライアント側にはプロキシがあります
DNS の問題; ISP またはネットワークの問題
スイッチとルーター
ロードバランサー; アプリケーションコード (サードパーティのソフトウェアライブラリを含む); HTTP サーバー (場合によっては ASP.net や IIS など)。 サードパーティ サービス: 決済サービス プロバイダー、地図サービス プロバイダーなど。 サブシステム（SQL Server、Redis、Elasticsearch、Rabbit MQ など）
-
対処するシステムの複雑さと規模に応じて、追加のパフォーマンスのトラブルシューティング ポイントをリストすることもできます。非常に多くのシステム コンポーネントがパフォーマンスの最適化の問題に影響を与える可能性がある場合、パフォーマンスの問題をどのように診断すればよいでしょうか?その答えは「データ」という一言で要約できます。すべてのシステム コンポーネントからの関連性のある意味のあるデータが必要です。 Web アプリケーションの応答が遅いという問題については、各システム コンポーネントが問題に影響を与えているか、それともまったく無関係であるかをデータで証明できます。
データが手元にあれば、ソート ツリーで検索するのと同じように、アイデアに従って上記のリストからトラブルシューティングのポイントを抽出して分析を始めることができます。ツリーのレベルを 1 つ下げるたびに、パフォーマンスの問題の詳細と本質に近づき、パフォーマンスの問題が次の場所に存在するかどうかを特定します。 クライアント側、サーバー側、あるいはその中間のどこかでしょうか? -
JavaScript、レンダリング、またはリソースのブロックが遅いですか? -
ロード バランサー、Web サーバー、サブシステム、またはサードパーティ製ソフトウェアはありますか?
このようなツリーをレベルごとに下に進むにつれて、パフォーマンスの問題がますます明らかになります。トラブルシューティングの各レベルで、パフォーマンスの問題を特定するために必要なデータは、対応する問題の精度と一致する必要があります。このとき、パフォーマンス分析ツールやSQL実行プランなどのツールを使用する必要があります。
時間を有効に使うためには、アムダールの法則を繰り返す必要があります:
タスクがどれだけ改善されても、改善の恩恵を受けないタスクの部分により、理論上のタスクの高速化は制限されます。
たとえば、Web リクエストでは、100 ミリ秒のサーバー処理時間と 5 秒の SQL クエリ時間が必要であると想定されます。サーバーの処理時間を 1 ミリ秒未満に最適化できたとしても、全体的な応答時間の改善は 5.1 秒から 5 秒とわずかです。 SQL 処理を改善するのに必要な 5 秒は、最大の効果が得られる最適化です。
アーキテクチャの問題
最適化問題をレイヤーごとに明確にするこのトップダウンの方法は、単一ページに限定された最適化問題に効果があります。では、複数のページにまたがる最適化問題に適用すると、どのような効果があるのでしょうか?たとえば、一部のページを開くのが断続的に遅くなる問題は、サブシステムが全体的な作業リズムについていけていないこと、またはシステム内に古いネットワーク スイッチが存在し、再起動後に機能しなくなる可能性があることが原因です。
この場合、アプリケーションに重点を置いた監視アプローチには限界があります。これには、システム内の各コンポーネントを評価するために、より多くのソフトウェア レベルおよびハードウェア レベルのメトリックが必要です。
ハードウェア レベルで最初に思い浮かぶのは、Web サーバーとデータベース サーバーですが、それらは氷山の一角にすぎません。すべてのシステムのハードウェア コンポーネントを識別して監視する必要があります。これには、サーバー、ネットワーク スイッチ、ルーター、ロード バランサー、ファイアウォール、SAN などが含まれます。
システム管理者の通常の仕事がハードウェアの監視であることを考えると、上記の指標はすべてシステム管理者にとって明らかである可能性があります。ただし、ここで重要な注意点があります。これらのハードウェア メトリクスのほとんどは、ソフトウェア メトリクスとは別に扱われると、パフォーマンスの観点からは役に立ちません。言い換えれば、インジケーターは適切な環境に置かれた場合にのみ最適に機能します。
たとえば、場合によっては、データベース サーバーの CPU 使用率が平均 50% になるのはごく普通のことですが、他のサーバーにとっては時限爆弾となります。 CPU 使用率が 50% である場合、ピーク時に、より重いタスクを実行する余地がまだたくさんあることを意味します。ただし、アイドル期間中に 50% の CPU 使用率が頻繁に発生する場合、アプリケーションが受信リクエストの突然の急増に耐えられない可能性があることを意味します。
肝心なのは、システムの健全性を評価するには、CPU、メモリ、ディスクなどのシステム全体のメトリクスをアプリケーションのメトリクスと相関させる必要があるということです。システムの健全性をより完全に把握するために、リクエスト スループットなどのアプリケーション メトリクスや CPU 使用率などのシステム メトリクスを視覚化できます。
アプリケーションパフォーマンス管理 (APM) ツール
APM ツールは、データ収集、データ保存、データ視覚化などの基本的な操作を提供します。通常、エージェントはデータを収集してデータ ストアに送信し、Web インターフェイスを使用して Web リクエストに重点を置いたダッシュボードでデータを視覚化する責任を負います。
APM は次の目的で使用できます:
Web アプリケーションのパフォーマンスの全体的な視覚化
特定の Web リクエストのパフォーマンスを視覚化します
Web アプリケーションのパフォーマンスが低下したり、複数のエラーが発生した場合に自動的にアラートを送信します
業務量が多い場合は、アプリケーションの応答モードを確認してください。
ここでは例を示します。
以下は、ASP.NET と IIS をサポートする APM ツールの完全なリストではありません:
NewRelic APM
Application Insights
AppDynamics
Stackify
インフラストラクチャ監視ツール
インフラストラクチャ監視ツールはホスト レベルでメトリクスを収集し、パフォーマンスをより完全に反映できます。これらのメトリクスは、ハードウェア レベルとソフトウェア レベルで収集されます。
データドッグ
OpServer - オープンソース
軽量分析ツール
軽量の分析ツールは、特定の Web リクエストに対する高レベルのメトリクスを提供し、開発者が Web ページを閲覧するときにリアルタイムのフィードバックを提供します。これらのツールは、あらゆる種類の環境 (開発環境、QA 検証、ステージング環境、運用環境など) で使用できるため、特定のページのパフォーマンスを迅速に評価するのに最適です。
対応するフル機能の分析ツールと比較した場合、軽量分析ツールの本質的な違いは、軽量分析ツールがプロセスに関連付けられていないことです。つまり、軽量分析ツールの使用時に生成されるオーバーヘッドを心配する必要がありません。
開発環境では、軽量の分析ツールが現在作成中のコードに関するリアルタイムのフィードバックを提供します。応答時間は常にページの隅に表示されるため、N+1 や遅い応答時間などの問題を特定するのに非常に役立ちます。
オープンソース MiniProfiler
オープンソースの Glimpse
パフォーマンスカウンターでギャップを埋めましょう
Windows システムのパフォーマンス カウンター (パフォーマンス カウンター) は、ハードウェア レベルとソフトウェア レベルでさまざまなインジケーターを提供します。監視ツールは、CPU やメモリの使用量などのパフォーマンス カウンターを報告することがよくあります。ただし、多くの場合、ガベージ コレクション時間など、いくつかの有用なカウンターが欠落しています。最も現実的な方法は、基本的なリストを使用し、必要な関連カウンターを反復内に追加することです。さらに、perfmon を使用してパフォーマンス カウンターをリアルタイムで収集し、視覚化することができます。多くの場合、ユーザーがカスタマイズしたインジケーターやプラグインを APM ツールと統合することも可能です。
SQL ツール
データベースは多くのアプリケーションで一般的に使用されるため、永続化レイヤー (SQL データベースなど) がパフォーマンスのボトルネックになることがよくあります。 SQL 監視用のプロフェッショナル ツールは、リソース使用量のメトリックだけでなく、待機時間や 1 秒あたりのコンパイル数などの特定のメトリックも提供できます。
次のデータを提供することにより、いくつかの種類の問題を発見し、パフォーマンスを改善することができます:
1 つまたは複数のクエリでの過剰なスループット
過剰な CPU 使用率。クエリの問題またはインデックスの欠落を示唆します
キャッシュできる高スループットのクエリ。
SQL 監視ツールには次のものが含まれます:
RedGate SQL モニター
SQLSentry パフォーマンス アドバイザー
他の永続化システム
すべてのサブシステムをある程度監視する必要があります。スループットが低いシステムやクリティカルではないシステムの場合は、単純なデータ収集と視覚化で十分です。より高度な専門的なモニタリングが必要な場合もあります。
コード分析ツール
特定のページまたはコード部分が遅いと特定された場合、コード分析ツールはパフォーマンスの問題を特定するために可能な限り詳細なビューを提供します。コード分析ツールは、データベース クエリや Web リクエストなどの外部呼び出しの正確なビューも提供します。
分析ツール:
レッドゲート・アント
JetBrains ドットトレース
メモリ分析ツール
メモリの監視とガベージ コレクションのメトリクスは、潜在的な問題の検出に役立ちます。しかし、これらの指標は問題があることを示していますが、多くの場合、問題がどこにあるのかはわかりません。メモリとガベージ コレクションの問題をさらに詳しく調べる必要がある場合は、メモリ分析ツールが役立ちます。
分析ツール:
JetBrains dotMemory
RedGate Ants メモリ プロファイラー
顧客分析ツール
パフォーマンスの問題はフロントエンドからも発生する可能性があります。この問題は、JavaScript を利用したシングルページ アプリケーションの普及により、現在では非常に一般的になっています。すべての主要なブラウザには、コード分析やメモリ分析などのツールが組み込まれています。イベントとリクエストのシーケンスを表示するツールは、問題の原因がフロントエンドなのかバックエンドなのかを一目で判断するのに役立ちます。
ツール:
Google Chrome タイムライン
Firefox
ページ分析ツール
高レベルのクライアント ツールは、パフォーマンスの問題を特定して解決するための便利な開始点を提供します。これらのツールは、応答時間の問題の根本原因の概要を提供し、対応する推奨事項をいくつか提供します。たとえば、Google の PageSpeed Insights は非常に無料のツールです。
システムのパフォーマンスに関連する要素やツールは非常に多く、非常に複雑に思えます。しかし、それらは「データ」という一言で要約できます。システムを明確かつ正確に把握することで、パフォーマンスの問題について推論することが可能になります。これにより、パフォーマンス メトリクスとグラフがシステム パフォーマンスに正確に影響を与えている原因を発見できるため、パフォーマンスの問題をその場でトラブルシューティングする方法を学ぶこともできます。
以上がASP.NET パフォーマンスの監視と最適化の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。