如何解释 Siege 和/或 Apache Bench 结果
我们有一个 MySQL 驱动的网站，偶尔会在 48 小时内吸引 10 万用户，所有用户都登录该网站并进行购买。
我们正在尝试使用 Apache Bench 和 Siege 等工具来模拟这种负载。
虽然在我看来关键指标是并发用户数，并且我们已经得到了报告结果，但我们仍然感觉自己一无所知。
我想问的是：我们应该测试哪些东西来预测这种流量？
50个并发用户1000次？ 500个并发用户10次？
我们正在研究数据库错误、apache 超时和响应时间。我们还应该关注什么？
这是一个模糊的问题，我知道没有“正确”的答案，我们只是在寻找一些关于如何确定我们的基础设施可以实际处理的一般想法。
提前致谢！
We have a MySQL driven site that will occasionally get 100K users in the space of 48 hours, all logging into the site and making purchases.
We are attempting to simulate this kind of load using tools like Apache Bench and Siege.
While the key metric seems to me number of concurrent users, and we've got our report results, we still feel like we're in the dark.
What I want to ask is: What kinds of things should we be testing to anticipate this kind of traffic?
50 concurrent users 1000 Times? 500 concurrent users 10 times?
We're looking at DB errors, apache timeouts, and response times. What else should we be looking at?
This is a vague question and I know there is no "right" answer, we're just looking for some general thoughts on how to determine what our infrastructure can realistically handle.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
同时用户无疑是关键因素之一 - 特别是适用于数据库连接池等。但您还需要验证测试的页面速率（页/秒）是否也在您期望的范围内。如果测试用例中的思考时间相差很多，您可能会意外地模拟比实际流量高（或低）得多的页面速率。思考时间是用户在页面请求之间花费的时间 - 阅读页面、填写表单等。
根据您手头的其他信息，这可能会帮助您计算要模拟的并发用户数量：
虚拟用户计算器
最终用户看到的完整页面加载时间通常是最长的评估系统性能的重要指标。您还需要查看所有交易的失败率。您还应该留意从未完成的交易。一些测试工具不能很好地报告这些情况，当服务器没有响应时，允许模拟用户无限期挂起......并且不报告这种情况。寻找能够报告在给定页面或事务上等待的用户数量以及这些用户等待的平均时间的工具。
至于要寻找的服务器端指标，您的应用程序还基于哪些其他技术构建？您需要了解 .NET 应用程序与 PHP 应用程序的不同之处。
最后，我们发现查看系统如何响应不断增加的负载非常有价值，而不是仅查看单个负载级别。 本文更详细的内容。
Simultaneous users is certainly one of the key factors - especially as that applies to DB connection pools, etc. But you will also want to verify that the page rate (pages/sec) of your tests is also in the range you expect. If the the think-time in your testcases is off by much, you can accidentally simulate a much higher (or lower) page rate than your real-world traffic. Think time is the amount of time the user spends between page requests - reading the page, filling out a form, etc.
Depending on what other information you have on hand, this might help you calculate the number of simultaneous users to simulate:
Virtual User Calculators
The complete page load time seen by the end-user is usually the most important metric to evaluate system performance. You'll also want to look for failure rates on all transactions. You should also be on the lookout for transactions that never complete. Some testing tools do not report these very well, allowing simulated users to hang indefinitely when the server doesn't respond...and not reporting this condition. Look for tools that report the number of users waiting on a given page or transaction and the average amount of time those users are waiting.
As for the server-side metrics to look for, what other technologies is your app built on? You'll want to look at different things for a .NET app vs. a PHP app.
Lastly, we have found it very valuable to look at how the system responds to increasing load, rather than looking at just a single level of load. This article goes into more detail.
理想情况下，您需要对用户的使用情况进行建模，但为 10 万用户创建模拟并发会话通常并不容易完成。
最好的来源是检查最繁忙时间的日志，并尝试找出一种对负载级别进行建模的方法。
数据库通常是基础设施的关键部分，因此我会考虑记录锁定等待的数量和长度以及数据库语句的数量和持续时间。
另一个需要关注的关键项目是磁盘队列长度。
大多数情况下，这个过程是在整个网站或特定页面中寻找缓慢的响应，然后找出原因。
负载测试的最大问题是测试您的网络非常困难，并且如果您（像大多数公共站点一样）通过 ISP 的带宽有限，则可能会产生负载测试中未反映出来的性能问题。
Ideally you are going to want to model your usage to the user, but creating simulated concurrent sessions for 100k users is usually not easily accomplished.
The best source would be to check out your logs for the busiest hour and try and figure out a way to model that load level.
The database is usually a critical piece of infrastructure, so I would look at recording the number and length of lock waits as well as the number and duration of db statements.
Another key item to look at is disk queue lengths.
Mostly the process is to look for slow responses either in across the whole site or for specific pages and then hone in on the cause.
The biggest problem for load testing is that is quite hard to test your network and if you have (as most public sites do) a limited bandwidth through your ISP, that may create a performance issue that is not reflected in the load tests.