问题标签 [dottrace]

我正在使用 dotTrace Performance 4.5 来分析 .NET 3.5 C# Web 应用程序。当我记录一个“用户请求”（页面加载）时，我看到 11 个线程的时间大致相同，即 7644 毫秒。

• 大多数线程描述仅包含： 100% [本机或优化代码] - 7644 ms
• 一说： 100%Microsoft.VisualStudio.WebServer.WebServerApp.Main(String[])
• 最后一篇写道：
  • 86%System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object)
  • 14% PerformWaitCallback(1094 毫秒) >> 12% =ProcessRequest

你能告诉我吗：

• 为什么会有这么多线程？（图片资源、AJAX、JavaScript）
• 是什么PerformWaitCallback？
• 为什么只有 1094 毫秒的工作需要 7644 毫秒？

用法：

我正在使用 dottrace，这种方法占用了我 33% 的 CPU。我该如何优化它。因为它我的应用程序崩溃或者我的内存不足。这种方法是静态的聪明吗？

dottrace 显示 30% 的 cpu 使用率：

编辑：

希望这有助于这种方法的作用。尝试在 strBegin 和 strEnd 之间查找字符串...

使用 dotTrace 时，我必须选择分析模式和时间测量方法。 分析模式是：

• 追踪
• 逐行
• 采样

时间测量方法有：

• 挂时（性能计数器）
• 线程时间
• 挂墙时间（CPU 指令）

跟踪和逐行不能使用线程时间测量。但这仍然让我有七种不同的组合可以尝试。我现在已经阅读了十多次关于这些的 dotTrace 帮助页面，但我仍然没有比我开始选择哪个更了解。

我正在开发一个 WPF 应用程序，该应用程序读取 Word 文档，提取所有段落和样式，然后遍历提取的内容以挑选文档部分。我正在尝试优化这个过程。（目前它需要一个多小时才能完成，所以我试图在给定的时间长度内对其进行分析，而不是直到它完成。）

哪种分析和时间测量类型会给我最好的结果？或者如果答案是“取决于”，那么它取决于什么？给定的分析模式或时间测量方法的优缺点是什么？

我试图弄清楚是否有办法告诉 dotTrace 根据性能测试项目执行配置文件分析。

或者在 dotTrace 监控项目时运行此测试（在 Web 开发服务器中运行）。

到目前为止，我还没有找到任何解决方案，但我认为这将是一个完美的情况，因为很多时候，当我运行分析时，我总是使用相同的浏览流程。

我正在使用 dotTrace 5.0 EAP，它应该有一个命令行工具，但我找不到任何关于它的文档，我什至不知道这是否可以帮助我。

任何人都知道我如何实现这一目标？

我正在尝试使用 JetBrains dotTRACE Memory 分析 IIS 托管的 WCF Web 应用程序的内存使用情况。

过去，我在同一个 Web 应用程序上成功使用了 dotTRACE Performance，一切正常，但我无法启动 dotTRACE Memory。

当我尝试启动内存跟踪时，我得到的只是：

搜索 JetBrains 的（通常很好的）支持文档一无所获。

有任何想法吗？

服务器：Windows 2008 R2（64 位）
IIS：7.0
dotTRACE 内存：3.5.360（截至今天的最新可用版本）

我要提供的应用程序位于通过 Active Directory 帐户登录的专用应用程序池中。

我有一段代码（.NET4 C#）应该在紧密循环中运行——其他线程通过这个循环异步向线程提供信息并处理它的命令。该代码平均足够快（100 - 200 微秒），但大约每 2 秒一次需要更多时间，通常大约 15 毫秒。

这些峰值并没有太大改变平均值，但我想找出它们发生在代码的哪些部分——我不关心平均值，而是关心最坏情况下的执行时间。是否有任何工具可以收集此类信息？我试过 dotTrace 但没有运气，它只显示平均值，我想忽略大多数情况。

总是可以选择使用秒表等编写我自己的分析器，但是在整个代码中部署这些是相当笨拙的。

注意：我知道我应该预料到一些上下文切换会导致这些峰值与繁忙循环，但代码是在专用于该应用程序的 24 核服务器上运行的。因此，我希望我能以某种方式将它们减少到最低限度。

