Question

我正在构建自动填充功能，并意识到客户端和服务器之间的时间过长（在450-700ms范围内）

autocomplete response time

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

enter image description here

但是你可以看到这些Nginx logs are almost always 0.001 milliseconds（请求时间是最后一列）。这几乎不是引起关注的原因。

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

enter image description here

虽然很容易说谷歌拥有以这种速度提供的巨大基础设施能力，但我想让自己去了解一下这个水平的人是否可能。如果不是60毫秒，我想减少100-150毫秒。

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

Enable httpd slowstart and initcwnd
如果您使用https
确保结果为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

Answer 1

我可能错了，但我个人闻到了老鼠的味道。您的设置不符合您的时间;我相信你的请求应该运行得更快。

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

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

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

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

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

Answer 2

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

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

参见＆＃34; HTTPS服务器优化＆＃34;这里： http://nginx.org/en/docs/http/configuring_https_servers.html

Answer 3

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

Answer 4

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

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

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

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

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

4 个答案: