On 24 June 2013 19:08, Robin D. Wilson <[email protected]> wrote: > 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.
For maximum performance, don't use the tree listener. Or, better, use non-GUI mode - the GUI parts of Listeners are deactivated. > 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:[email protected]] > 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 > <[email protected]>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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
