数据库引起的性能下降问题实例数据库 性能 自顶向下分析 性能下降问题Word下载.docx

数据库引起的性能下降问题实例数据库 性能 自顶向下分析 性能下降问题Word下载.docx

《数据库引起的性能下降问题实例数据库 性能 自顶向下分析 性能下降问题Word下载.docx》由会员分享，可在线阅读，更多相关《数据库引起的性能下降问题实例数据库 性能 自顶向下分析 性能下降问题Word下载.docx（41页珍藏版）》请在冰豆网上搜索。

不同的产品有不同的版本定位策略，各个版本之间的差别也没有一个统一的标准。

但一般而言，企业版或商业版都是整个产品线中最高级别的版本。

本书题目中的企业级应用（EnterpriseApplication）也是指与一般的中小型或非商业应用相区别的应用，而不是泛指使用Java2企业版（Java2EnterpriseEdition）技术构建的应用。

本书所特指的企业级应用，通常都为大中型企业维持生产运行提供服务。

中断这些应用系统的正常运行，对整个企业的营业利润会造成巨大的影响，所以，对企业级应用的各方面都有严格的要求。

比如安全性，企业级应用的数据通常都是企业的核心业务数据，对这些核心业务数据的非法访问可能为企业带来非常严重的损失。

又比如数据准确性和完整性，对某些重要交易数据的错误处理可能带来包括法律诉讼在内的严重后果。

此外，最常见、也是本书想强调的就是对性能的严格要求。

在澄清有关性能的具体概念之前，这里先对企业级应用的性能需求进行一些感性的描述。

首先，企业级应用往往需要承担很大规模的业务负载。

以作者参与的某个电子商务应用系统为例，该系统有四百万用户定期访问，平均每小时要处理三百万次Web页面访问。

比这更大的业务负载在企业级应用中也很常见。

其次，企业级应用的运行往往支撑着企业的核心业务，所以，要求应用程序能够提供7乘24小时的不间断服务。

仍以上面提到的电子商务应用系统为例，该系统平均每小时会产生一万个订单（Order）。

按照平均每个订单的交易金额为一百美元计算，平均每小时的交易金额为一百万美元。

也就是说，该系统的正常运行每中断一小时，就可能带来一百万美元的经济损失。

再次，企业级应用对应用程序的处理速度（或运行效率）要求很高。

前面提到的系统平均每小时要处理一万个订单，也就是说，系统需要在大约三分之一秒内处理完一个订单。

这看起来似乎并不是很快。

但如果考虑到系统同时还要应付每小时三百万次页面访问，商业应用中订单的业务逻辑又非常复杂，此外还要兼顾数据安全性、完整性的要求，三分之一秒内处理完一个订单已经对应用程序的处理速度提出了非常高的要求。

总之，在商品经济社会，一个企业花费巨额资金构建一个企业级应用，是为了带来更多的利润。

如果这个企业级应用不能带来经济效益，那么，就没有必要构建它。

所以，作者更愿意将企业级应用称为商业应用（BusinessApplication）。

企业级用户对应用程序运行的要求总是越快越稳定（或者说性能越高）越好。

因此，高性能是一个应用能成为企业级应用的重要前提。

1.1.3 

电子商务应用

本书是一本经验分享型的书，书中介绍的是作者在开发、测试和维护WebSphere企业级应用系统过程中的实践经验。

为了使读者更容易理解书中提到的性能问题或系统结构，有必要介绍一下作者所参与的企业级应用系统的背景。

作者所参与的主要是IBM提供的电子商务解决方案或应用系统，在本书中简称电子商务应用。

电子商务本身是一个比较宽泛的概念，本书中所提到的电子商务应用特指由IBM提供的在WebSphere平台上构建的电子商务（e-Commerce）解决方案。

按照前两节的概念，作者参与的电子商务应用（e-CommerceApplication）是一个构建于WebSphere平台上的企业级应用。

该应用的客户都是企业客户，客户搭建该应用是为了构建网络或其他渠道上的交易平台。

这些企业的最终用户可以通过该电子商务应用进行企业对客户（B2C）或企业对企业（B2B）的交易活动。

如前所述，绝大部分企业客户对作者开发的电子商务应用的性能都有很高的要求，所部署的应用也通常要面对非常高的业务负载。

企业客户投入很多资金购买和构建作者参与的电子商务应用，电子商务应用也给客户带来了可观的经济效益。

比如，某大客户目前70%的营业收入是通过电子商务应用的业务渠道获得的。

本书后面绝大部分讨论都是以该应用为背景介绍的，本节就对该应用的大体结构及相关概念进行简单的介绍。

用一句话概括，作者参与的电子商务应用的功能设计是为企业用户提供企业对企业（B2B）或企业对客户（B2C）的电子商务解决方案。

它提供一组紧密集成的软件模块，帮助企业客户实现快速的、高度自动化的跨渠道营销和销售流程。

电子商务应用的功能如图1-2所示。

图1-2 

IBM电子商务应用的功能

电子商务应用对最终用户（购买客户）提供的界面是丰富多彩的电子商店。

购买客户可以通过各种渠道访问电子商店：

可以是Web浏览器，也可以是各种智能终端设备，或者通过电话联系客户经理进行交易。

电子商务应用为企业业务人员提供各种各样的管理功能：

审批订单、修改库存等。

业务人员也可以通过多种渠道访问这些管理功能：

可以是Web浏览器，也可以是基于Eclipse技术的富客户端工具。

电子商务应用支持多渠道（multi-channel）的访问方式，所以，作者在工作中遇到的性能问题也不局限于Web应用中的问题。

不过，目前Web仍然是最主要的访问渠道，因此，本书中的讨论也以Web应用中的性能问题为主。

