线程和迭代次数如何影响测试以及 JMeter 的最大值是多少。线程限制
请告诉我最大限制。我可以在 JMeter 2.4 中用于进行负载测试的线程数？
-
在单个循环中采用所有线程或采用较少的否有什么区别吗？线程数和初始化循环以实现相同的数量。用户/线程数？
例如：
No. of threads=500
Ramp up=1000
Loop=1
是否相同或有差异？
No. of threads=50
Ramp up=100
Loop=10
结果
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
最大线程数由很多因素决定，请参阅此答案https://stackoverflow.com/a/11922239 /460802
您的提议有很大差异。
理论上，您会得到相同数量的结果 (500)，但您以非常不同的方式访问服务器。
The max number of threads is determined by a lot of factors, see this answer https://stackoverflow.com/a/11922239/460802
There is a big difference in what you are proposing.
In theory you get the same number of results (500), but you are hitting the server in a very different manner.
最大用户数取决于您的操作系统、可用 RAM 和连接。 Win XP 限制同时运行 3000 个进程。在Linux上是超过3000，但我不知道是多少。测试服务器时要小心，如果在机器上启动 3000 个线程，则需要大量资源，并且测试不会是真实的。我更喜欢每台机器启动最多 300 个用户。如果您想增加用户数量，请使用分布式测试（使用更多机器作为 DoS 攻击）。
理论上是相同数量的请求但是时间复杂度不一样。
Maximum number of users depends of your OS,free RAM and connection. Win XP is limited to 3000 processes at the same time. On Linux is more than 3000 but I don't how much. Be careful that you test server and if you start 3000 thread on your machine require a lot of resources and the test will not be real. I prefer to start maximum 300 users per machine. If you want to increase the number of users then use distributed testing (use more machine as DoS attack).
In theory is the same number of request but the time complexity is not the same.
1：当然，这在很大程度上取决于运行 JMeter 的机器，但如果里程数很重要，我可以给你一些提示。 JMeter 允许您在同一个框中运行多个进程，并且通常非常可靠地为每个 JMeter 实例生成最多 200 个线程。如果您需要更多，我建议使用多个 JMeter 实例。现代机器经过一些调整可以轻松生成 500 到 1000 个线程。使用 Linux，您可能需要增加文件描述符的最大数量 (请参阅此处）。
在没有 GUI 的情况下运行 JMeter，将报告/图形数据写入稍后渲染的文件中，这很有帮助。您还必须注意网络限制。 Gbps 网络中的服务器很容易生成数千个请求，但共享 54 Mbps 路由器的笔记本电脑会受到更多限制。尝试将您与服务器的实际连接除以请求的大小，然后您就会知道带宽是否会限制您。请特别注意 JMeter 的配置，以下载或不下载 HTML 响应中引用的文件。
希望我能提供帮助。
2：这正是 BlackGaff 的解释：
“500 个线程，循环 1”表示 500 个线程同时执行一次循环。
“50 个线程，循环 10”意味着只有 50 个线程同时执行循环 10 次。
1: Of course it depends a lot on the machine running JMeter, but if mileage counts I can give you some hints. JMeter allows you to run multiple processes in the same box, and it's usually pretty reliable generating up to 200 threads per JMeter instance. If you need more than that, I'd recommend using multiple JMeter instances. A modern machine with some tweaking can easily generate 500 to 1000 threads. Using Linux you probably need to increase the max number of file descriptors (see here).
It helps a lot to run JMeter without a GUI, writing report/graphics data in a file to be rendered later. You must also pay attention to your networking limitations. It'd be easy for a server within a Gbps network to generate some thousands of requests, but a laptop sharing a 54 Mbps router would be much more limited. Try to divide your actual connection to the server by the size of the requests, and then you'll know if bandwidth will limit you. Pay special attention to JMeter's configuration to download or not the files referenced in an HTML response.
Hope I was able to help.
2: It's precisely what BlackGaff explained:
"500 threads, Loop 1 " Means 500 threads AT THE SAME TIME doing the loop ONCE.
"50 threads, loop 10" Means only 50 threads AT THE SAME TIME doing the loop TEN TIMES.
在创建场景和测试用例后，这很常见，我们需要使用 JMeter 运行，并且必须修复 JMeter 线程组中允许使用多少用户或线程的值。我们不想限制我们的负载生成器或 JMeter 实例。所以基本上，在这两种情况下都需要调整。否则，测试的输出将毫无价值，我们将损失几个小时的时间我们的时间。因此，我们需要考虑以下事项： -
这意味着默认分配的堆大小最小为 512MB，最大为 512MB。根据您自己的 PC 配置进行配置。请记住，操作系统也需要一定量的内存，因此不要分配所有物理 RAM。
这意味着内存将以这个速度增加。您应该小心，因为，如果您的负载生成在开始时非常高，则可能需要增加。请记住，如果范围太宽，它将导致 JVM 内的堆空间碎片化。如果是这样，垃圾收集器需要更加努力地进行清理。
JMeter 是 Java GUI 应用程序。它还具有资源密集程度较低（CPU/RAM）的非 GUI 版本。如果我们在非GUI模式下运行JMeter，它将消耗更少的资源，并且我们可以运行更多的线程。
禁用所有侦听器：在测试运行期间。它们仅用于调试并使用它们来设计您所需的脚本。
在负载测试期间应禁用侦听器。启用它们会导致额外的开销，从而消耗测试中更重要的元素所需的宝贵资源。
始终尝试使用最新软件。保持 Java 和 JMeter 更新。
不要忘记，在存储请求和响应标头时，断言结果和响应数据可能会消耗大量内存！因此，除非绝对必要，否则尽量不要将这些值存储在 JMeter 上。
总而言之，如果 JMeter 脚本中没有包含监听器，运行中的 JMeter 服务器内部没有监控，网络开销/障碍和 JMeter 脚本得到优化，那么这里是一个粗略的计算：
您必须估计并发用户/线程数（活动线程） 仅根据您的负载场景。
此外，您还需要监控您的服务器
内存消耗、CPU 使用率是否运行低于 80%或不。如果这些使用率超过 80%，则认为这些测试与报告一样不可靠。为了更好、更详细地理解这两个博客如何许多用户JMeter可以支持？和针对 JMeter 负载测试“内存不足”失败的 9 个简单解决方案一定会有所帮助。
This is very common to stuck here after creating a scenario and test cases, we need to run using JMeter and we have to fix the value of how many users or threads are allowed to use in JMeter Thread Group. We don't want to throttle either our Load generator or our JMeter instance.So basically, it is needed tweaking in both cases.Otherwise, The output of the test will be worthless and we will lose hours of our time. So here are the things we need to consider:-
It means default allocated heap size is minimum 512MB, maximum 512MB. Configure it as per your own PC configuration. Keep in mind, OS also need some amount of memory, so don't allocate all of you physical RAM.
This means memory will be increased at this rate. You should be careful, because, if your load generation is very high at the beginning, this might need to increase. Keep in mind, it will fragment your heap space inside JVM if the range too broad. If so, Garbage Collector needs to work harder to clean up.
JMeter is Java GUI application. It also has the non-GUI edition which is less resource intensive (CPU/RAM). If we run JMeter in non-GUI mode, it will consume less resource and we can run more thread.
Disable ALL Listeners: During the Test Run. They are only for debugging and use them to design your desired script.
Listeners should be disabled during load tests. Enabling them causes additional overheads, which consume valuable resources that are needed by more important elements of your test.
Always try to use the Up-to-date software. Keep your Java and JMeter updated.
Don’t forget that when it comes to storing requests and response headers, assertion results and response data can consume a lot of memory! So try not to store these values on JMeter unless it’s absolutely necessary.
So in summary, if no Listeners are included in JMeter script, no monitoring inside running JMeter server, network overhead/barriers and JMeter scripts are optimized then here is a rough calculation:
You have to estimate your concurrent number user/thread (active threads) only in terms of your load scenario.
Also, you need to monitor whether your servers
Memory consumption,CPU usagesare running below 80 % or not. If these usages exceed 80 % consider those tests as unreliable as a report.For better and more elaborate understanding these two blogs How many users JMeter can support? and 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure must help.
Jmeter中的线程执行没有限制。由于它是一个基于 java 的工具，因此它使用 java 线程功能。在并发线程执行的情况下，我们需要注意机器配置（即内存大小和 CPU）。为了避免
OutOfMemory问题，请尝试在NON-GUI模式下运行jmeter，并在jmeter脚本中使用自定义 java 运行时参数apache-jmeter/bin/jmeter 。默认值为 512 MB。
There is no limit on Thread execution in
Jmeter. Since its a java based tool, it uses java thread capabilities. In case of concurrent thread execution we need to taken care of machine configuration (ie. Memory size and CPU).To avoid
OutOfMemoryissue try to runjmeterinNON-GUImode with custom java runtime arguments injmeterscript insideapache-jmeter/bin/jmeter.Default is 512 MB.
如果你的机器可以处理的话，我认为 JMeter 本身没有任何线程限制。测试的基本思想应该是，线程的切换和等待时间不应该对实际的性能指标影响太大。
两种情况之间存在巨大差异。在第一种情况（最坏的情况）中，您将有 500 个并发用户。在第二种情况下，最大并发用户数将为 50。场景 1 的平均时间将大于场景 2 的平均时间。
I don't think there is any thread limit on JMeter itself if your machine can handle it. The basic idea of testing should be that, the switching of thread and waiting time should not affect the actual performance metrics too much.
There is huge difference between the two cases. In the first case, worst scenario, you will have 500 concurrent users. In the second case, the max number of concurrent users will be 50. The average time for scenario 1 will be larger than the average time for scenario 2.