如何找到 IIS 在负载/性能测试期间模拟的平均并发用户数？
我正在使用 JMeter 进行负载测试。我正在练习通过简单地增加我的分布式 JMeter 测试用例中的线程数并启动测试来查找我们的网络服务器可以处理的最大并发线程（用户）数量。
然后，我突然意识到，虽然 MAX 数字可能有用，但我的网站平均实际处理的真实用户数量是我使测试取得成果所需的数量。
以下是有关我们设置的一些信息：
- 这是一个混合 .NET/Classic ASP 站点。登录后，将为用户创建一个浏览器会话（有超时）。
- 每个会话在 60 分钟后超时。
有没有办法使用这些信息、IIS 日志、性能计数器和/或一些计算来帮助我确定我们在生产站点上处理的平均并发用户数？
I'm using JMeter for load testing. I'm going through and exercise of finding the max number of concurrent threads (users) that our webserver can handle by simply increasing the # of threads in my distributed JMeter test case, and firing off the test.
Then -- it struck me, that while the MAX number may be useful, the REAL number of users that my website actually handles on average is the number I need to make the test fruitful.
Here are a few pieces of information about our setup:
- This is a mixed .NET/Classic ASP site. Upon login, a browser session (with timeout) is created in both for the users.
- Each session times out after 60 minutes.
Is there a way using this information, IIS logs, performance counters, and/or some calculation that will help me determine the average # of concurrent users we handle on our production site?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以将 logparser 与 QUANTIZE 函数结合使用来确定适当时间间隔内的请求峰值数。
对于 10 秒的窗口，它会类似于：
报告的计数不会与线程或用户完全相同，但它们应该帮助您指明正确的方向。
进行精确计数的最佳方法可能是使用性能计数器，但我不确定任何标准计数器是否能像您想要的那样工作——您可能需要创建一个自定义计数器。
You might use logparser with the QUANTIZE function to determine the peak number of requests over a suitable interval.
For a 10 second window, it would be something like:
The reported counts won't be exactly the same as threads or users, but they should help get you pointed in the right direction.
The best way to do exact counts is probably with performance counters, but I'm not sure any of the standard ones works like you would want -- you'd probably need to create a custom counter.
我可以在这里看到几个选项。
使用性能监视器获取当前数字或让它记录全天并获取平均值。 ASP.NET 有一个当前请求计数器。根据 此页面 经典 ASP 还具有请求当前数据，但我自己从未使用过。
通过日志解析器运行 IIS 日志以获取请求总数以及每个请求花费的时间。我认为，如果您知道每小时有多少个请求以及每个请求花费了多长时间，您就可以获得并发运行的平均数。
另外，请记住，并发用户与服务器上的并发线程并不完全相同。其一，在下载图像等内容时，每个用户将激活多个线程。之后，当服务器空闲时，用户将在页面上停留几分钟。
I can see a couple options here.
Use Performance Monitor to get the current numbers or have it log all day and get an average. ASP.NET has a Requests Current counter. According to this page Classic ASP also has a Requests current, but I've never used it myself.
Run the IIS logs through Log Parser to get the total number of requests and how long each took. I'm thinking that if you know how many requests come in each hour and how long each took, you can get an average of how many were running concurrently.
Also, keep in mind that concurrent users isn't quite the same as concurrent threads on the server. For one, multiple threads will be active per user while content like images is being downloaded. And after that the user will be on the page for a few minutes while the server is idle.
我的建议是您首先定义停止条件，例如
选择参数确实很主观，我个人无法提供太多经验。
其次，您可以查看性能计数器或 IIS 日志是否可以映射到参数。然后您设置正确的映射。
第三，您可以通过模拟N个用户（线程）开始测试，看看是否满足停止条件。如果没有命中，你可以去更高的数字。如果命中，您可以使用较小的数字。递归地你会找到一个粗略的数字。
然而，这并不意味着您的网站在现实世界中可以容纳这么多用户。到目前为止，还没有任何模拟可以涵盖所有边缘情况。
My suggestion is that you define the stop conditions first, such as
It is really subjective to choose the parameters and I personally cannot provide much experience on that.
Secondly you can see whether performance counters or IIS logs can map to the parameters. Then you set up proper mappings.
Thirdly you can start testing by simulating N users (threads) and see whether the stop conditions hit. If not hit, you can go to a higher number. If hit, you can use a smaller number. Recursively you will find a rough number.
However, that never means your web site in real world can take so many users. No simulation so far can cover all the edge cases.