容量规划决定系统是否能够处理负载
假设一个基于 Java EE 的电子商务网站运行良好，具有预期的响应时间和吞吐量。该网站正在经历重大的 UI 更改，预计将带来 3 倍的流量。
如何确定现有环境是否可以处理预计的网络流量？
如果我有现有系统的系统利用率（CPU、内存利用率）、吞吐量、响应时间，有没有办法使用一些经验公式来找出它，而无需实际对系统进行负载测试。 （目标是确定在设计阶段本身是否可以满足 SLA）
Lets say a Java EE based e-commerce web site is performing well giving expected response time and throughput. The web site is undergoing major ui changes and it is expected to bring 3 times more traffic.
How do I find out whether the projected web traffic could be handled by the existing environment?
Is there a way to find it out using some empirical formula without actually load testing the system if I have the system utilization (CPU, memory utilization), throughput, response time of the existing system. (The goal is to determine whether the SLAs could be met in the design stage itself)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，这没有公式，只是有太多相互依赖的因素。获得真实数字的唯一方法是通过实证测试。如果你做不到这一点，你唯一的选择就是寻求硬件容量过剩，并进行有根据的猜测，如下所示：
No there is no formula for this, there are just too many interdepend factors for this. The only way to get realistic numbers is by empirical tests. If you can't do this, you're only option is to go for overcapacity in hardware and do an educated guess that would go something like this:
我部分不同意之前的答案。
当然，任何容量规划都涉及创建具有一组（潜在危险）假设的模型。
尽管如此，对以下方面有良好的历史了解：
事务负载（例如 Apache 日志上的 Web 命中）
CPU 和内存利用率
负载性能分析，以便通过分析统计技术确定“服务需求”（粗略地说，用于处理单个请求的资源量）。
然后可以将相同的参数输入到排队网络模型中，以估计预期响应时间和吞吐量（其行为在资源饱和程度较高时可能变得高度非线性）。
尽管刚才说了：
- 这不是一个简单的公式
您需要假设新 UI 的效果是 3 倍的负载生成，除此之外（请求的服务需求相同，效率相同）
您正在冒遇到非建模可能瓶颈（例如饱和连接池、网络带宽等）问题的风险，这是容量规划的一般问题。
测试是唯一安全的选择，不幸的是，这种选择往往不可用。
I partly disagree with the previous answer.
For sure any capacity planning involves the creation of a model with a set of (potentially dangerous) assumptions.
Nontheless, having a good historical perspective of:
transactional load (e.g. web hits on Apache logs)
CPU and memory utilization
load-performance analyses can be built to determine the "Service Demand" (roughly speaking the amount of resources used to process a single request) through analytical statistical techniques.
The same parameter can then be fed into queuing network models to estimate expected response time and throughput (whose behaviour can become highly non-linear at high levels of resource saturation).
Despite what just said:
- it's no easy formula
you need to assume that the new UI's effect is 3X load generation and nothing else (same Service demand for a request, same efficiency)
you're taking the risk of experiencing issues with the non-modelled possible bottlenecks (e.g. saturated connection pools, network bandwidth, ...) which is a general problem of capacity planning.
Testing is the only safe option, unfortunately too often an option that is not available.