代码95%运行耗时去向不明？dotTrace分析Blazor Server应用疑问

dotTrace的「All Calls 100%」视图默认仅统计托管代码的主动执行耗时，你遇到的95%未显示耗时，大概率落在以下几个Blazor Server特有的场景或dotTrace的视图盲区里，按以下步骤排查：

• 切换到「Wait Time」视图：Blazor Server依赖SignalR通信，UI线程常处于等待客户端消息、数据库IO、外部API响应的阻塞/异步等待状态。这些等待时间不会计入托管代码的调用耗时，「Wait Time」视图会清晰展示这类耗时的分布，比如Async Wait、Lock Wait等。
• 查看「Native Calls」视图：.NET Runtime内部的原生操作、SignalR底层WebSocket通信逻辑、或调用的第三方原生库，这些非托管代码的耗时不会出现在普通的All Calls里，切换到该视图可捕获这部分开销。
• 检查GC停顿：若应用内存压力大，垃圾回收的停顿时间会占用大量CPU周期，但不会体现在常规调用栈中。打开dotTrace的「GC」标签页，查看Full GC次数、Gen 2 GC次数及对应的停顿时长。
• 确认视图过滤设置：检查是否误开启了调用栈过滤（比如仅显示自定义代码，排除了框架代码）。点击视图顶部的「Filter」按钮，确保未过滤System、Microsoft开头的命名空间，避免遗漏Blazor框架本身的耗时。
• 切换跟踪模式重新分析：如果使用的是采样模式（Sampling），对于短时间高频调用或阻塞等待，可能存在采样遗漏。尝试切换到**跟踪模式（Tracing）**重新运行分析（注意：该模式会增加应用性能开销，仅用于精准排查）。

针对Blazor Server的额外排查点：

• SignalR往返延迟：客户端与服务器的消息传递耗时属于网络IO等待，在「Wait Time」中会标记为Async Wait，可结合浏览器开发者工具的Network面板交叉验证。
• Razor组件异步渲染开销：组件渲染中的异步操作（如await数据库查询、API调用）的等待时间，需在「Async Calls」视图中查看异步方法的完整生命周期，这类耗时不会被同步调用栈统计。

内容的提问来源于stack exchange，提问作者David Thielen