.　　　2.1.3　资源占用指标
　　　2.1.4　各指标之间的关系
　　2.2　理论分析
　　　2.2.1　理论模型与实际问题　　
　　　2.2.2　实例分析：漏斗模型　　
　　2.3　缓存技术与性能模型
　　　2.3.1　提升系统性能的途径　　
　　　2.3.2　WebSphere动态高速缓存技术
　　　2.3.3　动态高速缓存性能模型
　　　2.3.4　WebSphere 6.1对动态高速缓存的改进　
　　2.4　小结
第2部分　技术篇
　第3章　WebSphere应用性能规划　
　　3.1　性能规划的一般过程
　　　3.1.1　理解应用环境
　　　3.1.2　系统负载分析
　　　3.1.3　软件结构中的性能设计
　　　3.1.4　硬件结构中的性能设计
　　3.2　拓扑结构设计
　　　3.2.1　WebSphere应用拓扑结构
　　　3.2.2　实例分析：电子商务应用拓扑结构设计　　
　　3.3　系统容量规划
　　　3.3.1　容量规划的范围　　
　　　3.3.2　CPU容量规划的理论模型　　
　　　3.3.3　实例分析：电子商务应用容量规划　　
　　3.4　小结
　第4章　WebSphere高性能编程
　　4.1　MVC结构与高性能编程　
　　　4.1.1　MVC结构　
　　　4.1.2　电子商务应用分层结构
　　　4.1.3　提高性能的一般原则　　
　　4.2　控制层
　　　4.2.1　一般性建议　　
　　　4.2.2　电子商务应用最佳实践
　　4.3　模型层
　　　4.3.1　一般性建议　　
　　　4.3.2　电子商务应用最佳实践
　　4.4　视图层
　　4.5　其他最佳实践
　　　4.5.1　内存使用
　　　4.5.2　数据软删除　　
　　　4.5.3　缓存与滞后取
　　　4.5.4　数据库编程　　
　　4.6　小结
　第5章　WebSphere应用性能测试　
　　5.1　性能测试概述
　　　5.1.1　性能测试的一般方法　　
　　　5.1.2　性能测试的一般流程　　
　　5.2　电子商务应用性能测试
　　　5.2.1　制定测试计划
　　　5.2.2　执行测试
　　　5.2.3　管理测试资产
　　　5.2.4　常见问题处理
　　5.3　性能测试工具
　　　5.3.1　常见性能测试工具
　　　5.3.2　选择负载测试工具
　　　5.3.3　测试工具发展趋势
　　5.4　小结
　第6章　企业级应用性能监视　　
　　6.1　性能监视概述
　　　6.1.1　监视对象与监视策略　　
　　　6.1.2　监视级别
　　6.2　操作系统监视
　　　6.2.1　nmon　
　　　6.2.2　top和topas　　
　　　6.2.3　vmstat和iostat　
　　　6.2.4　typeperf
　　　6.2.5　zVM监视
　　6.3　WebSphere应用服务器监视　　
　　　6.3.1　Tivoli性能查看器　
　　　6.3.2　高速缓存监视器　　
　　6.4　数据库服务器监视
　　　6.4.1　DB2性能监视
　　　6.4.2　Oracle监视　　
　　6.5　生产环境性能监视
　　　6.5.1　Tivoli产品家族　
　　　6.5.2　ITCAM监视工具
　　6.6　小结
　第7章　性能问题分析与诊断　　
　　7.1　性能问题诊断的一般过程
　　　7.1.1　自顶向下分析与自底向上分析　　
　　　7.1.2　电子商务应用的问题诊断过程　　
　　7.2　WebSphere应用日志分析
　　　7.2.1　Web服务器日志　　
　　　7.2.2　应用服务器日志　　
　　　7.2.3　数据库服务器日志
　　　7.2.4　日志分析工具
　　7.3　WebSphere应用程序运行剖析
　　　7.3.1　Heap分析
　　　7.3.2　JInsight
　　　7.3.3　TPTP分析平台
　　　7.3.4　ITCAM
　　7.4　小结
　第8章　WebSphere应用性能参数调优　
　　8.1　参数调优概述
　　　8.1.1　一般过程
　　　8.1.2　基本原则
　　　8.1.3　参数调优与性能测试　　
　　8.2　电子商务应用经验参数
　　　8.2.1　操作系统调优参数
　　　8.2.2　Web服务器调优参数　　
　　　8.2.3　数据库服务器调优参数
　　　8.2.4　应用服务器调优参数　　
　　　8.2.5　硬件配置
　　8.3　性能参数调优实例介绍
　　8.4　小结
第3部分　实践篇
　第9章　死锁问题实例分析　　
　　9.1　死锁的原理
　　　9.1.1　抽象死锁原理
　　　9.1.2　DB2锁管理机制　　
　　9.2　死锁问题处理的一般过程
　　　9.2.1　发现死锁
　　　9.2.2　解决死锁
　　9.3　常见死锁问题处理实例
　　　9.3.1　RUNSTATS　　
　　　9.3.2　缺少索引
　　　9.3.3　SQL语句不合理　　
　　　9.3.4　资源访问顺序问题
　　　9.3.5　隔离级别问题
　　　9.3.6　意外更新记录
　　9.4　小结
　第10章　内存使用问题实例分析
　　10.1　WebSphere内存管理　
　　　10.1.1　Java虚拟机与垃圾回收机制　
　　　10.1.2　WebSphere应用中的JVM内存管理　
　　10.2　WebSphere内存问题分析　
　　　10.2.1　内存问题分析的一般过程　
　　　10.2.2　垃圾回收分析工具　
　　10.3　常见内存问题实例　　
　　　10.3.1　JVM堆大小问题　
　　　10.3.2　固定对象问题　
　　　10.3.3　大对象问题　
　　　10.3.4　缓存大小问题　
　　　10.3.5　内存泄漏问题　
　　10.4　小结　　
　第11章　性能下降问题实例分析
　　11.1　性能下降问题　
　　　11.1.1　常见现象和产生原因　
　　　11.1.2　分析和解决过程　
　　11.2　自顶向下分析实例　
　　　11.2.1　问题背景　
　　　11.2.2　自顶向下分析过程
　　11.3　数据库引起的性能下降问题实例　
　　　11.3.1　问题背景　
　　　11.3.2　分析与解决过程　
　　11.4　小结　
　第12章　动态高速缓存实例分析
　　12.1　动态高速缓存设计　　
　　　12.1.1　基本缓存策略　
　　　12.1.2　整页缓存与片段缓存　
　　　12.1.3　命令缓存　
　　　12.1.4　磁盘缓存　
　　　12.1.5　外部缓存　
　　　12.1.6　失效处理　
　　　12.1.7　缓存复制　
　　12.2　实例分析：B2C网站动态高速缓存的设计与实现
　　　12.2.1　缓存需求分析　
　　　12.2.2　整页缓存：产品目录页　
　　　12.2.3　片段缓存：迷你购物车　
　　　12.2.4　命令缓存：组织查询　
　　　12.2.5　缓存配置参数设计　
　　　12.2.6　缓存部署与验证　
　　　12.2.7　缓存预加载机制　
　　12.3　动态高速缓存常见问题处理　　
　　　12.3.1　页面内容重复　
　　　12.3.2　缓存内容错误　
　　　12.3.3　JVM内存不足
　　　12.3.4　磁盘I/O导致性能下降　
　　12.4　小结　　
附录A　测试工具介绍
附录B　操作系统监视工具介绍
附录C　动态高速缓存辅助资料
参考文献　　
术语表

