软件性能测试 容量测试,软件性能测试的容量评估

软件性能测试的容量评估

发表于：2009-03-16来源：作者：点击数：

很多人在使用诸如"容量评估"，"容量计划"，"趋势分析"和"预测" 等术语时，并没有真正理解这些词汇的含义。当有人提起"容量计划"时，通常是指他们的应用不能满足SLA，而将被迫购买更多的硬件。 长期以来，我们一直在倡导这样的观念：即使你的预算充足，添置硬

很多人在使用诸如"容量评估"，"容量计划"，"趋势分析"和"预测" 等术语时，并没有真正理解这些词汇的含义。当有人提起"容量计划"时，通常是指他们的应用不能满足SLA，而将被迫购买更多的硬件。

长期以来，我们一直在倡导这样的观念：即使你的预算充足，添置硬件通常不是正确的

容量评估不只是负载均衡的，典型的服务请求: 需要了解你的用户，特别要知道他们的操作以及操作的百分比(均衡的)。 明确SLA：需要为关键服务请求定义精确的SLA。 期望的负载：需要知道应用所要支持的并发用户的数量。包括典型的行为，譬如与你的

在掌握了所有这些数据后, 就可以开始对应用施加负载了。配置你的负载产生工具，在合理的时间(可以象10 分钟那么短，或像一个小时那么长，或根据在上线环境里观察到的用户行为)内，产生你期望的使用压力。在将负载增加到期望的负载过程中，应采集服务请求的响应时间并且基于他们的SLA进行评价。

一旦达到预期的用户负载，就可以确定你想要监测步骤的大小了。步骤的大小是在采样间隔之间增加的可测量的用户负载，定义了容量评估的精确粒度。例如，所期望的负载是1000 用户，你可以定义一个步骤为25或50名用户。在一个时间段中逐渐增加步骤，然后在这些时间段中记录服务请求的响应时间。

对每个服务请求都采用这种模式，直到每个请求的响应时间超过它的SLA。需要注意这个时间并且开始以更短的间隔记录响应时间。增加采样的目的是，在达到它的容量之后，能够更好的识别一个服务请求是如何递降的。从这些递降的数字中，我们要尽量绘出响应时间，从而确定下降的程度：是线形下降？指数或更坏？这里的关键是我们了解未达到SLA所隐含的问题。

例如，如果在1500用户时，我们没达到SLA, 但是在增加下一个500名用户时，只增加了50%的响应时间，那么这要好于：每增加100用户就增加三倍的响应时间，然后在1800用户时整个应用服务器崩溃。这可以帮助我们了解和减轻由用户行为的变化而导致的风险。

对每一个服务请求，我们都汇总这种信息并且以最小公分母的方式关注应用的容量：即所有服务请求开始到未达到它的SLA。在在容量分析报告的下个部分，描述了性能递降应用的行为。从这个报告当中，业务负责人可以确定他们何时需要增加额外的资源。

当进行测试时，还需要监测应用服务器和操作系统资源的使用率。需要知道线程池，堆，JDBC连接池，以及其它后端资源连接池(比如：JCA 和JMS), 和缓存，还有CPU，内存, 硬盘I/O 和

图1: 用户负载，服务请求响应时间，和资源利用率之间的关系。

图1 把用户负载、服务请求响应时间和资源利用率关联了起来。你可以看到，当用户负载增加, 响应时间也缓慢的增加，而资源利用率几乎是线形增长。这是因为应用做更多的工作，它需要更多的资源。一旦资源利用率接近百分之百时，出现一个有趣的现象--响应以指数曲线方式下降。这点在容量评估中被作为饱和点。饱和点是指所有