問題タブ [dottrace]

dotTracePerformance4.5を使用して.NET3.5C＃Webアプリケーションのプロファイルを作成しています。1つの「ユーザーリクエスト」（ページのロード）を記録すると、ほぼ同じタイミング、7644ミリ秒の11のスレッドが表示されます。

• ほとんどのスレッドの説明には次のものしか含まれていません： 100％[ネイティブまたは最適化されたコード]-7644ミリ秒
• 1つは言う： 100％Microsoft.VisualStudio.WebServer.WebServerApp.Main(String[])
• 最後に読む：
  • 86％System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object)
  • 14％PerformWaitCallback（1094ミリ秒）>> 12％=ProcessRequest

教えて頂けますか：

• なぜこんなにたくさんのスレッドがあるのですか？（画像リソース、AJAX、JavaScript）
• 何PerformWaitCallbackですか？
• たった1094ミリ秒の作業でなぜ7644ミリ秒なのですか？

利用方法：

私は dottrace を使用していますが、このメソッドは CPU の 33% を使用しています。どうすれば最適化できますか。そのため、アプリケーションがクラッシュしたり、メモリ不足になったりします。このメソッドが静的であることは賢明ですか?

dottrace は、これで CPU の 30% の使用率を示します。

編集：

これがこのメソッドの機能に役立つことを願っています。strBegin と strEnd の間の文字列を検索してみてください...

dotTrace を使用する場合、プロファイリング モードと時間測定方法を選択する必要があります。 プロファイリング モードは次のとおりです。

• トレース
• 1行ずつ
• サンプリング

また、時間の測定方法は次のとおりです。

• ウォールタイム（パフォーマンスカウンター）
• スレッドタイム
• ウォールタイム（CPU命令）

トレースと行単位では、スレッド時間の測定を使用できません。それでも、7 つの異なる組み合わせを試す必要があります。私は今、これらの dotTrace のヘルプ ページを十数回以上読んでいますが、どれを選ぶべきかについて最初に知った以上の知識はありません。

Word ドキュメントを読み取り、すべての段落とスタイルを抽出し、その抽出されたコンテンツをループしてドキュメント セクションを選択する WPF アプリに取り組んでいます。このプロセスを最適化しようとしています。(現在、完了するまでに 1 時間以上かかるため、完了するまでではなく、一定の時間プロファイルを作成しようとしています。)

どのプロファイリングと時間測定タイプが最良の結果をもたらしますか? または、答えが「依存する」である場合、それは何に依存していますか? 特定のプロファイリング モードまたは時間測定方法の長所と短所は何ですか?

パフォーマンス テスト プロジェクトに基づいてプロファイル分析を実行するように dotTrace に指示する方法があるかどうかを調べてみました。

または、dotTrace がプロジェクトを監視している間 (Web 開発サーバーで実行中)、このテストを実行します。

これまでのところ解決策は見つかりませんでしたが、プロファイリングを実行するときは常に同じブラウジング フローを使用することが多いため、これは完璧な状況になると思います。

コマンドラインツールを備えているはずのdotTrace 5.0 EAPを使用していますが、それに関するドキュメントが見つからず、これが役立つかどうかさえわかりません。

どうすればこれを達成できるかについて誰にもアイデアがありますか?

JetBrainsdotTRACEMemoryを使用してIISでホストされているWCFWebアプリケーションのメモリ使用量をプロファイリングしようとしています。

過去に、この同じWebアプリケーションでdotTRACE Performanceを正常に使用し、すべてが正常に機能しましたが、dotTRACEメモリを起動できません。

メモリトレースを開始しようとすると、次のようになります。

JetBrainsからの（通常は良い）サポートドキュメントを検索しても何も見つかりませんでした。

何か案は？

サーバー：Windows 2008 R2（64ビット）
IIS：7.0
dotTRACEメモリ：3.5.360（現在利用可能な最新バージョン）

提供したいアプリケーションは、ActiveDirectoryアカウントを介してログインする専用のアプリケーションプールにあります。

タイトループで実行する必要のあるコード（.NET4 C＃）があります。他のスレッドは、このループを使用してスレッドに情報を非同期的に提供し、そのコマンドを処理します。コードは平均して十分に高速ですが（100〜200マイクロ秒）、約2秒に1回、さらに時間がかかります。通常は約15ミリ秒です。

これらのピークは平均をあまり変更しませんが、コードのどの部分で発生するかを調べたいと思います。平均は気にせず、最悪の場合の実行時間は気にしません。そのような情報を収集するためのツールはありますか？dotTraceを試しましたが、運が悪かったので、平均値を示しているだけなので、ほとんどの場合は無視したいと思います。

ストップウォッチなどを使用して独自のプロファイラーを作成するオプションは常にありますが、これらをコード全体にデプロイするのはかなり不器用です。

注：ビジーループでこれらのピークを引き起こすいくつかのコンテキストスイッチを期待する必要があることはわかっていますが、コードはこのアプリケーション専用の24コアサーバーで実行されます。したがって、どうにかしてそれらを最小限に抑えることができると思います。

最近、ファイル形式の書き込みライブラリを書き直しました。私は自分のコードが乱雑で、すべてが非常に複雑になり、一般的に保守を維持するのが難しいことに気づきました。

