全面提升 Web 2.0 应用程序的性能，第 2 部分: 页面下载时间分析

选自dW

什么是终端用户响应时间？

正如在本系列文章 第 1 部分 中描述的那样，终端用户响应时间就是指从这个用户触发一个页面请求到这个页面被完全展示的时间，有时也被称为浏览器响应时间。终端用户响应时间是终端用户对一个应用性能的直观感受。它由三部分组成：

• 页面请求与下载时间（简称页面下载时间）。
• 服务器响应时间。
• 浏览器处理及渲染时间。

用一个公式来表示，那就是 :

终端用户响应时间= 页面下载时间+ 服务器响应时间+ 浏览器处理及渲染时间

页面请求与下载时间就是被忽略的第二个盲点。即缺少复杂网络条件下，网络传输对响应时间的影响。真实用户很可能会从各种各样不同网络环境（比如网吧）访问一个互联网应用，而基于现实的原因，性能测量软件往往是在实验室中访问实验室中的互联网应用。

在现实的生产环境中，有各种各样的网络环境。性能工程需要尽可能的模拟现实的生产环境，但也要在可接受的成本下进行，覆盖所有网络环境的测量方法不是现实可行的。然而如果能够对页面下载的时间、Web 2.0 应用的网络传输行为、以及网络参数的关系建模，那么就有可能通过实验室的性能数据来预测在真实网路环境的响应时间。

 

页面下载时间的模型

简化的浏览器响应时间的计算模型

浏览器响应时间 = 服务器响应时间 + 页面装载时间 + 页面渲染时间

页面装载时间 = 页面尺寸 / 网络带宽 + （网络延迟 × HTTP 请求数）/ 并发度

页面下载时间的模型涉及三方面：

• 互联网应用的网络传输行为 : 它包括这个互联网应用通过浏览器发出了多少个 HTTP 请求，页面大小（HTTP 响应的总和），同时有多少个 HTTP 连接，这个互联网应用是如何并发使用这些 HTTP 连接的，等等。
• 网络参数 : 网络参数一般可以用 QoS (Quality of Service) 来描述，Qos 包括带宽、延迟、丢包率等等一系列参数。但简化的说，带宽和网络延迟是最主要的因素。
• 页面下载时间 : 终端用户响应时间就是指从这个用户触发一个页面请求到这个页面被完全展示时，有多少时间是花费在网络传输上。

网络带宽和页面大小的关系

在这些关系中页面大小和带宽的关系是最简单明了的，网络带宽决定了网路内每秒钟能传输的数据量的大小。同样大小的文件，在低带宽网络环境下的传输时间将大于高带宽的网络环境。所以：

消耗在带宽上的时间 = 页面大小 / 网络带宽

例如：在 512Kbps 的 ADSL 线路上下载 1Mbyte 的页面， 消耗在带宽上的时间 = 1Mbyte / 512Kbps = 1024 * 1024 * 8 bit / 512 * 1024 bps = 16 秒。

注：这里的页面尺寸比页面文件的总和要略大，这是因为整个 HTTP 协议栈（HTTP、TCP、IP）有报头数据。

HTTP 请求数和网路延迟的关系：

HTTP 请求数和网路延迟的关系就不是这么明了的了。我们先举个例子：有一家在上海的公司要从北京运 100 个标准集装箱货柜，那需要多少时间把所有的货柜运会到上海呢？

• 首先，要运回这 100 个货柜，就需要从上海到北京来回跑 100 车次。
• 其次，从上海到北京是要相当的时间的，这主要和空间距离，汽车的速度有关，加油休息的时间有关。
• 最后，如果只有一部运输车的话，这辆车就需要跑 100 个车次。假设跑一个来回需要 2 天的话，那么运 100 个货柜就需要 200 天。如果有两部车的话就可以一起运，那就只要 100 天，四部车就只要 50 天了。

HTTP 请求数和网路延迟的关系和上述例子是一样的：

• 首先，如果这个互联网应用发出了 100 个 HTTP 请求，这就相当于这个例子中要跑 100 个车次。
• 其次，网络是有延迟的。这就相当于上述例子中北京上海一个来回的时间。它也和速度、空间距离有关。速度可以假设是光速。光速听上去很快了，但在中国美国之间来个来回也要 0.13 秒。当然在网络上网关的开销也是相当可观的，这就类似于上述例子中司机要休息，车要加油一样。网络延迟是有个简单的操作系统命令来测量的。这个命令就是 ping， 平均 ping 值可以被简单的认为就是网络延迟。
• 最后，HTTP 请求数也有“几部车”的概念吗？有的，这就是浏览器支持的最大 HTTP 连接数。现在的浏览器基本上都支持 2 个以上的 HTTP 连接数。那是不是说一个在中国的终端用户访问一个在美国的互联网应用，共发了 100 个 HTTP 请求，浏览器支持两个 HTTP 连接，那他只需要花费 0.13 × （100 / 2）= 6.5 秒在网络延迟上呢？事情没有这么简单。这就是牵涉到互联网应用的并发度和 HTTP 连接数的关系。