.第3部分实践篇分专题重点讨论构建WebSphere企业应用中的几个常见性能问题和相应的解决途径。通过对这几个专题的实例分析，可以加深读者对第二部分中介绍的各个环节所涉及的原理与经验的理解与掌握。这一部分包括以下4章。
第9章介绍死锁问题。死锁是数据密集型应用系统的常见问题。本章将通过实例来介绍系统出现死锁问题的常见原因，以及相应的解决方案。
第10章介绍内存使用问题。内存使用问题常常导致严重的性能问题。本章将介绍包括内存碎片和内存泄漏在内的一些典型的内存使用问题，并针对每一类问题介绍实际问题的现象、问题产生的原因，以及分析处理过程。
第11章介绍性能下降问题。性能下降问题产生的原因很多，本章将根据作者在分析和处理实际应用中积累的解决系统性能随时间下降问题的经验，总结一套解决类似问题的方法。
第12章介绍动态高速缓存的使用问题。使用动态高速缓存是提高WebSphere应用系统性能的重要方法之一。然而，正确使用动态高速缓存并不是一个非常简单的过程。本章将通过实例介绍如何设计和实现动态高速缓存，以及如何处理不恰当的缓存使用带来的性能问题。
本书的三部分内容是一个密切联系又相对独立的整体，基本上是按照从理论到实践的顺序进行组织的。读者可以根据自己的需要直接阅读某个章节。比如，有经验的系统管理员可以在简单浏览第1章后跳到第二部分阅读第6章和第8章。但是作者认为，构建高性能WebSphere企业应用系统是一个完整的过程，了解这个过程各个环节的原理对于正确分析和处理性能问题，并最终解决性能问题是非常必要的。在时间允许的情况下，作者建议读者完整地阅读第一部分和第二部分内容，然后，对第三部分的实例分析，根据需要，有选择地阅读以加深对前两部分的理解。
本书中的大部分例子基于WebSphere应用服务器6.0版本，另有一小部分基于WebSphere应用服务器6.1版本。实例中如果没有特殊说明，对应WebSphere应用服务器的版本均为6.0。实际上，本书介绍的大部分原理和技巧与WebSphere应用服务器的具体版本无关。读者完全可以根据自己的理解，在不同的WebSphere应用服务器版本中，应用相关原理和技巧。
致谢
本书是集体创作的结晶，首先感谢每一位作者的辛勤工作。本书的写作占用了各位作者大量的休息、娱乐，以及和家人在一起的时间，所以，在此感谢各位作者家人的理解和支持。
其次，感谢IBM多伦多实验室的WebSphere应用专家James Tang、Robert Dunn、Alex Shum提供相关资料及建议；感谢IBM中国开发中心的架构师王紫瑶、周彬、姜斌等审阅本书的内容，并提供宝贵的修改意见。
在本书成书的过程中，笔者得到各位领导的关怀、鼓励和支持，其中包括IBM中国软件开发中心总裁郑妙勤女士、经理主管沈政芳先生、开发经理王克非先生和孙清涛先生等，在此一并表示感谢。
最后，感谢出版社的有关领导、协调人员及编辑，没有他们的支持和参与，本书不可能顺利出版。
由于时间仓促，作者水平有限，书中难免有许多不妥甚至错误之处。在此，敬请读者不吝指出，作者非常愿意与读者共同探讨，并不胜感激。...

