What is the highest number of threads that is reas

问题:

I want to use the highest possible number of threads (to use less computers) but without making the bottleneck to be in the client.

回答1:

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.

Outdated answer since at least version 2.6 see https://stackoverflow.com/a/11922239/460802 for a more up to date one.

回答2:

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:

• Remote Testing > 15.4 Using a different sample sender

And finally use cloud based testing if it's not enough.

Read this for tuning tips:

• http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/

Read this book for doing load testing and using JMeter correctly.

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

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

回答7:

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..

回答8:

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%.

回答9:

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.