「.NETアプリケーションのパフォーマンスの監視：アプローチとツール」、Dina Goldsteinのインタビュー

常に開発されたソリューションが許容可能なパフォーマンスで機能するとは限りません。 特に顧客のために。 また、メモリを購入してシステム要件を引き上げるという提案が機能しない場合（私は成功したことがありません）、最適化を行う必要があります。 このため、ストップウォッチだけでなく、DotNext 2016 Moscowカンファレンスで素晴らしい女の子であり、優れたスペシャリストであり、講演者であるDinaと話しました。 ゴールドスタイン 。



Dinaは、Aternityのシニアソフトウェアエンジニアです。 Aternityは、数百万台のPCおよびモバイルデバイス用の監視ツールを開発しています。 Dinaは、さまざまなソースからデータを収集するための主要なメカニズムを担当するチームで働いています。

監視ソリューションについて

-監視のための既成のソリューションは何ですか？ 彼らはどのくらい人気がありますか？ どのタスクを解決しますか？



-監視ツールは、組み込みユニットと個別の独立したプログラムの2つのメイングループに分けることができます。



最初のカテゴリには、ETW（Windowsのイベントトレース）やパフォーマンスカウンターなどのインフラストラクチャがあります。 それらはすでにWindowsにプリインストールされています。 .NET（またはC ++）APIを使用して、データ収集用の既成のソリューションを使用したり、ツールにコンポーネントを埋め込むことができます。 これらのソリューションは、まさにあなたが望むものを正確に実現するのに役立ちます。 しかし、ここでの主な言葉は実現することです。 基本的に、すべての作業を自分で行う必要があります。 はい、Windows API呼び出しをいつでもフックしてさらに多くのデータを取得できますが、これには特別なアプローチと注意が必要です。



完成したツールの中には、多くの製品があります。 また、コードに埋め込まれているライブラリ、たとえばNew Relic、プログラマーの介入を必要としない完全に既製の監視システム。 たとえば、Aternity、私はただ仕事をしています。



-遅かれ早かれ、十分な既製のツールがない場合に状況が発生します。 また、製品にコードを記述する必要があります。 .NET Frameworkと言語ツールは、開発を簡素化する何かを提供しますか？



-はい、間違いなく。 もちろん、パフォーマンスカウンターには便利な.NET APIがあり、Microsoftが開発中のTraceEventと呼ばれる無料で利用可能なNuGetパッケージを使用してETWを使用できます。 最近、ところで、同社はソースコードを公開しました。 リポジトリがGitHubで利用可能になりました。



これらは、一般的なアプローチに関するいくつかの言葉でした。 別個の.NETフレームワーク（WCF、WPF、Entity Frameworkなど）には、コードを埋め込み、必要なデータを収集できる拡張ポイントがあります。 もう1つの興味深いオプションは、ClrMDを使用することです。 これは、.NETのデバッグAPIのセットです（Microsoftがサポートするオープンソースでもあり、GitHubおよびNuGetで利用可能です ）。



ClrMDを使用すると、コールスタックを取得したり、マネージヒープを調べたりすることができます。 オーバーヘッドが高すぎるためだけに、このツールのみを使用して大規模な監視を行うことは不可能だと思いますが、他のツールを使用して問題を見つけた場合、ClrMDを使用すると特定の情報を取得できます。 たとえば、アプリケーションのヒープが大きすぎる場合は、どのオブジェクトが最もメモリを消費しているかを判断できます。



Win32 APIをさらに深く掘り下げたい場合は、NETが特に役立つことはないので、C ++に頼らなければなりません。 たとえば、 Microsoft Detoursを使用します 。

あなたはコントロールを失ってはいけません

-当社のソフトウェア製品が稼働しました。 コントロールを失いましたか、それとも情報を収集する方法がありますか？ これを行う最良の方法は何ですか？



-いや！ あなたがコントロールを失うことはありません。 サーバーまたはクラウド製品について話している場合は、もちろん、環境が完全に制御されているため、ニーズに合った監視ソリューションを使用できます。



デスクトップアプリケーションを開発している場合、ユーザーに監視フレームワークのインストールを要求することはできません。 これは、アプリケーションを独立して監視する機能を組み込む必要があることを意味します。 もちろん、ここでは、既製のライブラリ（New Relicなど）を使用することも、既に述べた.NET APIを使用して自分で実装することもできます。



実際、最近、パフォーマンスカウンターを使用して動作するプロセッサ負荷の監視をアプリケーションに追加するようマネージャーに説得し、特定のしきい値に達したら、ETWを使用してコールスタックの統計の収集を開始しようと試みました。



-どのような測定誤差が許容できると考えられ、どのようにそれを達成しますか？



-正確さは主な仕事ではないと思います。 製品がどのように機能するかを一般的に理解したいことは明らかです。 リリースされた製品の監視は、開発中のデバッグおよびプロファイリングと同じではありません。 たとえば、ClrMDを使用するなど、運用中により多くのデータを取得する方法は常にありますが、高い精度を支払う必要があります。 もちろん、時々これを行うことができますが、これまでのところ、私はその継続的な使用のポイントを見ていません。 パフォーマンスの問題に直面した場合、プロファイラーまたはデバッガーに短時間接続できます。 理想的なケースでは、監視は一般的なアイデアを提供し、問題が発見されたら、オフィスに戻ってローカルに再現し、専用ツールを使用して調べます。



-メソッドのパフォーマンスを測定する必要があるとしましょう。 しかし、サードパーティのアクションがこれに影響を与えないという確実性はありません。たとえば、ガベージコレクターです。 測定の落とし穴とその回避方法は？



