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

我们的网络应用程序中存在延迟问题。大多数时间要求在100ms内处理。但有时可能会花费几秒钟，因为没有明显的原因。监控工具的准确性 - 调试应用程序延迟

所以我迷上了一些监控工具，抬头发生了什么事（Wireshark来通过端口复制和进程监视器外部监视在网络上看到发生了什么事在本地计算机上）。

我能匹配tcp数据包，他们通常在两个日志文件eachother毫秒内彼此。但是在一次事件中，与Wireshark相比，一系列的最后一个数据包在Process Monitor中延迟了250ms以上（并且由于延迟导致应用程序不稳定的行为正在被观察）。

由于Wireshark的就迷上了另一台电脑我敢肯定那是什么被监测是准确的：所有的包装都按时到达网卡。至于进程监视器我不完全确定它是如何工作的：网络数据何时被注册？它是否到达网卡？当它被提供给应用程序？当应用程序读取数据？

在这250毫秒有被注册其他一些事件，让我相信，进程监视器被正确记录，而这250ms的延迟不是由它“创造”。

有关进程监视器，我用它来挖下来的问题，或者您认为可能是这个问题，将不胜感激当前有哪些方法的行为任何帮助。

来源

2010-09-22 Benoittr

选项2

也许您遇到了臭名昭著的250毫秒的延迟，从时间GC原因时（link）。您可以使用专门的CLR主机（link）

准确地测量GC悬浮

选项1 - 被排除

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

来源

2010-09-25 18:23:30 Liran

Nodelay已启用。此外，由于我使用wireshark进行监控，并且数据包在发送部分没有任何延迟的情况下进入，所以我只能假设问题在本地。数据包及时通过网络，为什么它不能在本地计算机上“准时收到”？ – Benoittr 2010-09-27 13:03:33

@Benoittr，你有没有检查过250ms的延迟是否是由GC收集引起的？也许你正经历着GC不时引起的臭名昭着的250ms延迟（链接：http：//blogs.microsoft.co.il/blogs/sasha/archive/2009/07/31/garbage-collection-thread-悬浮液 - 延迟 - 250ms的-multiples.aspx）。您可以使用专门的CLR主机准确测量GC悬浮液（链接：http://blog.liranchen.com/2010/08/accurately-measuring-gc-suspensions.html） – Liran 2010-09-27 13:25:18

@Liran我一直在尝试测量GC在我的应用程序中跟随你的博客文章我稍微修改它以使用4.0中的新事物。目前我可以从主机加载一些示例c＃程序，但一旦出现第一次垃圾收集，方法SetAppDomainManager将在非托管代码中调用，并且c＃应用程序会因System.ExecutionEngineException而崩溃。仍在努力。最终我想要一个可配置的主机，它可以加载任何管理代码并报告GC持续时间。它可能已经存在，但我找不到任何东西。 – Benoittr 2010-09-28 15:19:33

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

回答

相关问题