Finally I did the similar thing.. I create like 10 instances of Jmeter working un no-gui mode, and now is working, but I have to modify the PermSize of JMeter and adapt to my case, after executing Jconsole.
Thanks for the help, Toni. 2009/2/26 sebb <[email protected]> > On 26/02/2009, kirk <[email protected]> wrote: > > Oliver Erlewein [DATACOM] wrote: > > > > > Hi Toni, > > > > > > Just some things I’ve noticed with JMeter/Java... > > > > > > a) One JVM only supports 2000 concurrent TCP connections. Check your > > Time_wait states! > > > b) Using HTTPS I've determined that about 70 threads per JVM is about > the > > max you should do although I haven't investigated it into much detail. > Seems > > to be pretty independent of processing power. I don't know the value for > > HTTP. > > > > > > Because of such issues I've written my own distributed test harness for > > JMeter. What I basically do is start separate instances of JMeter and let > > them execute at predetermined times. What I've noticed though is, that > > although one JVM/JMeter client can't go above 70 threads I can run > multiple > > of these on one machine (P4HT 3Ghz). So far I've tried 3 concurrent. That > to > > me shows that the treading used by Java is not as efficient as the Linux > > threading/multitasking. > > The maximum number of threads will depend a lot on the test plan. Some > elements take much more memory that others. > > I've certainly used 200+ threads with just a Java Request sampler > without problems. > > When you say that 70 threads is the maximum, what is the limiting factor? > I.e. what happens when you add more threads? > > > > > > > > > I would suggest something other than Java's threading is involved. I've > > used 1000's of threads (limited by memory) in a Java application. In > fact, I > > had 250,000 open sockets from 4 machines talking to a single JVM for a > total > > of 1,000,000 socket connections all running on RH4 installs. I did *not* > use > > JMeter for this stress test as the application used Mina and Mina/JMeter > > don't seem to mix well. > > > > Regards, > > Kirk > > > > > > --------------------------------------------------------------------- > > 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] > >
