4

現在、(C#) アプリのパフォーマンス分析のために PerfView を使用しています。ただし、通常、これらのアプリは多くのデータベース呼び出しを使用します。そこで、次のような質問を自問しました。 - リポジトリでどれくらいの時間が費やされているか - (SQL クエリが返されるのを待つのにどれくらいの時間が費やされていますか?) -> これが PerfView で発見できるかどうかさえわかりません

しかし、私のトレースからは、有用な結果はほとんど得られません。「Any Stacks」ビューでは、（リポジトリでグループ化を使用すると）リポジトリで1.5秒が費やされることがわかります（呼び出し全体は約45秒です）。リポジトリはデータベースを大量に呼び出すため、これは実際には真実ではないことを私は知っています。

CPU はこの期間に何もすることがないため、SQL クエリが完了するのを待っているときに CPU メトリックがキャプチャされないため、私の時間にはリポジトリのデータ変換時間などが含まれているだけですか?

助けてくれてありがとう！

編集：

私が見逃したのは、スレッド時間オプションをオンにして、ブロックされたコードの時間を取得することです(これは、データベース呼び出し中に起こっていると思います)。これですべてのスタックを取得しました。興味のないものを除外するだけです。しかし、私はどこにも行かないようです。

「スレッド時間」を使用するときに特に興味深いのは、BLOCKED_TIME です。しかし、それで時代はずれていると思います。スクリーンショットを見ると、CPU_TIME が 28,384 であることがわかります。これはミリ秒 (afaik) ですが、BLOCKED_TIME は 2,314,732 であり、ミリ秒にはなりません。したがって、CPU_TIME のパーセンテージは 1.2% と非常に低くなりますが、70 秒のうち 28 秒は依然として多いです。したがって、包括的パーセンテージの時間は、ここではリンゴとオレンジを比較しています。誰か説明できますか？

パフォーマンス ビュー

4

1 に答える 1

5

それで、私は成功しました。

私が見逃したのは (Vance Morrison が彼のビデオ チュートリアルで実際に説明していた) は、次のとおりです。perfview で壁時計の時間分析を行うと、「BLOCKED_TIME」と呼ばれるもので「待機」しているすべてのスレッドから累積時間が得られます。 . つまり、70 秒間、ファイナライザー スレッドだけがこの "BLOCKED_TIME" に 70 秒を追加します。

したがって、実時間分析を行うときは、関心のあるものを除外することが重要です。たとえば、最も CPU 時間を消費していたスレッドを検索し、これを分析に含めて、スタックをさらに下に移動して見つけます。高価なコードの一部 (DB またはサービス呼び出しにつながる可能性もあります)。メソッドの観点から分析するとすぐに、このメソッドで費やされた時間が実際に得られ、累積された「BLOCK_TIME」は見えなくなります。

私が最も便利だと思ったのは、自分のコードで「時間がかかると思われる」メソッドを検索することです。このメソッドの呼び出し元ビューに切り替えました。これは、呼び出された場所と、呼び出し先のビューで、スタックのさらに下の消費時間の原因を明らかにします (リポジトリ内の DB 呼び出しまたはデータを取得するためのサービス呼び出し)。

説明するのは少し難しいですが、実時間分析の基本を本当に理解するとすぐに、ある時点ですべてが理にかなっています.

このビデオ チュートリアルをお勧めします: http://channel9.msdn.com/Series/PerfView-Tutorial

繰り返しますが、素晴らしい非常に強力なツールです。

于 2015-02-27T15:13:27.263 に答える