debugging - 监控工具准确性 - 调试应用程序延迟

Question

我们的一个网络应用程序存在延迟问题。大部分时间请求都在 100 毫秒内得到处理。但有时可能会无缘无故地花费几秒钟。

所以我连接了一些监控工具并查看发生了什么(Wireshark 通过端口复制从外部监控网络，Process Monitor 查看本地机器上发生了什么)。

我能够匹配 tcp 数据包，它们通常在两个日志文件中彼此相差不到一毫秒。但有一次，与 wireshark 相比，Process Monitor 中一系列数据包的最后一个数据包延迟超过 250 毫秒(并且观察到由于延迟导致的应用程序不稳定行为)。

因为 Wireshark 连接到另一台计算机上，所以我很确定所监视的内容是准确的:所有打包的数据都按时到达了网卡。至于 Process Monitor，我不太确定它是如何工作的:什么时候注册网络数据？是到达网卡的时候吗？何时提供给应用程序？应用什么时候读取数据？

在这 250 毫秒内，记录了一些其他事件，这让我相信 Process Monitor 正在正确记录并且这 250 毫秒延迟不是由它“创建”的。

任何有关 Process Monitor 行为的帮助，我用来挖掘问题的当前方法或您认为可能是问题的方法，我们将不胜感激。

Answer 1

选项 2

也许您正经历着臭名昭著的 250 毫秒延迟，这是 GC 不时造成的 (link)。您可以使用专门的 CLR 主机 (link) 准确测量 GC 暂停

选项 1 - 被排除

<罢工>由于您使用的是 TCP，我建议您打开 NoDelay套接字上的选项只是为了消除您遭受 Nagle 算法和延迟 ACK 算法之间冲突的可能性。如果您遇到数据包的“批处理”，而有时数据包会“延迟”大约 200 毫秒，那么这可能就是问题所在。
可以找到对此行为的更深入解释 here .