长期以来，我们一直在倡导这样的观念：即使你的预算充足，添置硬件通常不是正确的解决方案，即使这也是一个有效的方案。通过主动实施系统的方法论来了解你的环境容量，在问题影响到你的最终用户之前，你可以避免被动地解决问题并且可以根据你的具体环境做出有根据的决定。
容量评估不只是负载测试。在准备好执行容量评估之前还需要准备下面内容：
均衡的，典型的服务请求: 需要了解你的用户，特别要知道他们的操作以及操作的百分比(均衡的)。 明确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 把用户负载、服务请求响应时间和资源利用率关联了起来。你可以看到，当用户负载增加, 响应时间也缓慢的增加，而资源利用率几乎是线形增长。这是因为应用做更多的工作，它需要更多的资源。一旦资源利用率接近百分之百时，出现一个有趣的现象--响应以指数曲线方式下降。这点在容量评估中被作为饱和点。饱和点是指所有性能指标都不满足，随后应用发生恐慌的时间点。执行容量评估的目标是保证你知道这点在哪，并且你应该永远不要出现这种情况。在这种负载发生前，你应调优系统或者增加适当额外的硬件。
文章来源于领测软件测试网 https://www.ltesting.net/
