1.2.2 性能问题的现象

作者: 孙磊/孙静/楼亭/涂子琰等编著 出处:电子工业出版社 　2008-06-05 17:11　   砖    好    评论  条 　进入论坛

阅读提示：《构建高性能WebSphere企业级应用》第1章主要介绍的是性能与WebSphere企业级应用, 本节将为大家介绍性能问题的现象。

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  性能随时间下降问题

本节讨论的主要是在一个较小的时间尺度内（即系统负载没有明显变化），系统性能发生明显下降的情况。由于下降趋势的存在，不论系统初始的性能有多好，在足够长的时间后，系统的性能也会下降到零。实际系统中这种下降的趋势可能相当缓慢，只有在系统性能下降到比较严重的时候问题才被发现。

不少开发人员对于系统性能下降的问题并不太重视，甚至有人会把定期重新启动整个系统推荐作为性能随时间下降问题的解决方案。对于企业级应用而言，这是不可接受的。如前所述，企业级应用系统中断运行很短时间都可能为企业带来巨大的经济损失。复杂的企业级应用重新启动一次往往需要很长的时间，所以，如果不是万不得已，企业级应用是不会随便重新启动的。

企业级应用中可能出现的性能问题还有很多，这里就不一一列举了。本书第三部分将通过实例详细介绍企业级应用中常见的性能问题的分析和解决方法。

回书目   上一节   下一节