容量规划决定了系统是否能够处理负载

Question

假设一个基于Java的电子商务网站在预期的响应时间和吞吐量方面表现良好。该网站正在经历重大的用户界面变化，预计将带来3倍以上的流量。

如何确定现有环境是否可以处理预计的web流量？

如果我有现有系统的系统利用率(CPU，内存利用率)，吞吐量，响应时间，有没有办法在不对系统进行实际负载测试的情况下，使用一些经验公式来找出它。(目标是确定在设计阶段本身是否可以满足SLA)

Answer 1

不，这没有公式，只是有太多相互依赖的因素。获得真实数字的唯一方法是通过经验测试。如果你不能做到这一点，你唯一的选择就是去找硬件中的容量过剩，并做一个有根据的猜测，大概是这样：

• 新UI是否影响CPU使用率？
• 渲染和传输页面是否需要更长时间？估计concurrency.
• Does流量的增加更多也意味着更多的数据？如果是，这如何影响performance?
• Are是否存在可能导致concurrency?
• How意外增加的瓶颈?增加的并发性是否会影响内存使用率？
• 内存使用率如何影响文件系统缓存、数据库缓存、JPA缓存等。
• 受性能IO限制？available?
• Is性能CPU限制了多少空闲容量？您的内存中有多少空闲容量？

Answer 2

我部分地不同意之前的回答。可以肯定的是，任何容量规划都涉及到使用一组(潜在危险的)假设创建模型。

然而，有一个很好的历史观点：

• 事务性负载(例如，Apache日志上的web点击率)
• CPU和内存利用率

可以构建负载性能分析，以通过分析统计技术确定“服务需求”(粗略地说，用于处理单个请求的资源量)。然后，可以将相同的参数馈送到排队网络模型中，以估计预期的响应时间和吞吐量(其行为在资源饱和程度较高时可能会变得高度非线性)。

不管刚才说了什么：-这不是一个简单的公式

• 您需要假设新UI的影响是负载生成的3倍，而不是其他(请求的相同服务需求，相同的efficiency)
• you're冒着遇到未建模的可能瓶颈(例如，饱和连接池、网络带宽等)的问题的风险)这是容量规划的一般问题。

测试是唯一安全的选择，不幸的是，太多的选择是不可用的。