Jmeter 中合理同时运行的最大线程数是多少？
我想使用尽可能多的线程（以使用更少的计算机），但又不让瓶颈出现在客户端。
I want to use the highest possible number of threads (to use less computers) but without making the bottleneck to be in the client.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
只要使用得当，JMeter 就可以模拟非常高的负载。
不要听城市传奇说JMeter 无法处理高负载。
现在至于答案，它取决于：
您的机器功率
您的jvm 32位或64位
您的jvm分配的内存-Xmx
你的测试计划（很多beanshell，后处理器，xpath ...意味着很多cpu）
你的操作系统配置（可调）
Gui /非gui模式
所以没有理论依据回答但遵循最佳实践将确保JMeter表现良好。
请注意，使用 jmeter，您可以通过远程测试分配负载，请阅读：
如果还不够，最后使用基于云的测试。
阅读本文以了解调整技巧：
阅读这本书来进行负载测试并正确使用JMeter。
JMeter can simulate a very High Load provided you use it right.
Don't listen to Urban Legends that say JMeter cannot handle high load.
Now as for answer, it depends on:
your machine power
your jvm 32 bits or 64 bits
your jvm allocated memory -Xmx
your test plan ( lot of beanshell, post processor, xpath ... Means lots of cpu)
your os configuration (tunable)
Gui / non gui mode
So there is no theorical answer but following Best Practices will ensure JMeter performs well.
Note that with jmeter you can distribute load through remote testing, read:
And finally use cloud based testing if it's not enough.
Read this for tuning tips:
Read this book for doing load testing and using JMeter correctly.
我使用过 JMeter 相当多，发现它在生成真正高负载方面效果不佳。 在具有 2Gb 内存的 2Ghz Core2 Duo 上，您可以合理地预期大约有 100 个线程。
话虽这么说，最好在您的硬件上运行它，这样 PC 的 CPU 不会达到 100% 的峰值 - 稳定的 80%-90% 最好，否则结果会受到影响。
我还尝试过 WAPT 5 - 它成功地从同一台 PC 运行了 1000 多个线程。 它不是免费的，但比 JMeter 更有用，但不具备所有功能。
I have used JMeter a fair bit and found it is not great at generating really high load. On a 2Ghz Core2 Duo with 2Gb memory you can reasonably expect about 100 threads.
That being said, it is best to run it on your hardware so that the CPU of the PC does not peak at 100% - a stable 80%-90% is best otherwise the results are affected.
I have also tried WAPT 5 - it successfully ran 1000+ threads from the same PC. It is not free but it is more useable than JMeter but doesn't have all of the features.
JMeter Wiki 报告了 JMeter 使用多达 1000 个线程的情况。 我最多使用了 100 个线程，但 Wiki 中的链接建议我从未尝试过减少资源。
The JMeter Wiki reports cases where JMeter was used with as much as 1000 threads. I have used it with at most 100 threads, but the Links in the Wiki suggest resource reductions I never tried.
我们在 Windows XP 上运行 JMeter 时遇到的问题之一是 Windows XP TCP 连接限制。 为了发挥 JMeter 工作站的全部潜力，应消除限制
更多信息此处< /a>. AFAIK，不适用于其他操作系统。
One of the issues we had with running JMeter on Windows XP was the Windows XP TCP Connection Limit. Limit should be removed in order to run use the JMeter to workstation’s full potential
More info here. AFAIK, does not apply to other OS.
我从 2004 年开始使用 JMeter，并启动了很多负载测试。
配备 PC Windows 7 64 位 4Go RAM iCore5。
我认为 JMeter 可以支持 Http (Sampler) 协议的 300 到 400 并发线程，只需一个在日志文件结果中写入的“聚合报告侦听器”和调用页面之间的计时器 。
对于大负载测试，您可以像这样使用从站（负载生成器）配置 JMeter
http://jmeter-plugins.org/wiki/HttpSimpleTableServer/
我已经完成了测试11个PC从机模拟5000个线程。
I used JMeter since 2004 and i launched lot of load tests.
With PC Windows 7 64 bits 4Go RAM iCore5.
I think JMeter can support 300 to 400 concurrent threads for Http (Sampler) protocol with only one "Aggregate Report Listener" who writes in the log file results and timers between call pages.
For a big load test you could configure JMeter with slaves (load generators) like this
http://jmeter-plugins.org/wiki/HttpSimpleTableServer/
I have already done tests with 11 PC slaves to simulate 5000 threads.
我没有使用过 JMeter，但答案可能取决于您的硬件。 最好的办法可能是建立性能指标，猜测线程数，然后按如下方式运行二分搜索。
来源是维基百科。
猜数字游戏...
这个相当简单的游戏开始于“我正在考虑四十到六十之间的整数，对于你的猜测，我会回答‘高’、‘低’或‘是！’ 情况可能就是这样。” 假设 N 是可能值的数量（这里，“包含”二十一个），则最多需要问题来确定该数量，因为每个问题将搜索空间减半。 请注意，与一般算法相比，需要少一个问题（迭代），因为数量已被限制在特定范围内。
即使我们猜测的数字可以是任意大，在这种情况下没有上限 N，我们仍然可以通过首先找到上限来在最多步骤中找到该数字（其中 k 是（未知）选定的数字）通过重复加倍。 例如，如果数字是 11，我们可以使用以下猜测序列来找到它： 1, 2, 4, 8, 16, 12, 10, 11
还可以扩展该技术以包括负数； 例如，可以使用以下猜测来找到−13：0、−1、−2、−4、−8、−16、−12、−14、−13
I have not used JMeter, but the answer probably depends on your hardware. Best bet might be to establish metrics of performance, guess at the number of threads and then run a binary search as follows.
Source was Wikipedia.
Number guessing game...
This rather simple game begins something like "I'm thinking of an integer between forty and sixty inclusive, and to your guesses I'll respond 'High', 'Low', or 'Yes!' as might be the case." Supposing that N is the number of possible values (here, twenty-one as "inclusive" was stated), then at most questions are required to determine the number, since each question halves the search space. Note that one less question (iteration) is required than for the general algorithm, since the number is already constrained to be within a particular range.
Even if the number we're guessing can be arbitrarily large, in which case there is no upper bound N, we can still find the number in at most steps (where k is the (unknown) selected number) by first finding an upper bound by repeated doubling. For example, if the number were 11, we could use the following sequence of guesses to find it: 1, 2, 4, 8, 16, 12, 10, 11
One could also extend the technique to include negative numbers; for example the following guesses could be used to find −13: 0, −1, −2, −4, −8, −16, −12, −14, −13
它更依赖于您在特定服务器上进行的性能测试类型（负载、峰值、耐力等）（有点依赖于硬件）
请记住这些参数
- 您要运行jmeter的客户端计算机，将分配一定量的堆内存，确保有一个健康的分配，以便脚本不会出错。 我在本地环境（客户端-服务器架构）上在 jmeter 上运行的最高速度是 1500，在 Web 架构上，我运行的最高速度是基于非功能性要求限制为 250 个线程，
因此理想情况下它取决于各种性能测试和部署方式等等。
It is more dependent on the kind of performance testing you do(load, spike, endurance etc) on a specific server (a little on hardware dependency)
Keep in mind around these parameters
- the client machine on which you are targeting the run of jmeter, there will be a certain amount of heap memory allocated, ensure to have a healthy allocation so that the script does not error out. The highest i had run on jmeter was 1500 on a local environment ( client - server arch), On a Web arch, the highest i had a run was based upon Non- functional requirement were limited to 250 threads,
so it ideally depends on the kinds of performance testing and deployment style and so on..
对此没有标准数字。 一台计算机可以生成的最大线程数完全取决于计算机的硬件和操作系统。 操作系统默认占用一定量的CPU和RAM。
要找出计算机可以处理的最大线程数，您可以准备一个示例测试并仅使用几个线程运行它。 然后，随着测试运行的每个周期逐渐增加线程数量。 在此期间，您还需要监控计算机的 CPU、RAM、磁盘 I/O 和网络 I/O。 当其中任何一个达到接近或超过 80% 时（再次由您决定接近或超过），这就是您的计算机可以处理的最大线程数。 为了安全起见，我会在资源利用率达到 70% 时停止。
There is not standard number for this. The maximum number of threads that you can generate from one computer depends completely on the computer's hardware and the OS. The OS by default occupies certain amount of CPU and the RAM.
To find out the maximum threads your computer can handle you can prepare a sample test and run it with only a few threads. Then with each cycle of test run increase the number of threads gradually. During this you also need to monitor the CPU, RAM, Disk I/O and Network I/O of your computer. The moment any of these reach near or beyond 80% (Again for you to decide if near is okay for you or beyond), that is the maximum number of threads your computer can handle. To be on the safer side I would stop at the number when the resource utilization reaches 70%.
这取决于您运行的硬件以及底层脚本。 我一直觉得这种模糊性是传统负载测试工具的最大问题。 如果您的预算较少（200 美元左右即可进行大量测试），请查看我公司的负载测试服务，浏览器Mob。
除了出于性能和负载测试目的控制数千个实际浏览器的真实浏览器用户 (RBU) 之外，我们还有传统的虚拟用户 (VU)。 脚本是用 JavaScript 编写的，可以进行各种 HTTP 调用。
我提出这个问题的原因是，我总觉得试图弄清楚负载生成硬件上可以安装多少个 VU 的游戏是危险的。 很容易在没有意识到的情况下得到不好的结果。
为了解决 BrowserMob 的这个问题，我们对每个 CPU 核心的 VU 和 RBU 数量采取了极其保守的方法：每个 CPU 核心不超过 1 个浏览器或 50 个线程，有时甚至更少。 在云计算领域，CPU 周期非常便宜，以至于尝试使机器超载是没有意义的。
It'll depend on the hardware you run on as well as the underlying script. I've always felt that this fuzziness is the biggest problem with traditional load testing tools. If you've got a small budget ($200 or so gets you a LOT of testing), check out my company's load testing service, BrowserMob.
Besides our Real Browser Users (RBUs) which control thousands on actual browsers for the purpose of performance and load testing, we also have traditional virtual users (VUs). Scripts are written in JavaScript and can make various HTTP calls.
The reason I bring it up is that I always felt that the game of trying to figure out how many VUs you can fit on your load gen hardware is dangerous. It's so easy to get bad results without realizing it.
To solve that for BrowserMob, we took an extremely conservative approach on the number of VUs and RBUs per CPU core: no more than 1 browser or 50 threads per CPU core, and sometimes much less. In the world of cloud computing, CPU cycles are so cheap that it just doesn't make sense to try to overload machines.