2

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

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

我能够匹配 tcp 数据包,它们通常在两个日志文件中彼此相距一毫秒。但是有一次,与wireshark相比,进程监视器中的最后一个数据包在进程监视器中延迟了超过250毫秒(并且正在观察应用程序的不稳定行为-由于延迟)。

由于 Wireshark 连接在另一台计算机上,我很确定所监控的内容是准确的:所有打包的文件都按时到达了网卡。至于进程监视器,我不完全确定它是如何工作的:网络数据何时注册?是到达网卡的时候吗?它何时可供应用程序使用?应用程序何时读取数据?

在这 250 毫秒期间,还注册了一些其他事件,这让我相信进程监视器正在正确记录,并且这 250 毫秒的延迟不是由它“创建”的。

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

4

1 回答 1

1

选项 2

也许您正在经历 GC 不时导致的臭名昭著的 250 毫秒延迟(链接)。您可以使用专门的 CLR 主机准确测量 GC 暂停(链接

选项 1 - 被排除

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

于 2010-09-25T18:23:30.323 回答