我们正在使用ServiceStack 3.9.71.0,我们目前通过WAN连接遇到客户端无法解决的延迟问题.
在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是否解决了这个问题.
解决方法:
我认为你在Update中提供了一个答案UseNagleAlgorithm = false应该解决这个问题.但要小心,因为ServicePointManager.UseNagleAlgorithm = false;是全局设置,这意味着它将为您的所有端点以及整个App域中的所有请求关闭此算法.当您使用混合大小的请求调用多个服务端点(通常就是这种情况)时,它会咬回来.因此,您应该考虑仅为一个特定的ServicePoint设置此项,您可以通过以下方式获取它：
ServicePoint sp = ServicePointManager.FindServicePoint(<uri>);
sp.UseNagleAlgorithm = false;
而不是全局设置