On 23 September 2010 08:13, Felix Frank <[email protected]> wrote: > On 09/22/2010 11:15 PM, Brian Devaney wrote: >> I have looked around the JMeter documents and elsewhere on the web to >> try and fid out if there is a limit to the number of threads available >> to JMeter. I have found claims of 1000 threads, 7000 threads and >> others, mainly depending on system resources. >> >> I am testing a web service and I start to run into problems at >> approximately 350 user threads. The main error I get is a connection >> refused message. To the best of my knowledge, the web service can >> handle the number of connections. I have set up several computers all >> hitting the web service and the total number of users was well over 600. >> I could have tried more, but I ran out of computers.
Connection refused normally means that the server has run out of connections. However, in some cases if the OS runs out of connections it can report a similar error. What is the *exact* error message? > It depends largely on your Test Plan. The more elements it contains, the > fewer threads can be run, since each thread has its own copy of the Test > Plan (or so I gathered). Not really. The test plan is turned into linked lists; most elements are cloned per thread, but some are not. But it is the run-time memory use that is most important. But in this case, it is not a lack of memory that is causing problems - it is lack of connections. Connections are limited by the OS, rather than Java or JMeter. > My first test plan consistently crashed Java on a machine with 3G max > heap space granted to Java, whenever I ran as much as 100 threads. Some elements consume a lot more memory than others. > Test Plans should adhere to > http://jakarta.apache.org/jmeter/usermanual/best-practices.html#lean_mean > as closely as possible, this will maximize your mileage wrt. thread numbers. > >> What sort of error is generated when JMeter no longer has the resources >> to work with more threads. JMeter will run 400 plus threads in one test >> group, but the aggregate report shows massive numbers of errors and if I >> look at the results in the Tree View, I see many Connection refused >> messages. Altering the Rampup time does not seem to improve things >> either. Thanks for your help. > > When Java runs out of memory, it will cease functioning and barf a > message about writing a heap dump or somesuch. This may take a while, > when your heap is large-ish (which it should be). > > Connection refused sounds like the problem was either on your server > side (which you ruled out already) or somewhere between the Jmeter > machine and the server (say, your OS underneath Java limiting the number > of open sockets or somesuch, but that should result in yet a different > exception). Yes, see above. > Maybe Jmeter produces more requests than your former test framework. Are > you using Timers? Good point. You should look at the load on your server to see if you are generating the desired number and mix of requests. > Have you tried distributed testing with Jmeter? You should at least try > with two worker nodes and find out if the maximum number of total > threads remains the same. > HTH, > Felix > > --------------------------------------------------------------------- > 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]
