4

我们正在使用 ServiceStack 3.9.71.0，我们目前在通过 WAN 连接的客户端遇到无法解释的延迟问题。

200ms+ 后收到带有非常小的有效负载（<100 字节）的回复。

由于地理距离，链路上的往返时间 (RTT) 约为 40 毫秒。这已通过 ping 另一台主机并使用简单的回显服务来测试 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的副本。提到的问题涵盖HttpWebRequest了 ServiceStack 不使用的问题。ServiceStack 使用HttpListener也恰好由上述ServicePointManager. 我们将进行测试，看看设置是否能ServicePointManager.UseNagleAlgorithm = false解决问题。

4

1 回答 1

2

我认为您在 Update UseNagleAlgorithm = false 中提供了答案应该可以解决此问题。但要小心，因为ServicePointManager.UseNagleAlgorithm = false;它是一个全局设置，这意味着它将为您的所有端点以及整个应用程序域中的所有请求关闭此算法。当您使用混合大小的请求调用多个服务端点（通常是这种情况）时，它会反击。所以你应该考虑只为一个特定的 ServicePoint 设置它，你可以通过以下方式获取它：

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/

于 2017-09-14T08:19:02.447 回答