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]