我最近重新编写了我的文件格式编写库。我意识到我的代码很乱，让一切都变得太复杂，而且通常很难维护。

所以我的新图书馆更有条理和干净。我意识到我在旧库中完成任务的许多方法比它需要的要复杂得多，所以我希望我的新代码更快。

嗯，不完全是。我首先使用 .Net 框架中的 Stopwatch 类来测试性能。我的旧库始终更快，这让我感到震惊，因为有太多的改进和优化无法计算。

然后我使用 dotTrace Performance Profiler 对两者进行了测试。正如预期的那样，我的新库更快了——快了大约 2倍！我的旧库测量了 62 毫秒，而我的新库测量了 28 毫秒！

所以我不确定发生了什么。在 Visual Studio 中，我的新库要慢得多 - 事实上，它非常不一致，它的时间范围从 00::00::00.042 到 00::00::00.351！

有谁知道为什么会发生这种情况？dotTrace 说它快 2 倍，秒表说它慢 2-4 倍。

感谢大家的帮助。

• 亚历克斯

编辑：

两个库的代码相同，都只是引用新旧库。这是在控制台应用程序上测试的：

我正在通过 dottrace 为我的 asp.net 应用程序使用远程计算机调试。

我已将选项设置为：

但是当我单击“运行”时，会打开一个新模式但禁用按钮：

我想知道为什么这些按钮被禁用。如何配置我的远程 asp.net Web 应用程序？

在使用 dotTrace 分析器时，我收到了很多调用NamespaceName.ClassName.ctor>b__11 （当我在我的应用程序上使用 Equatec 分析器时，我得到了类似的结果，调用了神秘的函数NamespaceName.ClassName.<ctor>b__11）。我首先假设它是 的构造函数，ClassName但是构造函数内部的断点ClassName只被击中一次。我假设这是自动生成的函数，如果它是我如何找到它被调用的位置？ClassName如果构造函数只被调用一次，它与构造函数有什么关系？

我编写了一个访问 ClosedXML 库的相对简单的控制台实用程序，以生成 Excel 电子表格。没有什么令人兴奋的，它应该运行得非常快。但是，当我启动它时，它会在控制台屏幕上停留约 8 秒，然后才会显示任何进度。

起初，我认为这是 ClosedXML 库需要一段时间来初始化。我启动了 dotTrace 并逐行进行性能分析，得到了一些奇怪的结果：

• 主线程 [14,352ms]
  • 主要 [99.29% - 14,251 毫秒]
    • 生成 [88.88% - 12,756ms]
      • 11 个列出的调用总计 23.44% / 4,360ms
    • get_Instance [6.78% - 974ms]
    • Console.ReadLine [2.75% - 394ms]
    • ResolvePolicy [0.82% - 118ms]
    • 11个隐藏函数[0.01% - 1ms]
  • ResolvePolicy [0.20% - 29ms]
  • 7 个列出的调用加起来为 0.51% / 72ms
• 线程“.NET SystemEvents”[3,074 毫秒]
  • 线程启动 [100% - 3,074 毫秒]
    • 运行 [99.6% - 3,072 毫秒]
      • ThreadStart_Context [99.93% - 3,072ms]

现在，如果我们深入ThreadStart_Context研究 ，我们会看到以下内容：

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

据分析器称，该MsgWaitForMultipleObjectsExAPI 总共被调用了 26 次。这意味着它每次等待大约等待 100 毫秒。

该Generate方法是我编写的，它与 ClosedXML 库进行了很多对话。部分操作涉及写入磁盘，但在控制台输出应该出现之后，最后完成了。延迟发生在任何工作完成之前。

我的担忧有两个：

1. Generate为什么在主线程调用下结果会有8396ms的时间差异？
2. 为什么有这么多的调用MsgWaitForMultipleObjectsEx，总共需要 3 秒？我知道这可能是由于线程同步造成的，但应用程序中只有 1 个线程。

更新：好的，所以我发现第二个线程实际上是在处理消息循环，所以在那里花费的 5 秒只是没有任何窗口消息要处理的区域。不过，仍然不确定 8 秒的差异来自哪里。