互联网应用的并发度和 HTTP 连接数的关系：

互联网应用和上述例子的不同之处在于， 在例子中，是确定知道有 100 个货柜要运。所以两部车可以充分并发使用。而在互联网应用中，在一开始是不知道到底有几个货柜要运，这个信息是在运输过程中逐步清楚的。一个更准确的例子是：

• 在上海的这家公司知道在北京有个货柜要运，就派了一部车去。（两部车只用了一部，没有并发）
• 这部车回来后，还带回一个消息，在北京还有一个货柜要运。就继续派了一部车。（两部车只用了一部，没有并发）
• 这部车回来后，带回的消息是在北京还有 2 个货柜要运，于是就派了两部车去。（两部车都用上了，有并发了）
• 等这两部车回来后，带回的消息是在北京还有 1 个货柜要运，那就继续派了一部车。（两部车只用了一部，没有并发）
• 如此往复，直到回来的车说没有更多的货柜了为止。到这个时候，假设总共有 100 车次，两部车一起跑了 30 次，单独跑了 40 次。还是一个车次 2 天，那么总共用了 30 × 2 + 40 × 2 = 140 天。如果没有并发，那么就需要 100 × 2 = 200 天。那么我们可以设定并发度 = 200 / 140 = 1.43
• 如果是完全相同的情况，但只是把目的地从北京搬到了哈尔滨，一个来回需要 4 天。那么应用并发度，我们可以很容易算出运送所有货柜需要 （总车次 × 单次来回时间 / 并发度） = 100 × 4 / 1.43 = 280 天。

互联网应用的并发度和 HTTP 连接数的关系是和这个例子是类似的：

• 当一个 HTTP 请求返回时，浏览器分析出还要下载若干图片、CSS 和 JavaScript 文件。在这种情况下浏览器可以并发的下载这些文件。
• 但当一个 JavaScript A.js 下载下来后，A.js 引用了 B.js，B.js 下载下来后发现它引用了 C.js。在这种情况下，浏览器就不能串行下载了。而在 Web 2.0 的应用中，这种情况相当普遍。

从以上分析可知， 网络延迟、HTTP 请求数、并发度和消耗的总延迟时间的关系是：

总延迟时间 = 网络延迟 × HTTP 请求数 / 并发度

而页面下载时间的简化模型就是 :

页面下载时间 = 在带宽上消耗的时间 + 在网络延迟上消耗的时间 = 页面尺寸 / 网络带宽 + （网络延迟 × HTTP 请求数）/ 并发度

在这个简化模型中，有些因子没有被考虑 :

• DNS 查询时间；
• HTTP 请求建立时间；
• HTTP 连接的连接保持状态；
• 浏览器，服务器在处理传输时消耗的时间，等等；
• 带宽对并发度的影响。

基于这个模型，我们只要测量出页面的尺寸、HTTP 请求数和并发度就可以推测在不同网络条件下的页面下载时间。

互联网应用网络传输行为的测量与终端用户响应时间：

如前所述：

终端用户响应时间= 页面下载时间+ 服务器响应时间+ 浏览器处理及渲染时间

互联网应用网络传输行为主要包含一下几方面：

• 页面尺寸
• HTTP 请求数
• 并发度

可以想象，如果我们能够监听网络传输就可以得知页面尺寸和 HTTP 请求数，而并发度则要通过一些分析也可以得到。而且事实上我们也可以通过互联网应用网络传输行为，分析出服务器响应时间和浏览器渲染时间。而 :

终端用户响应时间 = 页面下载时间 + 服务器响应时间 + 浏览器处理及渲染时间 = 页面尺寸 / 网络带宽 + （网络延迟 × HTTP 请求数）/ 并发度 + 服务器响应时间 + 浏览器处理及渲染时间

所以如果我们可以通过监听互联网应用的网络传输行为得到页面尺寸、HTTP 请求数、并发度、服务器响应时间和浏览器处理及渲染时间，那么我们就可以推测这个应用在任意网络环境下的终端用户响应时间。

网络监听工具有很多，比如 WireShark 。但 WireShark 比较底层，它可以捕捉整个协议栈的信息。但它的用户界面不是很友好，不利于本文的解释与描述。所以本文以 IBM PageDetailer Pro 为工具，以 Lotus Mashups 的首页为例来说明如何测量互联网应用网络传输行为以及如何理解。

 

用 Page Detailer Pro 进行测量

Page Detailer Pro 是 IBM alphaworks 提供的一个工具。它是一款用来记录浏览器 HTTP 请求的软件，它通过在客户端的 Windows 端口堆栈中插入探针（Probe）来获取记录浏览器发起的 HTTP 请求的各种类型的数据。 对于 Page Detailer 的具体使用，可以查看参考资源。

下面是我们的测量步骤 :

• Lotus Mashups 服务器和承担测量的台式机共存于同一个局域网。局域网的带宽是 100 Mbps，网络延迟小于 1 毫秒。
• 启动 Firefox 3.0，清除浏览器缓存。
• 启动 Page Detailer Pro。
• 我们使用 Firefox 3.0 对 IBM Mashups Center 的首页进行访问，Page Detailer 工具会监测并记录这些请求。
• 重复这个动作，使 Page Detailer 得到 5 条对于首页的访问记录。这是为了得到一个平均值。

