将networking延迟从500毫秒减less到60-100毫秒的策略

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

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

• 使用PHP脚本执行linux shell命令并在浏览器中显示？
• Web浏览器拒绝呈现PHP代码
• 为什么这个networkingMIDI API代码没有检测到MIDI事件？
• Perl脚本在linuxterminal中运行，但在浏览器中出现错误
• x-www-browser的兼容性

但正如你所看到的，这些Nginx日志几乎总是0.001毫秒 （ 请求时间是最后一列 ）。 这不是一个值得关注的问题。

所以很明显，我在服务器和客户端之间失去了时间 。 我的基准是Google即时响应时间 。 这通常在30-40毫秒的范围内。 幅度较低 。

虽然很容易说谷歌拥有庞大的基础设施能力，但是我想让自己学习一下，如果不是这个水平的人，这是可能的。 如果不是60毫秒，我想削减100-150毫秒。

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

1. 启用httpd slowstart和initcwnd
2. 如果您使用的是https，请确保SPDY
3. 确保结果是http压缩的
4. 等等。

在这里我还能做些什么呢？

例如

• 有一个持久的连接帮助？
• 我是否应该大幅缩小响应大小？

编辑：这里是ping和traceroute数字。 该网站是通过从弗里蒙特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 

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