在200ms之后接收具有非常小的有效载荷(<100字节)的回复. 由于地理距离,链路上的往返时间(RTT)约为40ms.这已通过ping其他主机并使用简单的echo服务来测试TCP连接的延迟来验证. ping和echo测试都显示出与预期一致的延迟.从我们的ServiceStack主机获得回复所需的时间比预期的要长. 我们已经证实:
> WAN链路仅以25%的容量运行(无拥塞)
> WAN链路上没有使用QOS
>同一主机可以快速回复来自本地网络上不同主机的相同请求
>延迟不是由我们处理请求的代码引起的
我们现在偶然发现了Nagle的算法,这可能意味着WAN网络上的小请求延迟(http://blogs.msdn.com/b/windowsazurestorage/archive/2010/06/25/nagle-s-algorithm-is-not-friendly-towards-small-requests.aspx).
在.NET中,可以通过设置TcpClient.NoDelay = true(https://msdn.microsoft.com/en-us/en-US/library/system.net.sockets.tcpclient.nodelay(v=vs.110).aspx)来禁用它.
如何禁用ServiceStack的TCP处理?
编辑:我不认为这是HttpWebRequest is slow with chunked data的副本.上述问题涵盖了ServiceStack未使用的HttpWebRequest. ServiceStack使用HttpListener,它也恰好由提到的ServicePointManager控制/管理.我们将进行一项测试,看看设置ServicePointManager.UseNagleAlgorithm = false是否解决了这个问题.
解决方法
ServicePoint sp = ServicePointManager.FindServicePoint(<uri>); sp.UseNagleAlgorithm = false;
而不是全局设置
这是一篇关于它的文章:https://blogs.msdn.microsoft.com/windowsazurestorage/2010/06/25/nagles-algorithm-is-not-friendly-towards-small-requests/
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。