.　　1.1.3　电子商务应用
　 本书是一本经验分享型的书，书中介绍的是作者在开发、测试和维护WebSphere企业级应用系统过程中的实践经验。为了使读者更容易理解书中提到的性能问题或系统结构，有必要介绍一下作者所参与的企业级应用系统的背景。作者所参与的主要是IBM提供的电子商务解决方案或应用系统，在本书中简称电子商务应用。
　　电子商务本身是一个比较宽泛的概念，本书中所提到的电子商务应用特指由IBM提供的在WebSphere平台上构建的电子商务（e-Commerce）解决方案。按照前两节的概念，作者参与的电子商务应用（e-Commerce Application）是一个构建于WebSphere平台上的企业级应用。该应用的客户都是企业客户，客户搭建该应用是为了构建网络或其他渠道上的交易平台。这些企业的最终用户可以通过该电子商务应用进行企业对客户（B2C）或企业对企业（B2B）的交易活动。如前所述，绝大部分企业客户对作者开发的电子商务应用的性能都有很高的要求，所部署的应用也通常要面对非常高的业务负载。企业客户投入很多资金购买和构建作者参与的电子商务应用，电子商务应用也给客户带来了可观的经济效益。比如，某大客户目前70％的营业收入是通过电子商务应用的业务渠道获得的。
　　本书后面绝大部分讨论都是以该应用为背景介绍的，本节就对该应用的大体结构及相关概念进行简单的介绍。
　　用一句话概括，作者参与的电子商务应用的功能设计是为企业用户提供企业对企业（B2B）或企业对客户（B2C）的电子商务解决方案。它提供一组紧密集成的软件模块，帮助企业客户实现快速的、高度自动化的跨渠道营销和销售流程。电子商务应用的功能如图
　　1.2　所示。
　　电子商务应用对最终用户（购买客户）提供的界面是丰富多彩的电子商店。购买客户可以通过各种渠道访问电子商店：可以是Web浏览器，也可以是各种智能终端设备，或者通过电话联系客户经理进行交易。
　　电子商务应用为企业业务人员提供各种各样的管理功能：审批订单、修改库存等。业务人员也可以通过多种渠道访问这些管理功能：可以是Web浏览器，也可以是基于Eclipse技术的富客户端工具。
　　电子商务应用支持多渠道（multi.channel）的访问方式，所以，作者在工作中遇到的性能问题也不局限于Web应用中的问题。不过，目前Web仍然是最主要的访问渠道，因此，本书中的讨论也以Web应用中的性能问题为主。
　　电子商务应用内部最核心的概念是商业模式（Business Model）和业务流程（Business Process）。B28和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所示的错误。
　　张三决定立刻解决这些问题。可是张三和他的朋友们钻研了几天也找不到头绪。网上商店的客户已经开始流失了，张三觉得不能再拖下去了。他找到了一家专业开发Web应用系统的公司来重新构建整个网站。有了以前的教训，张三把性能指标写入了需求规格说明书。他要求新的网站能够满足如下要求：
　　•系统高峰时期的页面平均响应时间不超过2秒
　　•系统每天可以处理1000个订单
　　•系统可以满足在5年内每年业务量增加50％的负载需求
　　•……
　　上面的场景是一个完全虚构的场景，但是，读者可以从这个场景中看到一些自己身边遇到的问题的影子。
　　1.2.2　性能问题的现象
　 各种应用要处理的业务不同，所面临的性能问题也会不同。本书主要讨论基二于二WebSphere构建的Web应用所面临的各种性能问题。下面就基于前一节举出的虚构场景，列举一些Web应用中常见的性能问题。在对各种性能指标进行定义之前，本节采取定性的非严格的描述方式。
　 1.交易出错
　 应用程序中的功能性问题也会导致在客户访问过程中出现错误。与功能性错误不同，性能问题导致的错误多数是由于并发访问造成的。也就是说，单个用户访问时没有错误，多个用户访问（或者说系统负载比较高）的时候才出现错误。
　 系统出错可能有两种类型。
　一种是系统的某个部分发生致命错误而完全不能工作，比如数据库服务器崩溃（Crash）。这种情况下，所有需要经过该部分的交易都会出现错误，而且一段时间内无法恢复。这种错误是非常严重的错误，企业级应用中基本上不应该出现这样的错误。
　　系统中经常出现的是另一种错误，即某些特定交易（或操作）出现错误。这种错误往往与系统特定的运行状态相关，也就是说，同一时间内，有些用户的交易出现错误，另外的用户则没有错误。这种错误又可以分为两种类型。一种是可恢复的，比如某个用户在网上商店提交订单的时候出现错误，用户刷新页面或者再次提交这个订单的时候就有可能成功地完成交易。另一种则是不可恢复的，比如前一节虚构场景中提到的，某些用户在订单交易出错的时候出现订单丢失的情况。订单一旦丢失，往往不能再从系统中找回来（虽然理论上讲可能通过服务器端的某些特殊处理进行恢复）。这两种错误相比，不可恢复的错误是更严重的。
　 2.交易速度慢
　与交易出错相比，交易速度慢的问题可能隐蔽一些。一些开发人员或维护人员可能认为只要应用系统把所有的交易处理都正确完成就可以了，处理速度慢一些没有太大关系。其实，从某种意义上讲，交易处理速度慢的问题更为严重。
　　从应用的服务器端或者从系统管理员的角度看，交易处理速度表现为单位时间内，系统处理的交易数目。对于最终用户而言，系统的处理速度表现为页面的响应时间。即使没有对响应时间的精确定义，大多数读者对于响应时间也有感性的认识。访问有些网站的时候，单击一个链接，马上就可以显示出页面；而访问另一些网站的时候，单击一个链接之后需要等上半天才能看到结果页面。
　　与交易出错（要么出错，要么不出错）相比，交易速度慢的问题更模糊一些。响应时间长到多少算是“慢”，并没有一个统一的定义。有些用户可能响应时间在10秒钟之内就可以接受，另一些用户可能对于3秒以上的响应时间就认为很慢了。这与用户的心理状态、处理交易的类型、其他类似应用的响应时间水平等许多因素有关。应用开发人员和测试人员需要根据各自应用的具体情况制定判定标准。
　　用户一旦认为交易（或页面）的响应时间“慢”，就有可能采取一些措施，比如反复刷新页面，重新提交操作，或者干脆放弃当前交易。应用系统的交易速度慢本来就可能是由系统负载重导致的，用户的这些行为有可能进一步加重系统的负载（用户即使放弃交易，该交易也可能还在服务器端继续运行），导致交易出错的产生。
　　此外，交易处理速度慢到一定程度，有可能超过系统各个环节的超时（TimeOut）设置，从而导致超时类错误的产生。
　　3.资源使用问题
　　与前面两种问题相比，资源使用问题更隐蔽，也更容易为开发或维护人员所忽略。
　　应用程序要正常运行，就必须使用各种各样的系统资源：CPU是资源，内存是资源，磁盘I/O是资源，这些都是物理存在的资源。还有一些抽象的逻辑资源，比如数据库系统中常用的“锁”也是一种特殊的资源。在特定的应用系统中，任何资源都是有限的，对资源的竞争或滥用都可能导致问题。
　　……