将得到的记录保存作为下一步分析使用。

理解 Page Detailer Pro 的测量结果

图 1. 示例：Page Detailer Pro 的记录
 

图 1 是一个 Page Detailer 记录的截图。浅蓝色标注部分是后加的，由上图示可知：

1. 页面尺寸。这儿的页面尺寸只包含资源本身的尺寸，不包含 HTTP 头及其他协议栈的头尺寸。当然，PageDetailer 也提供总下载尺寸的数据。
2. HTTP 请求数。
3. 单个资源下载时间。这整个条形代表单个资源下载的总时间，包含建立网络连接的时间，发送 HTTP 请求的时间，接收 HTTP 响应的时间，网路传输整个资源的时间。
4. 浏览器发出请求头到接收到响应头的时间。PageDetailer 只提供这个时间，但事实上网络监听工具可以提供记录更细粒度的时间。比如：HTTP 请求的发送时间，等待服务器响应的时间，接受 HTTP 响应头的时间。由于在局域网里，接受发送头的时间极短，所以这个时间可以认为就是服务器的响应时间。在这个图示中，把所有蓝色条形代表的时间相加就是服务器消耗的时间，去除重叠部分后才是服务器响应时间。注意，服务器消耗的时间不等于服务器响应的时间，这里也有一个并发度的问题。
5. 网络传输时间。只是有关浏览器从开始接收这个资源的内容到接受结束所化的时间。一般的来说，它就是资源尺寸 / 带宽。但如果服务器或浏览器是以流的方式处理这个资源的话，那它还包含浏览器或服务器的处理时间。
6. 浏览器渲染时间。在任意两个资源下载中的间隔时间就是浏览器的渲染时间。注意：即使是在资源下载是，浏览器也可能在进行渲染。不过这些消耗，无法用间隔时间的方法判断。一般的来说，这部分时间是比较有限的并且倾向于忽略。
7. 资源下载之间没有重叠，这说明这些下载之间没有并发。
8. 资源下载之间有重叠，这说明这些下载之间有并发。

那么并发度怎么计算？一个简化的方法就是：

并发度 = 单个资源下载时间之和 / （页面下载时间 – 浏览器渲染时间）

简化的前提是：

• 在局域网内，网络延迟很低。
• 服务器响应很快。
• 服务器端，浏览器端没有流式处理，或很快

当然，在这里只是介绍了一下计算并发度的原理。基于这个原理，可以编写相应的程序读取 PageDetailer 或其他网络监听程序 （比如 WireShark） 的数据来自动计算并发度。在 Lotus Mashups 的性能工程中，我们应用了一个小工具来自动化地计算并发度、浏览器渲染时间和服务器响应时间。具体的开发细节以及在这个例子中的数值就不再一一赘述了。

计算不同网络环境下的终端用户响应时间

接下来，我们可以通过简单的数学计算来推测在不同网络条件下的终端用户响应时间。如图 2：

图 2. 不同网络条件下的 Mashups 初始页面的终端用户响应时间
 

 

如何降低页面下载时间

由前面分析可知，可以通过以下几个方面来降低页面下载时间：

1. 减少 HTTP 请求数来降低在网络延迟上的消耗。方法有：
   • 尽可能的缓存 HTTP 请求。这样至少可以降低后续的访问的页面下载时间。
   • 将多个文件捆绑整合。如 Dojo Shrinksafe 可将多个 Javascript 文件整合成一个。CSS Sprite 可将多个图片整合成一个。
   • 当然通过设计 / 代码重整的方法来减少互联网应用的 HTTP 请求数总是有效的。
2. 减少页面尺寸来降低在网络带宽上的消耗。方法有：
   • 尽可能的缓存 HTTP 请求。这样至少可以降低后续的访问的页面下载时间。
   • 启动 HTTP 压缩。主流浏览器都支持 gzip enconding。通过在服务器端启动 HTTP 压缩，大致可以减少 60% 以上的文本尺寸。
   • 当然通过设计 / 代码重整的方法来减少互联网应用的页面尺寸也总是有效的。
3. 提高并发率。方法有 :
   • 预读。如 a.js 将引用 b.js，b.js 将引用 c.js。在正常情况下，这是个串行的过程。但如果在引用 a.js 时就引用 b.js 和 c.js 就可以很好的提高并发度。并降低在网络延迟上的消耗。

 

总结

本文中，我们介绍了影响终端用户响应时间的其中一个主要因素是”页面请求与下载时间“，并且阐述了页面下载时间的构成，以及页面下载时间的在不同网络环境下的响应时间计算模型。通过对 IBM Mashups Center 首页的页面下载分析与模型计算，我们得到了其在不同网络环境下的计算值。最后我们讨论了如何能降低页面下载时间。通过对页面下载时间的分析与模型解析，从而提早发现应用在不同网络环境下可能存在的性能问题。