全面提升Web应用程序的性能.docVIP

全面提升 Web 2.0 应用程序的性能，第 1 部分: Web 2.0 应用的性能分析概述和新的挑战 游戏规则已然改变 -- 从瘦浏览器应用到富浏览器应用 简介：?Web 2.0 技术的兴起，促使我们对互联网应用性能的衡量提出了新的要求，我们必须更加关注客户端性能。在这个分为四个部分的系列文章里，我们将结合 IBM Mashups Center 1.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 的应用给性能工程带来了两大挑战，而这两大挑战恰恰是在传统互联网应用中可以被忽略的性能盲点。在