终端用户响应时间是指用户触发页面请求到页面完全展示的时间，由页面下载时间、服务器响应时间和浏览器处理及渲染时间组成。通过减少HTTP请求数、页面尺寸及提高并发度可以有效降低页面下载时间。
正如在本系列文章 第 1 部分 中描述的那样，终端用户响应时间就是指从这个用户触发一个页面请求到这个页面被完全展示的时间，有时也被称为浏览器响应时间。终端用户响应时间是终端用户 对一个应用性能的直观感受。它由三部分组成：
- 页面请求与下载时间（简称页面下载时间）。
- 服务器响应时间。
- 浏览器处理及渲染时间。
用一个公式来表示，那就是 :
终端用户响应时间 = 页面下载时间 + 服务器响应时间 + 浏览器处理及渲染时间
页面请求与下载时间就是被忽略的第二个盲点。即缺少复杂网络条件下，网络传输对响应时间的影响。真实用户很可能会从各种各样不同网络环境（比 如网吧）访问一个互联网应用，而基于现实的原因，性能测量软件往往是在实验室中访问实验室中的互联网应用。
在现实的生产环境中，有各种各样的网络环境。性能工程需要尽可能的模拟现实的生产环境，但也要在可接受的成本下进行，覆盖所有网络环境的测量 方法不是现实可行的。然而如果能够对页面下载的时间、Web 2.0 应用的网络传输行为、以及网络参数的关系建模，那么就有可能通过实验室的性能数据来预测在真实网路环境的响应时间。
页面下载时间的模型涉及三方面：
- 互联网应用的网络传输行为 : 它包括这个互联网应用通过浏览器发出了多少个 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 请求数和网路延迟的关系就不是这么明了的了。我们先举个例子：有一家在上海的公司要从北京运 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 连接数的关系。
互联网应用和上述例子的不同之处在于， 在例子中，是确定知道有 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 的首页为例来说明如何测量互联网应用网络传输行为以及如何理解。
由前面分析可知，可以通过以下几个方面来降低页面下载时间：
- 减少 HTTP 请求数来降低在网络延迟上的消耗。方法有：
- 尽可能的缓存 HTTP 请求。这样至少可以降低后续的访问的页面下载时间。
- 将多个文件捆绑整合。如 Dojo Shrinksafe 可将多个 Javascript 文件整合成一个。CSS Sprite 可将多个图片整合成一个。
- 当然通过设计 / 代码重整的方法来减少互联网应用的 HTTP 请求数总是有效的。
- 减少页面尺寸来降低在网络带宽上的消耗。方法有：
- 尽可能的缓存 HTTP 请求。这样至少可以降低后续的访问的页面下载时间。
- 启动 HTTP 压缩。主流浏览器都支持 gzip enconding。通过在服务器端启动 HTTP 压缩，大致可以减少 60% 以上的文本尺寸。
- 当然通过设计 / 代码重整的方法来减少互联网应用的页面尺寸也总是有效的。
- 提高并发率。方法有 :
- 预读。如 a.js 将引用 b.js，b.js 将引用 c.js。在正常情况下，这是个串行的过程。但如果在引用 a.js 时就引用 b.js 和 c.js 就可以很好的提高并发度。并降低在网络延迟上的消耗。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
