全面提升 Web 2.0 应用程序的性能，第 1 部分: Web 2.0 应用的性能分析概述和新的挑战

简介

通常，当我们谈论一个互联网应用的性能的时候，我们总是会关注服务器系统的吞吐量（Throughput）、响应时间（Response Time）、单位时间的事务量（Transactions per seconde）、CPU 使用率、磁盘 I/0、内存使用等等服务器性能参数，测量这些服务器性能参数并对其进行分析是软件性能工程的主要工作。但是当基于 Web 2.0 技术互联网应用兴起的时候，游戏规则却已悄然发生了变化。一个典型的现象是，在实际的应用环境中，终端用户感到这个应用的响应很慢，但是在系统服务器端却观察不到任何一个资源瓶颈。而以服务器为中心的性能测量结果也证实这个互联网应用的吞吐量和响应时间都很好，而且在开发环境中也没有检测到类似的响应慢问题。这种现象在 Web 2.0 之前不是没有，但在 Web 2.0 架构的应用却越来越普遍。这说明以服务器为中心的性能工程可能是有盲点的，它可能已经不能全面分析、解决在 Web 2.0 架构上的性能问题。针对 Web 2.0 架构的性能工程，我们需要找到这个盲点，并用新的理论、方法和工具来填补这个盲点。

面向服务器的性能工程的盲点

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

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

以服务器为中心的性能工程是一个复杂的系统工程。它有着成熟的理论、方法和工具，也取得了巨大的成功。有关这些，本文就不一一赘述。去繁就简，其基本方法就是：

• 记录一个典型终端用户浏览器和应用服务器的交互，也就是浏览器和应用服务器之间的 HTTP 请求。
• 用性能测量软件将这些 HTTP 请求编制成脚本。典型的测量软件有 IBM 的 Rational Performance Tester。
• 在工作负荷生成服务器上，性能测量软件将模拟成千上万的用户来运行这些脚本，即发送 HTTP 请求并接受响应。
• 性能测量软件将记录，计算用户请求的响应时间，服务器的吞吐量及其它性能数据。

这套方法有盲点吗？有。用这套方法所观察到的响应时间和真实的终端用户的观察到的响应时间比，至少有两个盲点：

• 缺少浏览器渲染时间。终端用户的浏览器会渲染（包括解释，执行和呈现）HTTP 响应的内容。而性能测量软件却不能。
• 缺少复杂网络条件下，网络传输对响应时间的影响。真实用户很可能会从各种各样不同网络环境（比如网吧）访问一个互联网应用，而基于现实的原因，性能测量软件往往是在实验室中访问实验室中的互联网应用。

然而，这两个盲点也被忽略很多年了，服务器中心的性能工程已经成功很多年了。那么在 Web 2.0 架构下，它还能继续被忽略吗？

新的挑战与无法忽略的盲点

Web 2.0 架构到底给性能工程带来了什么样的挑战？在回答这个问题前，让我们比较一下 Web 2.0 架构和传统互联网应用的的区别。这个图对比了传统互联网应用（WebSphere Portal）的三层体系架构和 Web 2.0 应用（Lotus Mashups）的三层体系架构：

图 1. 传统互联网应用（WebSphere Portal）的三层体系架构和 Web 2.0 应用（Lotus Mashups）的三层体系架构
 

它们之间的区别是明显的：

• WebSphere Portal：业务逻辑层的实现在服务器端。
• Lotus Mashups：业务逻辑层的实现可以在浏览器端。
• WebSphere Portal：绝大部分的表现层在服务器端。
• Lotus Mashups：绝大部分的表现层在浏览器端。
• WebSphere Portal：服务器端的 Portlets 内容聚合。服务器端把 Portlets 的内容聚合成 Html, 浏览器端负责 HTML 页面内容渲染和有限的 JavaScript 实现用户交互。
• Lotus Mashups: 浏览器端的 Widgets 内容聚合。浏览器端把 Widgets 的内容插入 HTML DOM, 浏览器端完全负责 HTML 的生成和页面内容渲染，大量的 JavaScript 在浏览器上运行。

由此可见，Web 2.0 的应用给性能工程带来了两大挑战，而这两大挑战恰恰是在传统互联网应用中可以被忽略的性能盲点。在 Web 2.0 应用中它们不能再被忽略：

• 盲点 1：浏览器渲染时间

  在传统的互联网应用架构中，绝大多数的工作是在服务器端完成的。所有的业务逻辑是服务器端完成的，并且服务器端生成了完整的 HTML 页面，浏览器只要呈现就可以了。 而在 Web2.0 架构中，很多工作被移到了浏览器端，浏览器用 Javascript 直接操作 DOM 来生成 HTML。而且部分义务逻辑也可以在浏览器端完成。同时，随着异步 HTTP 请求的大量使用，HTTP 请求的发起时间由 JavaScript 逻辑控制。这使得 HTTP 请求的并发度下降，而影响到页面下载的完成时间。这些都使得很多的响应时间消耗在浏览器端。所以浏览器渲染时间不能被忽略。

• 盲点 2：网路传输时间

  在传统的互联网应用架构中，逻辑是有 Java 或其他语言在服务器的执行的。这些代码不也就驻留在服务器端而不需要被传输。而在 Web 2.0 架构下，这些代码是很有可能用 Javascript 实现并在 Browser 端执行的。这必然涉及到 Javascript 及其他相关联资源在互联网上的传输。这使 Web 2.0 架构可能会牵涉多的多的 HTTP 请求。而这可能或大大的增加网络传输时间，细节容后再述。

 

总结：照亮盲点

由上所述，这两大盲点在 Web 2.0 应用中不能被忽略。我们需要新的方法与工具来覆盖特别是客户端的性能 -- 浏览器响应时间。 通常，我们可以理解浏览器响应时间的计算公式：

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

在传统的互联网应用中，由于浏览器端的时间消耗比较有限，并且页面装载时间也比较简单且有限。所以在对传统互联网应用的响应时间分析中，我们通常忽略页面装载时间和浏览器渲染时间，而着重分析服务器响应时间。 而在 Web 2.0 应用中，页面装载时间和浏览器渲染时间将成为决定性能的关键因素。所以在接下来的系列文章中，我们将以 IBM Mashup Center 的产品作为实例，分别介绍有关页面装载时间与浏览器渲染时间的性能测试和分析方法，并在最后一篇文章列出了一些通用的解决方案。

参考资料

学习

• 查看 “全面提升 Web 2.0 应用程序的性能” 系列文章的所有部分：
  • 第 1 部分：Web 2.0 应用的性能分析概述和新的挑战
  • 第 2 部分：页面下载时间分析
  • 第 3 部分：浏览器渲染时间分析
  
  
• “提高基于 Dojo 的 Web 2.0 应用程序的性能”（developerWorks，2008 年 2 月）：本文通过演示一些实用的技巧来提高 Dojo 的性能，帮助开发人员找出 Web 2.0 应用程序的性能瓶颈。