将网络延迟从 500 毫秒减少到 60-100 毫秒的策略答案

【问题标题】：Strategies in reducing network delay from 500 milliseconds to 60-100 milliseconds将网络延迟从 500 毫秒减少到 60-100 毫秒的策略
【发布时间】：2014-05-31 18:11:20
【问题描述】：

我正在构建一个自动完成功能并意识到 客户端和服务器之间花费的时间太长（在 450-700 毫秒的范围内）

我的第一站是检查这是否是服务器延迟的结果。

但是正如您所看到的这些Nginx logs are almost always 0.001 milliseconds（请求时间是最后一列）。这几乎不是令人担忧的原因。

所以很明显我在服务器和客户端之间浪费了时间。我的基准是Google Instant's response times。这几乎通常在 30-40 毫秒的范围内。 幅度降低。

尽管说 Google 拥有以这种速度交付的庞大基础设施能力很容易，但我想推动自己了解这对于不具备这种水平的人来说是否可行。如果不是 60 毫秒，我想减少 100-150 毫秒。

以下是我设法学习的一些策略。

Enable httpd slowstart and initcwnd
如果您在 https 上，请确保 SPDY
确保结果是 http 压缩的
等

我还能在这里做什么？

例如

持久连接有帮助吗？
我应该显着减小响应大小吗？

编辑： 这是 ping 和 traceroute 编号。该站点通过来自 Fremont Linode 机器的 cloudflare 提供服务。

    mymachine-Mac:c name$ ping site.com
    PING site.com (160.158.244.92): 56 data bytes
    64 bytes from 160.158.244.92: icmp_seq=0 ttl=58 time=95.557 ms
    64 bytes from 160.158.244.92: icmp_seq=1 ttl=58 time=103.569 ms
    64 bytes from 160.158.244.92: icmp_seq=2 ttl=58 time=95.679 ms
    ^C  
    --- site.com ping statistics --- 
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 95.557/98.268/103.569/3.748 ms
    mymachine-Mac:c name$ traceroute site.com
    traceroute: Warning: site.com has multiple addresses; using 160.158.244.92
    traceroute to site.com (160.158.244.92), 64 hops max, 52 byte packets
     1  192.168.1.1 (192.168.1.1)  2.393 ms  1.159 ms  1.042 ms
     2  172.16.70.1 (172.16.70.1)  22.796 ms  64.531 ms  26.093 ms
     3  abts-kk-static-ilp-241.11.181.122.airtel.in (122.181.11.241)  28.483 ms  21.450 ms  25.255 ms
     4  aes-static-005.99.22.125.airtel.in (125.22.99.5)  30.558 ms  30.448 ms  40.344 ms
     5  182.79.245.62 (182.79.245.62)  75.568 ms  101.446 ms  68.659 ms
     6  13335.sgw.equinix.com (202.79.197.132)  84.201 ms  65.092 ms  56.111 ms
     7  160.158.244.92 (160.158.244.92)  66.352 ms  69.912 ms  81.458 ms
    mymachine-Mac:c name$  site.com (160.158.244.92): 56 data bytes

【问题讨论】：

从您显示的客户端到服务器的 ping 时间是多少？跟踪路由中有多少跳？您是否在本地网络或单台机器上尝试过此操作（使用localhost？）如果您要在网络上进行边缘到边缘（其中一个边缘是您的客户端，另一个边缘是低成本网络中的机器托管场）您可能已经达到了延迟限制。
@OllieJones 我已经添加了 ping 和 traceroute 详细信息
啊哈，它是通过 cloudflare 提供的。您的 ping 时间是到最近的 cloudflare 服务器。因此，您的动态菜单查询从您的客户端传输到附近的 cloudflare 节点，然后通过 cloudflare - 到 - 客户中继到您的服务器。您在延迟中携带 cloudflare 延迟。如果您要理性地解决这个问题，您应该关闭 cloudflare 以消除查询组合中的延迟。如果您想通过它们提供这些查询，我怀疑您的未来将会有高级 cloudflare 订阅。（这是洲际的吗？如果是的话会很慢。）
我试过直接绕过 cloudflare 到机器上。差别不大。 @OllieJones
我可以有服务器 URL 来检查这里的时间和页面加载顺序吗？

标签： performance networking browser nginx

【解决方案1】：

我很可能是错的，但我个人闻到了老鼠的味道。您的设置无法证明您的时间是合理的；我相信您的请求应该运行得更快。

如果可能，请使用curl 生成一个简短的查询，并在客户端和服务器上使用tcpdump 拦截它。

这可能是主机上的带宽/并发问题。查看其诊断面板，或尝试估算流量。

您可以尝试将响应查询保存到静态文件中，然后请求该文件（注意不要触发本地浏览器缓存...），以查看问题是否可能是处理数据（服务器端或客户端）。

这种缓慢会影响每个请求，还是仅影响自动完成请求？如果是后者，无论 nginx 怎么说，在恢复或格式化输出的自动完成数据时可能会出现一些低效/延迟。

此外，您可以尝试完全绕过 nginx 提供静态响应，以防这是 nginx 的问题（就此而言：您检查过 nginx 的错误日志吗？）。

【讨论】：

【解决方案2】：

我没有看到您提到的一种方法是使用 SSL 会话：您可以将以下内容添加到您的 nginx conf 中，以确保每个连接请求都不会发生 SSL 握手（非常昂贵的过程）：

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

请参阅此处的“HTTPS 服务器优化”： http://nginx.org/en/docs/http/configuring_https_servers.html

【讨论】：

这都是通过http。
我明白了 - ping 时间呢？
我认为您日志中的$response_time 并不代表您认为的那样。请参阅此链接：lincolnloop.com/blog/tracking-application-response-time-nginx - 如上所述，$response_time 没有考虑上游服务器生成请求所需的时间。它还提供了一种解决方案，以便您可以测量真正的响应时间。

【解决方案3】：

如果您还没有，我建议您使用New Relic。您拥有的服务器端代码可能是问题所在。如果您认为这可能是问题所在，那么有很多免费的代码分析工具。

【讨论】：

【解决方案4】：

您可能需要考虑在呈现页面时在后台预加载自动完成选项的选项，然后将 trie 或您在客户端上使用的任何结构保存在本地存储中。当用户开始在自动完成字段中输入内容时，您无需向服务器发送任何请求，而是查询本地存储。

Web SQL 数据库和 IndexedDB 将数据库引入客户端。而不是通过将数据发布到服务器的常见模式 XMLHttpRequest 或表单提交，您可以利用这些客户端数据库。减少 HTTP 请求是所有目标的主要目标性能工程师，因此将它们用作数据存储可以节省许多通过 XHR 或表单返回服务器。本地存储和 sessionStorage 可以在某些情况下使用，例如捕获表单提交进度，并且已经看到明显快于客户端数据库 API。

例如，如果您有一个数据网格组件或一个收件箱数百条消息，将数据本地存储在数据库中将节省当用户希望搜索、过滤或排序时，您的 HTTP 往返。一个可以过滤每个朋友列表或文本输入自动完成击键，提供更灵敏的用户体验。

http://www.html5rocks.com/en/tutorials/speed/quick/#toc-databases

【讨论】：

在这种情况下在客户端预加载只是掩盖了服务器上的真正问题。