You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Brian Devaney <bd...@docfinity.com> on 2010/09/22 23:15:27 UTC
What happens when the thread Limit in JMeter is reached?
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.
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.
--
Brian Devaney
DocFinity® by Optical Image Technology, Inc.
100 Oakwood Avenue, State College, PA 16803
ph: 814.238.0006 ext. 274
fax: 814.238.0011
mailto:bdevaney@DocFinity.com
http://www.docfinity.com/
DISCLAIMER: This email may contain proprietary information, some or all
of which may be legally privileged. It is for the intended recipient
only. If an addressing or transmission error has misdirected this email,
please notify the author by replying to this email. If you are not the
intended recipient, you may not use, disclose, distribute, copy, print,
or rely on this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: What happens when the thread Limit in JMeter is reached?
Posted by sebb <se...@gmail.com>.
On 23 September 2010 08:13, Felix Frank <ff...@mpexnet.de> 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: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: What happens when the thread Limit in JMeter is reached?
Posted by Felix Frank <ff...@mpexnet.de>.
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.
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).
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.
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).
Maybe Jmeter produces more requests than your former test framework. Are
you using Timers?
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: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org