You also need to evaluate _all_ of the potential bottlenecks when running multiple threads from the same machine. For example, the network interface - if you are requesting pages that return 1MB of data, and you try to do 1000 threads - it is unlikely that your load-generating system can handle 1GB of data from each simultaneous page as easily as say 10 machines can handle 100MB each. (Of course, then you have to look at the test servers - to make sure that they are not similarly bottlenecked.
Likewise, if your threads do a lot of pre and post processing (essentially parsing the data that comes back from the servers) and have a lot listeners, can your client machine really handle that amount of workload "times 1000"? It is unlikely unless you have the most basic of request/response values, and parsing rules. One example would be the 'tree listener'... If you are recording every response in the tree listener, it will eventually run your machine out of memory. Not only that, but before it runs you out of memory - it will dramatically slow down your test. So in our tests, we only use the 'tree listener' for recording errors. But even with just that, there is still a measurable difference in performance when it is enabled versus disabled. I run our load from 4 different load-generator machines (all running JMeter), each with Core i7 processors, and 8GB of RAM. We never run more than 200 threads simultaneously (50 per box) - simply because we've found that when we ramp up the testing clients beyond that level, the slowdown comes from the clients - not the servers. But then our tests are pretty involved, with lots of pre/post processors and assertions. What you want to look for is how do you generate sufficient load on the servers - and how many load-generating clients are required for that. You can try 1000 threads on a single client, but you look at the load on the servers and see it nowhere near capacity, and then you look at the load on the load-generating client and see it maxed out in CPU, Memory, I/O, (any single one will block it from generating more load), then you need to lower the number of simultaneous threads on that client until you see the best mix of performance from the client vs. capacity on the server. Then you can add more clients to meet your goal of 1000 simultaneous threads hitting the server. -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 http://www.kingsisle.com -----Original Message----- From: Deepak Shetty [mailto:shet...@gmail.com] Sent: Monday, June 24, 2013 12:05 PM To: JMeter Users List Subject: Re: System configuration you could probably get it to work , but I doubt your results would be accurate. (i.e. you can run more threads but it might not simulate the same load as if you had as many machines as threads) Usually with a windows client class machine , dont exceed 100-200 threads unless your tests have large wait times In most cases you have to try it out and see and measure - both your client machine and your server since answers to questions like yours are too heavily dependent on environment and script. On Mon, Jun 24, 2013 at 2:36 AM, Saranya C <saran...@maveric-systems.com>wrote: > Hi All, > > I would like to know the system configuration details to run 1000 > threads in jmeter. > > Physical memory: 2GB > OS: Windows XP > JVM: 1.7 > Jmeter: 2.9 > > Will the above specification workout? > > Thanks and regards, > Saranya C > ====================================================================== > ====================================================================== > ================== > Disclaimer: This message is intended only for the individual or entity > to which it is addressed. It may contain privileged, confidential > information which is exempt from disclosure under applicable laws. If > you are not the intended recipient, please note that you are strictly > prohibited from disseminating or distributing this information (other > than to the intended > recipient) or copying this information. If you have received this > communication in error, please notify us immediately by return email. > ====================================================================== > ====================================================================== > ================== > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