-メソッドのパフォーマンスの意味によって異なります。 「アルゴリズム」パフォーマンスについて話している場合は、実際の環境での動作中に測定する必要はおそらくありませんが、テストをローカルで記述し、ガベージコレクションを停止し、スワップファイルをオフにし、ラップトップを電源に接続し、一般的に考えていることを実行できます必要です。



しかし、実際には、これらの中断がいつ発生するかを制御する方法はありません。 本当にできることは、中断が発生した時期と中断時間を取得することです。 ETWは、ガベージコレクタ、ネットワーク、ディスクアクセスなどに関する情報を提供します。 次に、これらすべてのデータを一緒に分析し、パフォーマンスについて結論を出すことができます。 具体的には、ガベージコレクターで重要な場所がある場合は、GC.TryStartNoGCRegionを使用できます。



-少しきれいな理論に触れましょう。 大量のデータを持つ大規模なシステムでは、数学の成果を使用したいという要望があります。 多くの理論がありますか？ 統計的手法はどれくらい人気がありますか？ ツールで使用されていますか？



「私が知っているツールはデータを収集するだけです。」 そして、誰もがこのデータを処理する方法を決定します。 留意すべきことの1つは、Windows APIをインターセプトする代わりにサンプリングを使用する場合があることです。WindowsAPIはパフォーマンスの点で非常に高価です。 本質的に、信用を落とすと、まれなイベントの数が過小評価される可能性があります。 これは、プロセッサの使用を測定する場合に特に顕著であり、測定は、小さなアクションに関する情報を統計的に取得するのに十分な時間を要することを確認する必要があります。 しかし、一方で、これらのささいなことは明らかにパフォーマンスの問題を引き起こすものではなく、より多くの時間とより少ない時間を把握したい場合にはおそらく重要ではありません。 そして、そのような測定で正確な実行時間を取得することは絶対に不可能です。

システム設計段階での監視について

-システムを設計するときに、将来の監視のために拡張ポイントを配置する必要がありますか？ 既存のアプローチと推奨事項はありますか？



-はい、間違いなく！ これについてはこれまで言及していませんが、独自のパフォーマンスカウンターとETWログを作成できます。 そのため、システムの開発中に、どの場所が興味深いか、どのデータを収集するかについて考える必要があります。 理想的には、DevOpsがプログラマーの介入なしに必要なすべてを監視できるように、システムを設計する必要があります。



-Visual Studioなどの開発ツールからの支援を待つ価値はありますか？



-ここでも、環境に依存します。 もちろん、Visual Studioには、開発中のプロファイリング用の優れたツールがあります。 ただし、アプリケーションの操作中は助けを待たないでください。 まず、プロファイリングには多くのオーバーヘッドがあるためです。 第二に、ライセンスの制限がある場合のみ、ユーザーのコンピューターにVisual Studioをインストールできません。 サーバーへのリモート接続があり、しばらくの間アプリケーションを停止できる場合は、Visual Studioリモートデバッガーを使用できます。 しかし、これはまだ監視ではなくデバッグです。



-多くは、監視中に取得した膨大な量の生データを処理する必要に直面しています。 自動化することは可能ですか？



「はい、もちろん。」 ETWを使用する場合、TraceEventを使用して、オンラインまたはオフラインでイベントを分析するいくつかの.NETコードを作成することもできます。 別のデータソースを使用し、結果が標準形式である場合、分析には任意のプログラミング言語を使用できます。 そしてもちろん、私たちの時代には、驚くほど多くの既製のプログラムと分析プラットフォームがあり、データを美しい形で処理し、ダッシュボードに動的に表示することができます。



-現在、監視ツールはどのような問題に直面していますか？ そして、開発はどの方向に向かっていますか？



-最も差し迫った問題はオーバーヘッドとデータの過剰摂取だと思います。 監視のため、大きなパフォーマンスシンクを許可することはできません。 さらに、ユーザーは、アプリケーションを再コンパイルまたは再起動することなく、監視対象と構成を動的に変更できる必要があります。 これは特に証券取引所と軍隊に当てはまります。



Windowsで特に不足しているもう1つのことは、eBFP for LinuxのようなWindows APIの呼び出しを動的にインターセプトする機能です。 現在、私たちは大量のデータに直面しているため、コントロールパネルはますます人気が高まっており、絶えず変化する要件に従って情報をグループ化し、動的に表示することができます。

---

ディナは 、12月9日にラディソンスラビャンスカヤホテルで開催されるDotNext 2016モスクワ会議の最初のセクションで講演します。 ここで登録できます 。



Dinaのレポートに加えて、次のことも聞くことができます。

⬝.NET Core：最先端

Hardwareハードウェアを絞ってパフォーマンスジュースを作る

⬝ インテリジェントなチャットボットと認知サービス

⬝ スタックオーバーフロー-パフォーマンスがすべてです！

⬝ 高度なXamarin.Forms

⬝C ++からC＃

arithmetic算術について話し続けます

⬝ASP.NET SignalR：Web開発で本当に重要になっている理由

。.NETの例外的な例外

runtimeランタイムでの.NETコードの変更

⬝ エンドツーエンドJIT

Stackスタックオーバーフロータグのパフォーマンスチューニング

＃C＃スクリプト-これまで考えもしなかった場所でC＃を使用できる理由と方法

⬝ マルチスレッドディープダイブ

Every すべてを集める、またはケーキに会う（C＃Make）

。.NET 開発者向けのWinDbg Superpowers

new新しい.NET Coreおよび.NET Platform Standardの概要

。.NET プラットフォームで見つかった脆弱性と、アプリケーションでそれらを繰り返さない方法

C C＃7の新機能