使用 Visual Studio 2008 进行负载测试：分析结果时遇到问题
我使用 Visual Studio Team System 2008 Team Suite 对我的 Web 应用程序进行负载测试（它使用 ASP.MVC 技术）。
负载模式：恒定（这意味着我始终拥有恒定数量的虚拟用户）。 我指定 1000 个用户的配置来分析我的 Web 应用程序在真正压力条件下的性能。我多次运行相同的负载测试，同时在我的应用程序中进行一些更改。
但是在分析负载测试结果时，我遇到了一个奇怪的依赖关系：当平均页面响应时间变大时，每秒请求数值也会增加！反之亦然：当平均页面响应时间较短时，每秒请求数值也会减少。这种情况当用户量较小（5-50个用户）时不会重现。
您如何解释这样的结果？
I use Visual Studio Team System 2008 Team Suite for load testing of my Web-application (it uses ASP.MVC technology).
Load pattern:Constant (this means I have constant amount of virtual users all the time).
I specify coniguratiton of 1000 users to analyze perfomance of my Web-application in really stress conditions.I run the same load test multiple times while making some changes in my application.
But while analyzing load test results I come to a strange dependency: when average page response time becomes larger,the requests per second value increases too!And vice versa:when average page response time is less,requests per second value is less.This situation does not reproduce when the amount of users is small (5-50 users).
How can you explain such results?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
也许这里对“请求/秒”一词存在误解。 根据我的理解，请求/秒只是表示测试向应用程序推送的请求数量（而不是每秒完成的请求数量）。
如果你这样看的话。 这可能有道理。
高请求/秒将导致更高的平均。 响应时间（由于某处的瓶颈，即 CPU 限制、内存限制或 IO 限制）。
因此，当您的每秒请求数增加，并且内存中有大量对象时，内存就会面临压力，从而触发垃圾收集，从而减慢您的响应时间。
或者，当您的每秒请求数增加时，您的 CPU 就会受到重创，您可能必须等待 CPU 时间，从而使您的响应时间更长。
或者当你的Request/Sec上升时，你的SQL没有正确调整，并且发生阻塞和死锁，从而使你的响应时间更高。
这些只是您可能会看到这些相关性的原因的示例。 您可能需要根据 CPU、内存使用情况和 IO（网络、磁盘、SQL 等）进行更多跟踪。
Perhaps there is a misunderstanding on the term Requests/Sec here. Requests/Sec as per my understanding is just a representation of how any number of requests that the test is pushing into the application (not the number of requests completed per second).
If you look at it that way. This might make sense.
High Requests/Sec will cause higher Avg. Response Time (due to bottleneck somewhere, i.e. CPU bound, memory bound or IO bound).
So as your Requests/Sec goes up, and you have tons of object in memory, the memory is under pressure, thus triggering the Garbage Collection that will slow down your Response time.
Or as your Requests/Sec goes up, and your CPU got hammered, you might have to wait for CPU time, thus making your Response Time higher.
Or as your Request/Sec goes up, your SQL is not tuned properly, and blocking and deadlocking occurs, thus making your Response Time higher.
These are just examples of why you might see these correlation. You might have to track it down some more in term of CPU, Memory usage and IO (network, disk, SQL, etc.)
有关该问题的更多详细信息：我们正在针对标准 ASP.NET aspx 对渲染引擎 [NDjango][1] 进行负载测试。 我们用来加载测试的 Web 应用程序非常基本 - 它由 2 个静态页面组成 - 没有数据库，没有繁重的处理，只是渲染。 我们看到的是，就平均响应时间而言，aspx 比预期要快得多，但令我惊讶的是，每秒的请求数以及测试期间的请求总数要低得多。
抛开我们正在测试的内容不谈，我同意吉米的观点，较高的请求率会在很多方面阻塞服务器。 但据我了解，这会导致响应时间增加 - 对吧？
如果我们得到的数字确实反映了服务器上发生的情况，我不知道如何打破这个规则。 因此，目前我唯一的解释是数字存在偏差——我们配置工具的方式出了问题。
[1]: http://www.ndjango.org NDjango
A few more details about the problem: we are load testing our rendering engine [NDjango][1] against the standard ASP.NET aspx. The web app we are using to load test is very basic - it consists of 2 static pages - no database, no heavy processing, just rendering. What we see is that in terms of avg response time aspx as expected is considerably faster, but to my surprise the number of requests per second as well as total number of requests for the duration of the test is much lower.
Leaving aside what we are testing against what, I agree with Jimmy, that higher request rate can clog the server in many ways. But it is my understanding that this would cause the response time to go up - right?
If the numbers we are getting really reflect what's happening on the server, I do not see how this rule can be broken. So for now the only explanation I have is that the numbers are skewed - something is wrong with the way we are configuring the tool.
[1]: http://www.ndjango.org NDjango
这是正常结果，因为用户数量增加，您每秒将向服务器加载更高数量的请求。 任何服务器每秒处理更多请求都需要更长的时间，这意味着平均页面响应时间会增加。
每秒请求数是应用程序负载的衡量标准，平均页面响应时间是应用程序性能的衡量标准，其中数字高=响应慢。
最好使用阶梯式的用户数量或预热期，将负载逐渐施加到服务器上。
另外，单台测试机上有 1000 个虚拟用户，测试机的 CPU 绝对会被最大化。 这很可能是导致测试结果出现偏差的原因。 考虑虚拟用户的数量，您会发现每秒的请求数会达到最大值。 添加或删除虚拟用户将导致应用程序每秒的请求减少。
This is a normal result as the number of users increases you will load the server with higher numbers of requests per second. Any server will take longer to deal with more requests per second, meaning the average page response time increases.
Requests per second is a measure of the load being applied to the application and average page response time is a measure of the applications performance where high number=slow response.
You will be better off using a stepped number of users or a warmup period where the load is applied gradually to the server.
Also, with 1000 virtual users on a single test machine, the CPU of the test machine will be absolutely maxed out. That will most likely be the thing that is skewing the results of your testing. Playing with the number of virtual users you will find that there will be a point where the requests per second are maxed out. Adding or taking away virtual users will result in less requests per second from the app.