电子商务应用内部最核心的概念是商业模式（BusinessModel）和业务流程（BusinessProcess）。

B2B和B2C就是完全不同的商业模式。

电子商务应用内部的功能都围绕这些商业模式和业务流程展开。

电子商务应用可以独立地为客户提供服务，它也可以和客户的其他业务系统合作，为客户提供完整的解决方案：

客户关系管理系统（CRM）、企业资源计划系统（ERP）等。

电子商务应用可以通过包括Web服务在内的多种集成接口和这些业务系统进行集成。

电子商务应用内部划分为一些小的功能模块。

如订单处理（OrderManagement）、产品目录和内容管理（CatalogandContentManagement）等。

电子商务应用提供了相当丰富的预置（OutOfBox）功能，用户使用这些功能就可以搭建一个完整的网上商店。

电子商务应用也提供了开发环境和二次开发接口，大客户的开发人员（或IBM的技术服务人员）可以在其基础上进行定制开发（Customization）。

所以，作者遇到的性能问题有一些来自于电子商务应用的核心代码（产品开发），另外一些则来自于用户的定制开发代码（项目开发）。

在电子商务应用的开发和维护过程中遇到的性能问题涵盖的范围很广，但限于篇幅和作者的亲身经验，本书讨论的性能问题只是其中的一小部分。

1.2 

性能问题

前一节介绍了什么是WebSphere企业级应用，以及性能对企业级应用的重要性。

本节讨论什么是性能，通过介绍一些性能问题来界定讨论范围。

实际上，对企业级应用系统性能的掌握是与各种各样的性能问题联系在一起的。

这是一个遇到问题、解决问题、再遇到新问题的螺旋式上升的过程。

所以，提高企业级应用系统的性能是一个经验性很强的工作。

通过阅读和理解本书中介绍的各种性能问题，希望读者学会如何分析和解决这些问题。

这样才能够在自己的实际工作中遇到类似问题时处理得得心应手，并且能够在设计和实现新的企业级应用系统时设法避免类似的问题。

1.2.1 

一个虚构的场景

为了避免争议，此处以一个纯粹虚构的场景为例。

张三是一个钓鱼爱好者，同时又是一个很有商业头脑的青年。

他在五年前就看好互联网上的商机，创办了一个以销售钓鱼器具为核心业务的网站。

网站有钓鱼爱好者的论坛，也有出售钓鱼器具的网上商店。

网站是张三和几个朋友创建的。

构建之初主要考虑的是如何实现网站的各种功能，采用的技术也力求简单。

网站在一个月内就投入运行了。

刚开始的时候，网站的访问量很少。

出现过一些功能上的问题，但依靠张三和朋友们的技术力量很快就解决了这些问题。

张三的网站经过了最初几年的艰难时期，终于存活了下来。

网站的知名度也稳步提高。

张三不失时机地对网站进行了改版，引入最新的页面展示技术：

个性化页面，用户评价系统，动态广告，等等。

网站的网页越来越吸引人。

网站的访问量成倍地提升。

每天的访问量从几百增加到几万。

网上商店的业务量也从每天几个订单增加到每天几百个订单。

辉煌的前景就在眼前。

可就在这时，问题出现了。

越来越多的用户抱怨网页的响应时间变慢了，有时候需要等待十几秒一个网页才能显示出来。

更加不能忍受的是订单交易的过程中经常出错。

有的用户还反映在交易出错之后出现订单丢失的情况。

与此同时，网站的管理员（张三的朋友）也发出了警告：

在网站的访问高峰时期，网站服务器的CPU使用率达到了100%。

再这样下去，也许网站有一天会瘫痪的。

张三决定亲自体验一下问题的严重性。

于是他在网站的访问高峰期访问了自己的网上商店。

结果令人震惊：

在等待20秒后才进入网站的首页，而单击第一个热销商品的时候就出现了如图1-3所示的错误。

图1-3 

应用程序页面错误示例

张三决定立刻解决这些问题。

可是张三和他的朋友们钻研了几天也找不到头绪。

网上商店的客户已经开始流失了，张三觉得不能再拖下去了。

他找到了一家专业开发Web应用系统的公司来重新构建整个网站。

有了以前的教训，张三把性能指标写入了需求规格说明书。

他要求新的网站能够满足如下要求：

—系统高峰时期的页面平均响应时间不超过2秒

—系统每天可以处理1000个订单

—系统可以满足在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）的概念其实很广泛。

系统运行的各个方面的好坏都可以被称为性能。

本书讨论应用系统的性能，主要是和功能相区别的。

当开发人员制定一个企业级应用系统的需求规格说明书的时候，往往将需求分为两大类：

功能性需求（Functionalrequirement）和非功能性需求（Non-functionalrequirement）。

很大一部分非功能性需求都和性能相关。

前面列举的虚构场景中提到的一些非功能性需求，如响应时间、交易处理速度等，都属于性能需求。

本书将应用系统的性能笼统地界定为：

保证应用系统高效、持久、稳定运行的各种能力。

显然这不是一个严格的定义。

读者可以通过本书讨论的性能指标、性能问题和相关活动来界定本书的讨论范围。

与性能相关的常见概念还有高可用性（HighAvailability）和可扩展性（Scalability）。

可用性（Availability）不同于易用性（Usability）。

可用性强调的往往是容错性或从灾难中恢复的能力。

高可用性技术往往涉及冗余技术（Redundancy）或备份切换（Backupandtakeover）技术。

高可用性是性能领域的一个重要分支。

它也是一个相对独立的分支。

在某种程度上说，许多高可用性技术（比如冗余）是通过牺牲运算能力提供更好的容错性。

本书内容将不涉及高可用性问题。

可扩展性是指系统性能能够随负载增加而增加的能力（趋势），如图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