级别： 初级 孙 磊, 高级软件工程师, IBM
孙 静, 软件工程师, IBM
楼 亭, 高级软件工程师, IBM
涂 子琰, 高级软件工程师, IBM
王 肖青, 软件工程师, IBM
吴 中华, 高级软件工程师, IBM
2009 年 5 月 21 日
本书主要讲述如何构建高性能的 WebSphere 企业级应用系统，在阐述与性能相关的概念的基础上，重点介绍作者在开发、测试和维护 WebSphere 应用系统过程中为提高系统性能所进行的探索，以及在解决实际性能问题过程中所积累的经验。
全书由三部分组成，第一部分综述篇介绍构建高性能 WebSphere 企业级应用的基本原理和相关概念。第二部分技术篇以 WebSphere 企业级应用的整个生命周期为主线，从架构、设计、开发、测试等多个环节来介绍与性能相关的理论和经验。第三部分实践篇分专题通过实例讨论如何解决 WebSphere 企业级应用中几个常见的性能问题，以及由此总结出来的提高系统性能的方案。
在此我们推出了本书的 前言 和第 1、11 章供大家在线浏览。更多推荐书籍请访问 developerWorks 图书频道。
 | |
|
|
书名：构建高性能 WebSphere 企业级应用
作者：孙磊、孙静、楼亭、涂子琰 等编著
出版社：电子工业出版社
出版日期：2008 年 10 月
ISBN：ISBN 978-7-121-06317-6
购买：
中国互动出版网、当当网、卓越网
| |
推荐章节：
更多推荐书籍，请访问 developerWorks 图书频道。
欢迎您对本书提出宝贵的反馈意见。您可以通过本页面最下方的 建议 栏目为本文打分，并反馈您的建议和意见。
如果您对 developerWorks 图书频道有什么好的建议，欢迎您将建议发给我们。
|
|
|
1.1. WebSphere 企业级应用
经过多年的产品开发与市场推广，WebSphere 系列产品与技术日趋完善。开发 WebSphere 应用早已不是什么新鲜事。但对于什么应用可以称为企业级应用，并没有一个清晰的解释。很多软件都有企业版，但对于企业版与其他版本有何区别，许多人也并不了解。
1.1.1 WebSphere 应用
顾名思义，WebSphere 应用（WebSphere Application）是基于 WebSphere 开发的应用程序（Application）。
WebSphere 是国际商业机器有限公司（IBM）的五大软件品牌之一。WebSphere 提供一个集成软件平台。它包含编写、运行和监视随需应变的 Web 应用程序和跨平台解决方案所需要的整个中间件基础设施，如服务器、服务和工具。
WebSphere 应用服务器（WebSphere Application Server）是整个基础设施的基础，所有其他产品都在它之上运行。准确地说，WebSphere 应用是运行于 WebSphere 应用服务器之上的应用程序。
WebSphere 产品被称为中间件产品，是指 WebSphere 产品（尤其是 WebSphere 应用服务器）处于应用程序与操作系统之间。WebSphere 应用程序的逻辑结构如图 1-1 所示。
图 1-1. WebSphere 应用程序逻辑结构
从某种意义上说，中间件技术的出现是为了简化应用程序的开发。WebSphere 应用程序调用中间件产品提供的功能和服务而不是操作系统提供的接口实现高层的功能。因此，WebSphere 应用程序可以非常简单地实现跨平台和跨产品服务。
WebSphere 应用系统（WebSphere Application System）是指以 WebSphere 应用程序为核心的提供服务的完整系统。该系统一般包括硬件和软件，软件包括支持应用程序运行的各个组成部分：操作系统、WebSphere 应用服务器，以及其他支持软件（如数据库服务器、Web 服务器等）。如果没有特别声明，本书后面凡提到 WebSphere 应用的场合均指 WebSphere 应用系统。
1.1.2 企业级应用
许多软件产品都有企业版（Enterprise Edition）或商业版（Business Edition），以区别于专业版（Professional Edition）或标准版（Standard Edition）。不同的产品有不同的版本定位策略，各个版本之间的差别也没有一个统一的标准。但一般而言，企业版或商业版都是整个产品线中最高级别的版本。
本书题目中的企业级应用（Enterprise Application）也是指与一般的中小型或非商业应用相区别的应用，而不是泛指使用 Java 2 企业版（Java 2 Enterprise Edition）技术构建的应用。本书所特指的企业级应用，通常都为大中型企业维持生产运行提供服务。中断这些应用系统的正常运行，对整个企业的营业利润会造成巨大的影响，所以，对企业级应用的各方面都有严格的要求。比如安全性，企业级应用的数据通常都是企业的核心业务数据，对这些核心业务数据的非法访问可能为企业带来非常严重的损失。又比如数据准确性和完整性，对某些重要交易数据的错误处理可能带来包括法律诉讼在内的严重后果。此外，最常见、也是本书想强调的就是对性能的严格要求。
在澄清有关性能的具体概念之前，这里先对企业级应用的性能需求进行一些感性的描述。
首先，企业级应用往往需要承担很大规模的业务负载。以作者参与的某个电子商务应用系统为例，该系统有四百万用户定期访问，平均每小时要处理三百万次 Web 页面访问。比这更大的业务负载在企业级应用中也很常见。
其次，企业级应用的运行往往支撑着企业的核心业务，所以，要求应用程序能够提供 7 乘 24 小时的不间断服务。仍以上面提到的电子商务应用系统为例，该系统平均每小时会产生一万个订单（Order）。按照平均每个订单的交易金额为一百美元计算，平均每小时的交易金额为一百万美元。也就是说，该系统的正常运行每中断一小时，就可能带来一百万美元的经济损失。
再次，企业级应用对应用程序的处理速度（或运行效率）要求很高。前面提到的系统平均每小时要处理一万个订单，也就是说，系统需要在大约三分之一秒内处理完一个订单。这看起来似乎并不是很快。但如果考虑到系统同时还要应付每小时三百万次页面访问，商业应用中订单的业务逻辑又非常复杂，此外还要兼顾数据安全性、完整性的要求，三分之一秒内处理完一个订单已经对应用程序的处理速度提出了非常高的要求。
总之，在商品经济社会，一个企业花费巨额资金构建一个企业级应用，是为了带来更多的利润。如果这个企业级应用不能带来经济效益，那么，就没有必要构建它。所以，作者更愿意将企业级应用称为商业应用（Business Application）。企业级用户对应用程序运行的要求总是越快越稳定（或者说性能越高）越好。因此，高性能是一个应用能成为企业级应用的重要前提。
1.1.3 电子商务应用
本书是一本经验分享型的书，书中介绍的是作者在开发、测试和维护 WebSphere 企业级应用系统过程中的实践经验。为了使读者更容易理解书中提到的性能问题或系统结构，有必要介绍一下作者所参与的企业级应用系统的背景。作者所参与的主要是 IBM 提供的电子商务解决方案或应用系统，在本书中简称电子商务应用。
电子商务本身是一个比较宽泛的概念，本书中所提到的电子商务应用特指由 IBM 提供的在 WebSphere 平台上构建的电子商务（e-Commerce）解决方案。按照前两节的概念，作者参与的电子商务应用（e-Commerce Application）是一个构建于 WebSphere 平台上的企业级应用。该应用的客户都是企业客户，客户搭建该应用是为了构建网络或其他渠道上的交易平台。这些企业的最终用户可以通过该电子商务应用进行企业对客户（B2C）或企业对企业（B2B）的交易活动。如前所述，绝大部分企业客户对作者开发的电子商务应用的性能都有很高的要求，所部署的应用也通常要面对非常高的业务负载。企业客户投入很多资金购买和构建作者参与的电子商务应用，电子商务应用也给客户带来了可观的经济效益。比如，某大客户目前 70% 的营业收入是通过电子商务应用的业务渠道获得的。
本书后面绝大部分讨论都是以该应用为背景介绍的，本节就对该应用的大体结构及相关概念进行简单的介绍。
用一句话概括，作者参与的电子商务应用的功能设计是为企业用户提供企业对企业（B2B）或企业对客户（B2C）的电子商务解决方案。它提供一组紧密集成的软件模块，帮助企业客户实现快速的、高度自动化的跨渠道营销和销售流程。电子商务应用的功能如图 1-2 所示。
图 1-2. IBM 电子商务应用的功能
电子商务应用对最终用户（购买客户）提供的界面是丰富多彩的电子商店。购买客户可以通过各种渠道访问电子商店：可以是 Web 浏览器，也可以是各种智能终端设备，或者通过电话联系客户经理进行交易。
电子商务应用为企业业务人员提供各种各样的管理功能：审批订单、修改库存等。业务人员也可以通过多种渠道访问这些管理功能：可以是 Web 浏览器，也可以是基于 Eclipse 技术的富客户端工具。
电子商务应用支持多渠道（multi-channel）的访问方式，所以，作者在工作中遇到的性能问题也不局限于 Web 应用中的问题。不过，目前 Web 仍然是最主要的访问渠道，因此，本书中的讨论也以 Web 应用中的性能问题为主。
电子商务应用内部最核心的概念是商业模式（Business Model）和业务流程（Business Process）。B2B 和 B2C 就是完全不同的商业模式。电子商务应用内部的功能都围绕这些商业模式和业务流程展开。
电子商务应用可以独立地为客户提供服务，它也可以和客户的其他业务系统合作，为客户提供完整的解决方案：客户关系管理系统（CRM）、企业资源计划系统（ERP）等。电子商务应用可以通过包括 Web 服务在内的多种集成接口和这些业务系统进行集成。
电子商务应用内部划分为一些小的功能模块。如订单处理（Order Management）、产品目录和内容管理（Catalog and Content Management）等。
电子商务应用提供了相当丰富的预置（Out Of Box）功能，用户使用这些功能就可以搭建一个完整的网上商店。电子商务应用也提供了开发环境和二次开发接口，大客户的开发人员（或 IBM 的技术服务人员）可以在其基础上进行定制开发（Customization）。所以，作者遇到的性能问题有一些来自于电子商务应用的核心代码（产品开发），另外一些则来自于用户的定制开发代码（项目开发）。
在电子商务应用的开发和维护过程中遇到的性能问题涵盖的范围很广，但限于篇幅和作者的亲身经验，本书讨论的性能问题只是其中的一小部分。
1.2 性能问题
前一节介绍了什么是 WebSphere 企业级应用，以及性能对企业级应用的重要性。本节讨论什么是性能，通过介绍一些性能问题来界定讨论范围。实际上，对企业级应用系统性能的掌握是与各种各样的性能问题联系在一起的。这是一个遇到问题、解决问题、再遇到新问题的螺旋式上升的过程。所以，提高企业级应用系统的性能是一个经验性很强的工作。通过阅读和理解本书中介绍的各种性能问题，希望读者学会如何分析和解决这些问题。这样才能够在自己的实际工作中遇到类似问题时处理得得心应手，并且能够在设计和实现新的企业级应用系统时设法避免类似的问题。
1.2.1 一个虚构的场景
为了避免争议，此处以一个纯粹虚构的场景为例。
张三是一个钓鱼爱好者，同时又是一个很有商业头脑的青年。他在五年前就看好互联网上的商机，创办了一个以销售钓鱼器具为核心业务的网站。网站有钓鱼爱好者的论坛，也有出售钓鱼器具的网上商店。网站是张三和几个朋友创建的。构建之初主要考虑的是如何实现网站的各种功能，采用的技术也力求简单。网站在一个月内就投入运行了。刚开始的时候，网站的访问量很少。出现过一些功能上的问题，但依靠张三和朋友们的技术力量很快就解决了这些问题。
张三的网站经过了最初几年的艰难时期，终于存活了下来。网站的知名度也稳步提高。张三不失时机地对网站进行了改版，引入最新的页面展示技术：个性化页面，用户评价系统，动态广告，等等。网站的网页越来越吸引人。网站的访问量成倍地提升。每天的访问量从几百增加到几万。网上商店的业务量也从每天几个订单增加到每天几百个订单。辉煌的前景就在眼前。
可就在这时，问题出现了。越来越多的用户抱怨网页的响应时间变慢了，有时候需要等待十几秒一个网页才能显示出来。更加不能忍受的是订单交易的过程中经常出错。有的用户还反映在交易出错之后出现订单丢失的情况。与此同时，网站的管理员（张三的朋友）也发出了警告：在网站的访问高峰时期，网站服务器的 CPU 使用率达到了 100%。再这样下去，也许网站有一天会瘫痪的。
张三决定亲自体验一下问题的严重性。于是他在网站的访问高峰期访问了自己的网上商店。结果令人震惊：在等待 20 秒后才进入网站的首页，而单击第一个热销商品的时候就出现了如图 1-3 所示的错误。
图 1-3. 应用程序页面错误示例
张三决定立刻解决这些问题。可是张三和他的朋友们钻研了几天也找不到头绪。网上商店的客户已经开始流失了，张三觉得不能再拖下去了。他找到了一家专业开发 Web 应用系统的公司来重新构建整个网站。有了以前的教训，张三把性能指标写入了需求规格说明书。他要求新的网站能够满足如下要求：
系统高峰时期的页面平均响应时间不超过 2 秒
系统每天可以处理 1 000 个订单
系统可以满足在 5 年内每年业务量增加 50% 的负载需求
……
上面的场景是一个完全虚构的场景，但是，读者可以从这个场景中看到一些自己身边遇到的问题的影子。
1.2.2 性能问题的现象
各种应用要处理的业务不同，所面临的性能问题也会不同。本书主要讨论基于 WebSphere 构建的 Web 应用所面临的各种性能问题。下面就基于前一节举出的虚构场景，列举一些 Web 应用中常见的性能问题。在对各种性能指标进行定义之前，本节采取定性的非严格的描述方式。
1．交易出错
应用程序中的功能性问题也会导致在客户访问过程中出现错误。与功能性错误不同，性能问题导致的错误多数是由于并发访问造成的。也就是说，单个用户访问时没有错误，多个用户访问（或者说系统负载比较高）的时候才出现错误。
系统出错可能有两种类型。
一种是系统的某个部分发生致命错误而完全不能工作，比如数据库服务器崩溃（Crash）。这种情况下，所有需要经过该部分的交易都会出现错误，而且一段时间内无法恢复。这种错误是非常严重的错误，企业级应用中基本上不应该出现这样的错误。
系统中经常出现的是另一种错误，即某些特定交易（或操作）出现错误。这种错误往往与系统特定的运行状态相关，也就是说，同一时间内，有些用户的交易出现错误，另外的用户则没有错误。这种错误又可以分为两种类型。一种是可恢复的，比如某个用户在网上商店提交订单的时候出现错误，用户刷新页面或者再次提交这个订单的时候就有可能成功地完成交易。另一种则是不可恢复的，比如前一节虚构场景中提到的，某些用户在订单交易出错的时候出现订单丢失的情况。订单一旦丢失，往往不能再从系统中找回来（虽然理论上讲可能通过服务器端的某些特殊处理进行恢复）。这两种错误相比，不可恢复的错误是更严重的。
2．交易速度慢
与交易出错相比，交易速度慢的问题可能隐蔽一些。一些开发人员或维护人员可能认为只要应用系统把所有的交易处理都正确完成就可以了，处理速度慢一些没有太大关系。其实，从某种意义上讲，交易处理速度慢的问题更为严重。
从应用的服务器端或者从系统管理员的角度看，交易处理速度表现为单位时间内，系统处理的交易数目。对于最终用户而言，系统的处理速度表现为页面的响应时间。即使没有对响应时间的精确定义，大多数读者对于响应时间也有感性的认识。访问有些网站的时候，单击一个链接，马上就可以显示出页面；而访问另一些网站的时候，单击一个链接之后需要等上半天才能看到结果页面。
与交易出错（要么出错，要么不出错）相比，交易速度慢的问题更模糊一些。响应时间长到多少算是“慢”，并没有一个统一的定义。有些用户可能响应时间在 10 秒钟之内就可以接受，另一些用户可能对于 3 秒以上的响应时间就认为很慢了。这与用户的心理状态、处理交易的类型、其他类似应用的响应时间水平等许多因素有关。应用开发人员和测试人员需要根据各自应用的具体情况制定判定标准。
用户一旦认为交易（或页面）的响应时间“慢”，就有可能采取一些措施，比如反复刷新页面，重新提交操作，或者干脆放弃当前交易。应用系统的交易速度慢本来就可能是由系统负载重导致的，用户的这些行为有可能进一步加重系统的负载（用户即使放弃交易，该交易也可能还在服务器端继续运行），导致交易出错的产生。
此外，交易处理速度慢到一定程度，有可能超过系统各个环节的超时（TimeOut）设置，从而导致超时类错误的产生。
3．资源使用问题
与前面两种问题相比，资源使用问题更隐蔽，也更容易为开发或维护人员所忽略。
应用程序要正常运行，就必须使用各种各样的系统资源：CPU 是资源，内存是资源，磁盘 I/O 是资源，这些都是物理存在的资源。还有一些抽象的逻辑资源，比如数据库系统中常用的“锁”也是一种特殊的资源。在特定的应用系统中，任何资源都是有限的，对资源的竞争或滥用都可能导致问题。
资源使用问题可以分为两类。
一类是资源的过度使用，如果应用程序使用的系统资源过多，就可能导致应用程序与系统中运行的系统程序进行资源竞争，或者导致系统中同时运行的多个交易进程 / 线程之间竞争资源，从而导致系统运行出现问题。如前一节的虚构场景中描述的，系统运行的 CPU 占用率保持在 100%。这意味着应用程序对 CPU 资源的使用过多（或者说应用程序的运行效率不高），系统运行在这种状态下很快就会导致交易速度慢或交易出错的问题。
另一类资源使用问题是对资源的使用不足。最常见的现象是对 CPU 资源的使用不足。当系统中有多个 CPU 资源的时候，应用程序如果对多处理器运行的优化存在问题，就可能出现某个 CPU 很忙而其他 CPU 很闲的状态。严重的对资源的使用不足同样也会导致交易速度慢或交易出错的问题。
4．性能下降问题
前面列举的性能问题基本都是系统在某一个固定状态的问题，还有一类与时间有关的性能问题：性能下降（随时间下降）的问题，如图 1-4 所示。
这里衡量的时间尺度可长可短。对于一个比较长的时间尺度，系统面临的负载状况可能发生了很大变化（多数是负载增大）。多数系统很难保持与低负载情况下同样的性能表现。这实际是系统可扩展性的问题。
图 1-4. 性能随时间下降问题
本节讨论的主要是在一个较小的时间尺度内（即系统负载没有明显变化），系统性能发生明显下降的情况。由于下降趋势的存在，不论系统初始的性能有多好，在足够长的时间后，系统的性能也会下降到零。实际系统中这种下降的趋势可能相当缓慢，只有在系统性能下降到比较严重的时候问题才被发现。
不少开发人员对于系统性能下降的问题并不太重视，甚至有人会把定期重新启动整个系统推荐作为性能随时间下降问题的解决方案。对于企业级应用而言，这是不可接受的。如前所述，企业级应用系统中断运行很短时间都可能为企业带来巨大的经济损失。复杂的企业级应用重新启动一次往往需要很长的时间，所以，如果不是万不得已，企业级应用是不会随便重新启动的。
企业级应用中可能出现的性能问题还有很多，这里就不一一列举了。本书第三部分将通过实例详细介绍企业级应用中常见的性能问题的分析和解决方法。
1.2.3 性能问题的影响
前面已经提到过性能对于企业级应用的重要性。本节进一步详细分析性能问题对企业级应用的危害。这里仍以前一节列举的几种性能问题为例。
交易出错中的致命错误（服务器崩溃）和性能下降问题导致系统被迫重启，其后果都是企业应用在一段时间内不能正常工作。这种性能问题带来的经济损失是最直接的，按照前面介绍企业级应用时列举的例子，应用停止工作每一小时甚至每一分钟都可能带来巨大的直接损失。这类错误又往往发生在系统负载比较高（交易比较频繁）的时候，比如节日，系统停止工作带来的损失就更严重。
交易出错中的非致命错误及交易速度慢的问题带来的直接经济损失也许不那么明显，但是这类性能问题影响的是客户的交易体验，也就是客户满意度的问题。仍以电子商务应用为例，如果电子商店提供的商品很丰富，价格很实惠，客户也许会容忍在购物过程中偶尔出现一两次页面响应慢或出错的情况。但是，如果访问系统的每一个页面都很慢，或者每操作几个页面就会出错，那么，没有几个客户能够忍受。对于初次访问应用系统的新客户而言，一个流畅稳定的购物体验是非常重要的，一些看起来不那么严重的性能问题都可能损失掉潜在的客户。客户群的流失最终影响的仍然是企业的经济效益。所以，从长远来看，非致命错误和交易速度慢等性能问题的危害比几次系统停止工作的危害有过之而无不及。
资源使用问题带来的危害则是多方面的。有些资源使用问题可以通过添加系统资源（比如购买新的硬件）来解决，这会给企业带来直接的支出。有些问题则不能通过添加系统资源来解决（比如资源使用不足的问题），这类资源使用问题最终会转化为交易出错问题或交易速度慢的问题，带来相应的经济损失。
此外，性能问题通常都比较复杂，一旦出现就很不容易解决。也就是说，性能问题一旦出现就会持续一段时间，成为困扰企业用户和维护人员的噩梦。
总之，性能问题对企业级应用的危害很大，构建企业级应用时必须重视性能，尽量避免性能问题在生产环境中出现。
1.2.4 性能相关概念
本书中已经反复强调了性能的重要性，并列举了几种性能问题及其危害。但是本书还没有明确到底什么是性能。
性能（performance）的概念其实很广泛。系统运行的各个方面的好坏都可以被称为性能。本书讨论应用系统的性能，主要是和功能相区别的。
当开发人员制定一个企业级应用系统的需求规格说明书的时候，往往将需求分为两大类：功能性需求（Functional requirement）和非功能性需求（Non-functional requirement）。很大一部分非功能性需求都和性能相关。前面列举的虚构场景中提到的一些非功能性需求，如响应时间、交易处理速度等，都属于性能需求。本书将应用系统的性能笼统地界定为：保证应用系统高效、持久、稳定运行的各种能力。显然这不是一个严格的定义。读者可以通过本书讨论的性能指标、性能问题和相关活动来界定本书的讨论范围。
与性能相关的常见概念还有高可用性（High Availability）和可扩展性（Scalability）。
可用性（Availability）不同于易用性（Usability）。可用性强调的往往是容错性或从灾难中恢复的能力。高可用性技术往往涉及冗余技术（Redundancy）或备份切换（Backup and take over）技术。高可用性是性能领域的一个重要分支。它也是一个相对独立的分支。在某种程度上说，许多高可用性技术（比如冗余）是通过牺牲运算能力提供更好的容错性。本书内容将不涉及高可用性问题。
可扩展性是指系统性能能够随负载增加而增加的能力（趋势），如图 1-5 所示。
为了便于讲解，假定图中的负载指标是业务规模（并发用户数），性能指标是系统的吞吐率。后面（2.1 节）将详细介绍各种负载指标和性能指标。一般来说，可以通过增加硬件（CPU、内存等）来提高系统性能，适应负载的增加。但是明确负载增加与性能增加之间的关系很重要，否则，可能白白地增加硬件而达不到预期的性能效果。图中的两个系统相比，系统 1 的可扩展性优于系统 2（假定吞吐率为越高越好）。虽然系统 2 在小负载情况下优于系统 1，但是随着负载的增加，系统 1 的吞吐率将迅速超过系统 2。
图 1-5. 系统的可扩展性
仍以电子商务应用为例，假定要考察的负载指标是网上商店的产品目录中的产品数（数据库产品表的记录数），性能指标是产品浏览页面的响应时间（2.1 节会详细介绍这些指标的含义）。期望的关系曲线是一条线性关系曲线（直线）。也就是说，在相同硬件条件下，产品数量增加一倍，响应时间也增加一倍。反过来，产品数量增加一倍，要保持响应时间不变，可以通过增加一倍硬件资源来实现。线性关系曲线已经是比较理想的曲线，实际系统中二者的关系可能更差。也就是说，产品数量增加一倍，有可能需要增加几倍甚至更多的硬件资源来保持响应时间不变。此时，系统的可扩展性就需要改进。
本书的内容将涉及一些有关可扩展性的设计和问题分析。
1.3 构建高性能 WebSphere 应用
介绍了什么是企业级应用和性能对企业级应用的重要性之后，本节概要讲述如何构建一个高性能的 WebSphere 企业级应用。
1.3.1 WebSphere 应用性能影响因素
本书刻意强调的第一个观点是：WebSphere 应用系统由许多部件构成，是一个统一体，提高 WebSphere 应用的性能需要兼顾系统的各个部件，不能只着手于 WebSphere 应用程序本身。
常见 WebSphere 应用系统的概念结构如图 1-6 所示。
WebSphere 应用首先是一个 Java 程序，所以，应该遵从 Java 程序的高性能编程规范。
WebSphere 应用是构建在 WebSphere 应用服务器基础上的，所以，WebSphere 应用的性能很大程度上依赖于 WebSphere 应用服务器的性能。WebSphere 应用的开发人员应该理解 WebSphere 的编程接口，遵从 WebSphere 应用程序的高性能编程规范。WebSphere 应用的开发人员（或维护人员）还应该掌握 WebSphere 应用服务器的各种配置参数，通过参数调整保证 WebSphere 应用服务器工作在高性能状态。如果 WebSphere 应用服务器本身就工作不正常，很难期望上层的 WebSphere 应用程序工作正常。
图 1-6. 常见 WebSphere 应用系统的概念结构
WebSphere 应用服务器和 WebSphere 应用程序一样是一个 Java 程序，需要依赖于特定的 JDK 才能正常工作。深入优化 WebSphere 应用系统的性能，很多时候要从 JDK 入手。虽然 WebSphere 应用服务器已经屏蔽了很多 JDK 的实现细节，但是了解 JDK 的工作机理对于解决很多性能问题都是非常必要的（尤其是 Java 内存使用问题）。
除了 WebSphere 应用服务器，WebSphere 应用程序往往还需要依赖很多其他类型的服务器才能正常工作（最常见的是数据库服务器和 Web 服务器）。保证这些服务器高性能工作是整个 WebSphere 应用系统正常运行的必要前提。作者遇到的很多性能问题都不是 WebSphere 应用服务器的问题，而是数据库服务器端的问题。
无论 WebSphere 应用程序、WebSphere 应用服务器还是数据库服务器都是软件程序，它们都必须运行在一定的系统硬件之上。没有高性能的硬件支持，WebSphere 应用系统不可能高效地工作。读者可以想象一下要求一台运行在个人电脑上的 WebSphere 应用支持一个大型企业的业务负载会出现怎样的结果。
最后，在多数情况下，一个 WebSphere 应用往往需要与其他应用系统（很可能是非 WebSphere 应用）协同工作。这些应用包括其他业务系统或非业务系统。如果这些系统和 WebSphere 应用工作在同一个硬件环节中，那么，这些系统就可能和 WebSphere 应用系统竞争硬件资源。即使没有竞争资源的情况，WebSphere 应用和外部系统的接口乃至外部系统本身的性能都有可能影响到 WebSphere 应用自身的性能表现。
作者参与的电子商务应用中有很多这样的例子。比如在一个客户的解决方案中，支付系统（Payment）是由第三方软件厂商提供的。电子商务应用中与该第三方支付系统的接口存在并发性问题。在客户遇到高峰负载的情况下，这个支付系统的接口崩溃了。结果几乎所有的交易都不能正常完成。一个看起来并不起眼的程序模块造成了非常严重的性能问题。在另一个案例中，作者开发的电子商务应用需要和第三方的 LDAP（Light Directory Access Protocol，轻量级目录访问协议）系统协同工作，所有的用户都必须经过 LDAP 系统的身份认证才能登录到网上商店进行操作。但这个 LDAP 系统存在严重的性能问题，负载稍微大一些就会崩溃。导致作者部署的电子商务应用也不能在较大的负载下工作。尽管这不是 WebSphere 应用自身的问题，但最终的现象是整个系统的性能问题。毕竟最终用户直接看到的是 WebSphere 应用的性能表现，他们并不关心具体的性能问题是不是由 WebSphere 应用程序自身引起的。
因此，关注 WebSphere 应用的性能绝不能只关注应用程序本身或者应用服务器本身。必须对组成 WebSphere 应用系统的结构有清楚的认识，有能力对系统各个部分出现的性能问题加以辨别和处理。当然，WebSphere 应用系统的高性能工作并不一定要求系统的每一个部分都工作在最佳状态。整个系统的性能往往是由性能最差的环节（即所谓瓶颈）决定的。正确辨别系统的性能瓶颈，当瓶颈位于 WebSphere 应用程序之外时能够加以解决，只有如此才能构建高性能的 WebSphere 企业级应用。性能监视是发现性能问题，识别性能瓶颈的重要途径，本书第二部分将详细介绍性能监视的有关内容。
1.3.2 性能与应用系统的生命周期
本书强调的第二个观点是：提高性能是一个贯穿 WebSphere 应用生命周期的过程，决不能等到系统投入生产运行之后再来考虑性能问题。那样做的结果几乎注定会在生产运行中遇到严重的性能问题。而且如前面虚构场景中描述的那样，解决这些性能问题往往需要对整个系统重新设计，甚至将整个系统推倒重来。
作者认为，WebSphere 应用系统的生命周期如图 1-7 所示。
图 1-7. WebSphere 应用系统的生命周期
应用系统的生命周期大致可以分为四个阶段：需求与设计、实现、测试与评估、部署与运行。作者将这四个阶段表示为一个封闭的环形，因为实际系统往往是一个螺旋式上升的过程，对应于产品的各个版本或项目的各个实施阶段。
作者认为，提高 WebSphere 应用系统的性能要从生命周期的每一个阶段着手。
在需求与设计阶段就要考虑性能。首先是性能规划，制定系统的软硬件结构。其次是性能设计，概要设计阶段要制定高性能的编程模型（Programming model），详细设计文档中也要对性能充分考虑。
在系统实现阶段，需要高性能编程。系统的每一段代码都要考虑到对性能的影响，尤其是比较底层或者频繁被调用的代码。任何一段没有经过性能优化的代码都有可能成为最终系统的性能瓶颈。
在测试与评估阶段，应该进行充分的性能测试。只有通过性能测试才能验证针对性能的设计和编码是否有效。性能测试阶段往往需要对被测试的系统进行性能监视，以确定系统是否存在性能问题。
在部署（Deployment）和维护阶段，要对系统进行严密的性能监视。发现了性能问题要尽快进行问题诊断，对于相当一部分性能问题，可以考虑通过性能参数调优解决。
最终系统在生产环境中出现的性能问题会被反馈到需求和设计阶段，成为下一次性能规划或性能设计的依据。
本书第二部分将依次介绍各个生命周期中与性能相关的各种活动：从性能规划到性能参数调优。相对而言，本书对性能设计和高性能编码的论述并不太多。这是因为大部分讲述 WebSphere 应用性能的资料都会提到开发相关的内容，本书作者觉得没有必要重复这些内容。此外，通过本书第三部分讨论的各种性能问题，读者也能够了解到如何从设计和编码角度避免这些性能问题。
1.3.3 构建高性能应用的角色与任务
本书强调的第三个观点是：提供 WebSphere 应用系统的性能需要参与应用系统生命周期的各种角色人员的协同努力，不能片面地认为出现性能问题是某个角色（比如性能测试人员）的责任。
开发人员（包括设计人员）和测试人员是构建 WebSphere 应用最常见的角色。一般来说，开发人员负责性能设计和实现，测试人员负责性能测试。很多人认为开发人员和测试人员是一对矛盾。作者则更愿意把他们看作相互依存的整体。开发人员需要测试人员帮助他们发现问题，测试人员需要开发人员解决发现的问题。作者认为，开发人员和测试人员应该相互了解对方的工作，并协助对方的工作。比如性能测试人员应该在设计阶段审阅设计文档，确保设计中有针对性能的考虑；开发人员应该审阅性能测试人员的测试计划，确保测试计划能够覆盖应有的范围（覆盖可能存在性能问题的方面）。
实施人员（包括技术支持和服务人员）是构建高性能 WebSphere 应用的另一个重要角色。对于较小的产品或项目，实施人员与开发和测试人员可能隶属于同一个团队（甚至是同一个人）。对于比较大的产品或项目，则可能有专门的实施团队。实施人员需要对所实施应用的开发模型有比较清楚的了解，这样才能在实施过程中进行正确的配置。实施人员往往还需要在系统投入生产运行之前对系统进行最后的性能评估，所以，实施人员也需要有良好的性能测试知识。
构建高性能系统还有一个重要的角色是维护人员。维护人员通常与开发和测试人员属于不同的组织机构。以电子商务应用为例，大部分部署案例的维护人员隶属于客户的 IT 部门。运行维护人员的主要职责是对系统进行性能监视和性能调优。但维护人员也需要对所监视的 WebSphere 应用的内部机制有一定程度的了解，这样，才能对比较简单的性能问题进行正确的问题诊断和相应处理。
此外，比较大型的企业级产品或系统中还有一个专门的角色：性能架构师（Performance Architect）。性能架构师往往专门负责系统的性能规划和性能设计，他们也往往负责重大性能问题的诊断与解决。
本书第二部分将介绍 WebSphere 应用生命周期中的各种性能活动，不同的角色各有自己负责的活动。各角色的人员可以根据自身需要有选择地阅读对应章节。但本书推荐各角色人员都不要仅限于了解自己所负责的性能活动内容，也应该了解其他角色负责的活动内容，这样才能更好地完成份内的工作。
表 1-1 是作者推荐的各角色人员对各种性能活动的掌握程度。
表 1-1. 性能角色与性能活动
|
|
性能规划
|
性能设计与编程
|
性能测试
|
性能监视
|
性能问题诊断
|
性能参数调优
| |
性能架构师
|
精通
|
熟悉
|
熟悉
|
熟悉
|
精通
|
精通
| |
开发人员
|
熟悉
|
精通
|
了解
|
熟悉
|
熟悉
|
了解
| |
性能测试人员
|
了解
|
了解
|
精通
|
熟悉
|
熟悉
|
熟悉
| |
实施人员
|
了解
|
了解
|
熟悉
|
熟悉
|
熟悉
|
精通
| |
维护人员
|
了解
|
了解
|
了解
|
精通
|
熟悉
|
熟悉
|
1.4 小结
本章介绍了什么是 WebSphere 企业级应用，以及性能对企业级应用的重要意义。本章还通过一个虚拟的例子介绍了各种性能问题的现象和危害。最后，本章概括介绍了如下三个构建高性能 WebSphere 企业级应用的基本原则。
-
提高性能需要着手于整个系统的各个环节。
-
提高性能需要贯穿于系统的整个生命周期。
-
提高性能需要各种角色人员的协同努力。
读者反馈
欢迎您对本书提出宝贵的反馈意见。您可以通过本页面最下方的 建议 栏目为本文打分，并反馈您的建议和意见。
如果您对 developerWorks 图书频道有什么好的建议，欢迎您将建议发给我们。
参考资料
作者简介 | | | 孙磊， 北京大学计算机科学与技术系硕士，IBM 中国软件开发中心高级软件工程师。2003 年加入 IBM 中国开发中心至今，一直从事 WebSphere 企业级电子商务应用的测试和性能优化工作。兴趣包括 J2EE 应用性能理论模型，富客户端程序性能优化等 |
| | | 孙静，清华大学计算机科学与技术系硕士，IBM 中国软件开发中心软件工程师。2005 年加入 IBM 中国开发中心至今，一直从事 WebSphere 应用产品的性能评测工作。兴趣和经验包括 WebSphere 应用的内存问题分析，WebSphere 应用在 AIX，Linux，Windows 平台上结合 DB2，Oracle 的性能问题分析，以及网络应用的性能测试自动化等。 |
| | | 楼亭，南开大学计算机科学与技术系学士, IBM 中国软件开发中心高级软件工程师。长期从事 WebSphere 应用产品的系统测试及性能测试工作，对于 WebSphere 应用系统的性能问题诊断与解决以及 WebSphere 应用系统性能调优具有丰富的实践经验。 |
| | | 涂子琰，天津大学计算机科学与技术系硕士。IBM 中国软件开发中心高级软件工程师。2003 年加入 IBM 中国开发中心至今，一直从事 WebSphere 企业级电子商务应用的系统测试，性能测试和开发工作。并为客户实施 WebSphere 企业级电子商务应用的性能测试提供咨询服务。 |
| | | 王肖青，北京交通大学计算机与信息技术学院硕士, IBM中国软件开发中心软件工程师。2006 年加入 IBM 中国软件开发中心至今，主要从事针对电子商务平台的性能测试工作。工作内容包括性能测试的规划、性能问题的分析、自动化性能测试工具的研究等。 |
| | | 吴中华，西安电子科技大学计算机系硕士。IBM 中国软件开发中心高级软件工程师。2000 年加入 IBM 中国开发中心至今，一直从事 WebSphere 企业级电子商务应用的开发和维护工作。对于数据库死锁问题的分析和解决具有丰富的经验。 |
对本文的评价
| 
