原文地址:
http://www.innovatedigital.com/htm_speek/Index_speek_33.shtml
很多人在使用诸如"容量评估"，"容量计划"，"趋势分析"和"预测" 等术语时，并没有真正理解这些词汇的含义。当有人提起"容量计划"时，通常是指他们的应用不能满足SLA，而将被迫购买更多的硬件。
长期以来，我们一直在倡导这样的观念：即使你的预算充足，添置硬件通常不是正确的解决方案，即使这也是一个有效的方案。通过主动实施系统的方法论来了解你的环境容量，在问题影响到你的最终用户之前，你可以避免被动地解决问题并且可以根据你的具体环境做出有根据的决定。
容量评估不只是负载测试。在准备好执行容量评估之前还需要准备下面内容：
* 均衡的，典型的服务请求: 需要了解你的用户，特别要知道他们的操作以及操作的百分比(均衡的)。
* 明确SLA：需要为关键服务请求定义精确的SLA。
* 期望的负载：需要知道应用所要支持的并发用户的数量。包括典型的行为，譬如与你的负载测试有关的思考时间。
* 渐进的负载产生工具：需要产生负载的应用可以在合理的时间内达到你期望的负载，然后再缓慢增加。
* SLA评价：该功能可以被内置在你的负载产生工具中或者由综合事务分析提供或是通过完成综合性的事务, 但重点是基于他们各自的SLA监测服务请求的响应时间。
* 资源利用率的监测：采集应用服务器的性能和操作系统资源利用率，以此确定资源利用率的饱和点，以及最先饱和的资源。在调优的的过程中，这种信息能帮助你确定何处更需要调优。
在掌握了所有这些数据后, 就可以开始对应用施加负载了。配置你的负载产生工具，在合理的时间(可以象10 分钟那么短，或像一个小时那么长，或根据在上线环境里观察到的用户行为)内，产生你期望的使用压力。在将负载增加到期望的负载过程中，应采集服务请求的响应时间并且基于他们的SLA进行评价。
一旦达到预期的用户负载，就可以确定你想要监测步骤的大小了。步骤的大小是在采样间隔之间增加的可测量的用户负载，定义了容量评估的精确粒度。例如，所期望的负载是1000 用户，你可以定义一个步骤为25或50名用户。在一个时间段中逐渐增加步骤，然后在这些时间段中记录服务请求的响应时间。
