图1: 用户负载，服务请求响应时间，和资源利用率之间的关系。
图1 把用户负载、服务请求响应时间和资源利用率关联了起来。你可以看到，当用户负载增加, 响应时间也缓慢的增加，而资源利用率几乎是线形增长。这是因为应用做更多的工作，它需要更多的资源。一旦资源利用率接近百分之百时，出现一个有趣的现象--响应以指数曲线方式下降。这点在容量评估中被作为饱和点。饱和点是指所有性能指标都不满足，随后应用发生恐慌的时间点。执行容量评估的目标是保证你知道这点在哪，并且你应该永远不要出现这种情况。在这种负载发生前，你应调优系统或者增加适当额外的硬件。
因此，一篇正式的容量评估报告包括以下内容：
基于应用的当前/期望的用户负载
在均衡和典型的服务请求下的应用的容量
当前负载下的关键服务请求的性能
每个服务请求的递降的模式
系统饱和点
建议
在你收集了数据和识别了关键点之后(比如：满足SLA，未满足SLA，递降模式，饱和点等)，下一步应该进行更加深入的分析并提出建议。请试将你的应用按下面分类：
极端利用不足的系统：系统可以支持大于50%的额外负载。
利用不足的系统：在当前/期望的负载下，所有服务请求都达到他们的SLA并且系统可以很容易地支持超过25%的额外负载。
临界容量：应用满足SLA，但其容量小于当前负载的125%。
过度利用的系统：应用不满足它的SLA。
极端过度利用的系统：在当前或期望的负载下，系统已经饱和。
在极端利用不足的系统中，你可以考虑减少硬件或者服务器的许可，来节省许可费用。是否需要这些额外的容量，这个决定只能由应用业务负责人讨论后才能确定。
在利用不足的系统中, 你就可以高枕无忧了，因为你的环境能忍受任何合理的额外负载, 但是，它的利用率也没有低到需要削减资源的程度。
在临界的容量系统中, 你需要花费大量的时间和应用业务负责人一起确定用户行为的未来变化，可预测的用法模式的变化和计划的促销等等，从而决定是否需要额外的资源。
在过度利用的系统中, 你需要更多资源。但这一点，仍然由应用业务负责人决定。应用没有达到SLA的严重程度？性能递降模式是什么? 当前的应用行为是否可接受？设计中的用法变化是否会极大降低应用性能？
在极端过度利用的系统中，你无庸置疑地会受到用户的抱怨，并且处于前面提到的完全惊慌的状态。你需要有效的调优并且尽可能得增加额外的资源譬如硬件，来保留住你的用户。
在重要的应用叠代的结尾，对于所有的应用部署，都应该执行容量评估。一个完善的容量评估采集应用的当前负载的性能，系统容量（当第一次服务请求未达到它的SLA时），服务请求的下降模式和环境的饱和点。从这些信息中, 你能概括出结论，发起关于修改环境的讨论。没有进行容量评估而盲目去做，希望在下一次促销或节日期间，应用不会崩溃。要求你的管理层批准这些工作，将能保证让您高枕无忧。
文章来源于领测软件测试网 https://www.ltesting.net/
