NetNamedPipe：通信空闲时改变响应时间
我有两个 WCF 应用程序通过命名管道进行单向通信。 一切都很好，除了一件事： 通常，请求/响应周期花费零（边际）时间。 但是，如果有一段时间（例如半分钟）没有任何通信，则请求/响应会增加到约 300-500 毫秒。
我环顾网络，想到了使用心跳/ping 机制来保持通信通道繁忙。 通过反复试验，我发现每 10 秒执行一次请求时，响应时间仍然很低。 从大约 15 秒的间隔开始，“打嗝”响应时间开始出现。
现在我想知道这种现象的根源在哪里。 我尝试将双方所有可能的超时设置为 > 1分钟，但这没有帮助。
有人能解释一下那里发生了什么事吗？
I have two WCF apps communicating one-way over named pipes. All is nice, except for one thing:
Normally, the request/response cycle takes zero (marginal) time. However, if there was a time span of, say, half a minute without any communication, the request/response increases up to ~300-500ms.
I looked around the net and I got the idea of using a heart beat/ping mechanism to keep the communication channel busy. Using trial and error I found that when doing a request each 10 seconds, the response times stay low. Starting at around 15s intervals, the "hiccup" response times begin to appear.
Now I'm wondering where this phenomenon is originating from. I tried setting alle conceivable timeouts on both sides to > 1 minute, but that did not help.
Can anybody explain what's going on there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看 Wenlong Dong 的博客文章 为什么 WCF 在空闲 15 秒后变慢？
该帖子还包括一个解决方法，直到它得到修复。
Check out Wenlong Dong's blog post, Why Does WCF Become Slow After Being Idle For 15 Seconds?
The post also includes a workaround until it gets fixed.
空闲进程是否有可能被分页到磁盘？ 如果让两端的进程保持忙碌，但不让连接忙碌，这种情况还会发生吗？
这很可能不是这样，但可能值得一试。
Is it possible that the idling process is being paged to disk? If you keep the processes at both ends busy, but don't make the connection busy, does it still happen?
That may well not be it, but it's possibly worth a try.