Page 169 - Web性能权威指南

要让互联网从整体上提速，就必须寻求降低 RTT 的方法。把跨大西洋的
RTT 从 150 ms 降低到 100 ms，结果会怎么样？结果比把用户带宽从 3.9
Mbit/s 提高到 10 Mbit/s 甚至 1 Gbit/s 对速度的影响都大。
减少页面加载时间的另一种方法，就是减少加载每个页面过程中的往返次数。
今天，加载每个页面都需要客户端到服务器之间的数次往返。这些往返很大
程度上是由客户端与服务器之间为建立连接（DNS、TCP、HTTP 等）而进
行握手所导致的，当然有的是由通信协议引发的（如 TCP 慢启动）。假如我
们能够对协议加以改进，使得加载同样多的数据只需更少的往返，那应该也
能够减少页面加载时间。这就是 SPDY 的目标之一。
——Mike Belshe，更多带宽其实不（太）重要
很多人可能都会惊讶于这两项试验的结果，而实际情况的确如此，这正是 TCP 握手
机制、流量和拥塞控制、由丢包导致的队首拥塞等底层协议特点影响性能的直接后
果。大多数 HTTP 数据流都是小型突发性数据流，而 TCP 则是为持久连接和大块数
据传输而进行过优化的。网络往返时间在大多数情况下都是 TCP 吞吐量和性能的限
制因素，详细信息可参见 2.5 节“针对 TCP 的优化建议”。于是，延迟自然也就成
了 HTTP 及大多数基于 HTTP 交付的应用的性能瓶颈。

如果延迟对大多数有线连接是限制性能的因素，那可想而知，它对无线客
户端将是更重要的性能瓶颈。事实上，无线延迟明显更高，因此网络优化
是提升移动 Web 应用性能的关键。

10.4 人造和真实用户性能度量

有度量，才有改进。问题在于度量的标准是否正确，过程是否合理。如前所述，度
量现代 Web 应用的性能并不容易，没有什么指标放之四海皆准。换句话说，我们必
须定义自己的指标。确定了度量标准之后，接下来要收集性能数据，这个过程涉及
一系列人造和真实用户的性能度量。

宽泛地说，在受控度量环境下完成的任何测试都可称为人造测试。首先，本地构建
过程运行性能套件，针对基础设施加载测试，或者针对一组分散在各地的监控服务
器加载测试，这些服务器定时运行脚本并记录输出。这些测试中的任何一个都可能
测试不同的基础设施（如应用服务器的吞吐量、数据库性能、DNS 时间，等等），
并作为稳定的基准辅助检测性能衰退或聚焦于系统的某个特定组件。

只要配置得当，人造测试就可以提供一个受控且可重现的性能测试环境。
而这个环境非常适合发现和修复性能问题，确保用户体验。提示：确定一
个关键的性能指标，并为它们分别设定一个“预算额度”，纳入人造测试计
划。一旦哪个指标超出“预算”，马上拉响警报！

154 ｜ 第 10 章