ですから、私の新しいライブラリはもっと​​整理されていてきれいです。古いライブラリでタスクを実行する方法の多くは、必要以上に複雑であることに気づきました。そのため、新しいコードの方がはるかに高速であると期待していました。

まあ、正確ではありません。最初に、.NetフレームワークのStopwatchクラスを使用してパフォーマンスをテストしました。私の古いライブラリは一貫して高速でしたが、数え切れないほどの改善と最適化があったため、私はショックを受けました。

次に、dotTracePerformanceProfilerを使用して両方をテストしました。予想通り、私の新しいライブラリはより高速でした-約2倍高速でした！私の古いライブラリは62ミリ秒で、新しいライブラリは28ミリ秒でした。

だから私は何が起こっているのかわかりません。Visual Studioでは、新しいライブラリの速度が大幅に低下します。実際、非常に一貫性がなく、00 :: 00::00.042から00::00::00.351の範囲になります。

なぜこれが起こっているのか誰かが知っていますか？dotTraceは2倍速いと言っており、Stopwatchは2〜4倍遅いと言っています。

皆様のご協力に感謝いたします。

• アレックス

編集：

コードは両方のライブラリで同じであり、どちらも新しいライブラリと古いライブラリを参照するだけです。これは、コンソールアプリケーションでテストされました。

dottrace を介して asp.net アプリケーションのリモート コンピューター デバッグを使用しています。

オプションを次のように設定しました：

しかし、[実行] をクリックすると、新しいモーダルが開かれますが、ボタンが無効になっています。

なぜこれらのボタンが無効になっているのか疑問に思っています。リモート asp.net Web アプリケーションをプロファイリングするにはどうすればよいですか?

dotTrace プロファイラーを使用しているときに、多くの呼び出しをNamespaceName.ClassName.ctor>b__11 受けています (アプリケーションで Equatec プロファイラーを使用したとき、不思議な関数が呼び出されて同様の結果が得られましたNamespaceName.ClassName.<ctor>b__11)。最初は のコンストラクターだと思っていましたが、 のコンストラクClassNameター内のブレークポイントはClassName1 回しかヒットしませんでした。私はこれが自動生成された関数であると仮定しています。ClassNameコンストラクターが一度しか呼び出されない場合、コンストラクターとはどのような関係がありますか?

Excel スプレッドシートを作成するために、ClosedXML ライブラリにアクセスする比較的単純なコンソール ユーティリティを作成しました。驚異的なことは何もなく、非常に高速に実行されるはずです。ただし、起動すると、進行状況を表示する前にコンソール画面に約 8 秒間表示されます。

最初は、これは ClosedXML ライブラリの初期化に時間がかかるものだと思いました。dotTrace を起動し、行ごとのパフォーマンス分析を実行したところ、いくつかの奇妙な結果が得られました。

• メインスレッド [14,352ms]
  • メイン [99.29% - 14,251ms]
    • 生成 [88.88% - 12,756ms]
      • 合計 23.44% / 4,360 ミリ秒の 11 のリストされた呼び出し
    • get_Instance [6.78% - 974ms]
    • Console.ReadLine [2.75% - 394ms]
    • ポリシーの解決 [0.82% - 118ms]
    • 11の隠し機能 [0.01% - 1ms]
  • ポリシーの解決 [0.20% - 29ms]
  • 0.51% / 72ms になる 7 つのリストされた呼び出し
• スレッド「.NET SystemEvents」[3,074ms]
  • スレッドスタート [100% - 3,074ms]
    • 実行 [99.6% - 3,072ms]
      • ThreadStart_Context [99.93% - 3,072ms]

を掘り下げるとThreadStart_Context、次のことがわかります。

• System.Threading.ThreadHelper.ThreadStart_Context(オブジェクト) [99.93% - 3,072ms]
  • Microsoft.Win32.SystemEvents.WindowThreadProc [99.90% - 3,071ms]
    • Microsoft.Win32.UnsafeNativeMethods.MsgWaitForMultipleObjectsEx [87.26% - 2,682ms]

MsgWaitForMultipleObjectsExプロファイラーによると、API は合計 26 回呼び出されます。これは、待機ごとに約 100 ミリ秒待機していることを意味します。

このGenerateメソッドは私が作成したもので、ClosedXML ライブラリと頻繁にやり取りします。操作の一部にはディスクへの書き込みが含まれますが、これは最後に、コンソール出力が表示された後に行われます。遅延は、作業が完了する前に発生します。

私の懸念は 2 つあります。

1. Generateメイン スレッドでの呼び出しの結果に 8,396 ミリ秒の時間差があるのはなぜですか?
2. への呼び出しが非常に多くMsgWaitForMultipleObjectsEx、合計 3 秒かかるのはなぜですか? これはスレッド同期が原因である可能性があることは理解していますが、アプリケーションにはスレッドが 1 つしかありません。

更新: 2 番目のスレッドが実際にメッセージ ループを処理していることがわかったので、そこで 5 秒間費やされたのは、処理するウィンドウ メッセージがない領域だけです。ただし、その 8 秒の不一致がどこにあるのかはまだわかりません。