You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Naresh Kumar <na...@igatepatni.com> on 2012/03/01 11:46:34 UTC
J Meter fails when thread count is increased.
Hi,
We are performing load testing on the web services, below is structure of our test plan.
Ø Thread Group
Ø Webservice SOAP Request
Ø View Results in Table
Ø View Results Tree
Ø HTTP Authorization Manager
We get below error when we try to run 6000 threads in 1 min ramp up time.
Error Message : java.lang.OutOfMemoryError:unable to create new native thread' and the test stops.
After increasing heap size also we are getting 'ERROR - jmeter.JMeter: Uncaught exception:
Also what is the max threads J meter can support from single machine, we have plan to run 54000 threads in 1 hour
Is there a workaround possible.
Please help !
Regard's
Kumar
________________________________
Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com.
RE: J Meter fails when thread count is increased.
Posted by ZK <st...@gmail.com>.
Hi,
take a look here:
http://code.google.com/p/jmeter-plugins/wiki/PerfMon
http://code.google.com/p/jmeter-plugins/wiki/PerfMon
ZK
--
View this message in context: http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5530742.html
Sent from the JMeter - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
RE: J Meter fails when thread count is increased.
Posted by Naresh Kumar <na...@igatepatni.com>.
Is there any specific listener I can use to check ' monitor cpu, memory and network usage; and also jvm cpu, heap,
gc usage '
In general how can I check the resource/hardware utilization both at J meter & Server level, is this possible through listners.
Regard's
Kumar
-----Original Message-----
From: Flavio Cysne [mailto:flaviocysne@gmail.com]
Sent: 02 March 2012 11:25
To: JMeter Users List
Subject: Re: J Meter fails when thread count is increased.
If you can monitor cpu, memory and network usage; and also jvm cpu, heap,
gc usage would be nice to see the results and know if your box can hold
these load. It could be used as a parameter of future tests of members of
this list.
Regards.
Flavio Cysne.
2012/3/1 Naresh Kumar <na...@igatepatni.com>
> Thanks , distributed load testing seems to work.
> Will revert in case of issues.
>
> Between if I use 10 mcahines and use 1000 threads on each machines , will
> this impact on the test results.
> Can someone please confirm.
>
> Regard's
> Kumar
>
> -----Original Message-----
> From: Flavio Cysne [mailto:flaviocysne@gmail.com]
> Sent: 01 March 2012 16:38
> To: JMeter Users List
> Subject: Re: J Meter fails when thread count is increased.
>
> We used to execute distributed testing using JMeter agent (jmeter -s)
> loading almost 400 threads each. On that case we were using HEAP
> with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
> 3GB RAM box.
>
> Keep in mind that for better results the cpu/memory usage don't be higher
> than 80%. It can cause anomalies to test results in some cases.
>
> Hope it helps you.
> Flávio Cysne
>
> 2012/3/1 ZK <st...@gmail.com>
>
> > Hi,
> > 6000 threads seems like a lot to me for 1 machine
> > I normally dont go above 300 threads per load injector
> >
> > ZK
> >
> > --
> > View this message in context:
> >
> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
> > Sent from the JMeter - User mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
> >
>
> Information contained and transmitted by this e-mail is confidential and
> proprietary to iGATE Patni and its affiliates and is intended for use only
> by the recipient. If you are not the intended recipient, you are hereby
> notified that any dissemination, distribution, copying or use of this
> e-mail is strictly prohibited and you are requested to delete this e-mail
> immediately and notify the originator or mailadmin@igatepatni.com. iGATE
> Patni does not enter into any agreement with any party by e-mail. Any views
> expressed by an individual do not necessarily reflect the view of iGATE
> Patni. iGATE Patni is not responsible for the consequences of any actions
> taken on the basis of information provided, through this email. The
> contents of an attachment to this e-mail may contain software viruses,
> which could damage your own computer system. While iGATE Patni has taken
> every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software viruses.
> You should carry out your own virus checks before opening an attachment. To
> know more about iGATE Patni please visit www.igatepatni.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: J Meter fails when thread count is increased.
Posted by Flavio Cysne <fl...@gmail.com>.
If you can monitor cpu, memory and network usage; and also jvm cpu, heap,
gc usage would be nice to see the results and know if your box can hold
these load. It could be used as a parameter of future tests of members of
this list.
Regards.
Flavio Cysne.
2012/3/1 Naresh Kumar <na...@igatepatni.com>
> Thanks , distributed load testing seems to work.
> Will revert in case of issues.
>
> Between if I use 10 mcahines and use 1000 threads on each machines , will
> this impact on the test results.
> Can someone please confirm.
>
> Regard's
> Kumar
>
> -----Original Message-----
> From: Flavio Cysne [mailto:flaviocysne@gmail.com]
> Sent: 01 March 2012 16:38
> To: JMeter Users List
> Subject: Re: J Meter fails when thread count is increased.
>
> We used to execute distributed testing using JMeter agent (jmeter -s)
> loading almost 400 threads each. On that case we were using HEAP
> with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
> 3GB RAM box.
>
> Keep in mind that for better results the cpu/memory usage don't be higher
> than 80%. It can cause anomalies to test results in some cases.
>
> Hope it helps you.
> Flávio Cysne
>
> 2012/3/1 ZK <st...@gmail.com>
>
> > Hi,
> > 6000 threads seems like a lot to me for 1 machine
> > I normally dont go above 300 threads per load injector
> >
> > ZK
> >
> > --
> > View this message in context:
> >
> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
> > Sent from the JMeter - User mailing list archive at Nabble.com.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
> >
>
> Information contained and transmitted by this e-mail is confidential and
> proprietary to iGATE Patni and its affiliates and is intended for use only
> by the recipient. If you are not the intended recipient, you are hereby
> notified that any dissemination, distribution, copying or use of this
> e-mail is strictly prohibited and you are requested to delete this e-mail
> immediately and notify the originator or mailadmin@igatepatni.com. iGATE
> Patni does not enter into any agreement with any party by e-mail. Any views
> expressed by an individual do not necessarily reflect the view of iGATE
> Patni. iGATE Patni is not responsible for the consequences of any actions
> taken on the basis of information provided, through this email. The
> contents of an attachment to this e-mail may contain software viruses,
> which could damage your own computer system. While iGATE Patni has taken
> every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software viruses.
> You should carry out your own virus checks before opening an attachment. To
> know more about iGATE Patni please visit www.igatepatni.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
RE: J Meter fails when thread count is increased.
Posted by Naresh Kumar <na...@igatepatni.com>.
Thanks , distributed load testing seems to work.
Will revert in case of issues.
Between if I use 10 mcahines and use 1000 threads on each machines , will this impact on the test results.
Can someone please confirm.
Regard's
Kumar
-----Original Message-----
From: Flavio Cysne [mailto:flaviocysne@gmail.com]
Sent: 01 March 2012 16:38
To: JMeter Users List
Subject: Re: J Meter fails when thread count is increased.
We used to execute distributed testing using JMeter agent (jmeter -s)
loading almost 400 threads each. On that case we were using HEAP
with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
3GB RAM box.
Keep in mind that for better results the cpu/memory usage don't be higher
than 80%. It can cause anomalies to test results in some cases.
Hope it helps you.
Flávio Cysne
2012/3/1 ZK <st...@gmail.com>
> Hi,
> 6000 threads seems like a lot to me for 1 machine
> I normally dont go above 300 threads per load injector
>
> ZK
>
> --
> View this message in context:
> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
> Sent from the JMeter - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: J Meter fails when thread count is increased.
Posted by CHARLES BAKER <ch...@clemson.edu>.
So what is meant by "Don't use functional mode" at http://jmeter.apache.org/usermanual/best-practices.html#lean_mean ?
--
Charles H. Baker, Systems Programmer II CCIT/CSO
Don't see me in my cubicle? Try AIM: rascharles GTalk: chbaker@g.clemson.edu
chbaker@clemson.edu | o: 864.656.8069 | gv: 864.990.1297
If you don't fail now and again, it's a sign you're playing it safe. Woody Allen
On Mar 1, 2012, at 11:58 AM, Bruno Antunes wrote:
> How many threads does JMeter support?
> http://wiki.apache.org/jmeter/HowManyThreads
>
> --
> Bruno Antunes
> Software Engineer
>
>
> On Thu, Mar 1, 2012 at 4:50 PM, Anthony Johnson <an...@gmail.com> wrote:
>
>> I agree with everyone else about the 300-400 thread count being a good
>> limit for JMeter. I have taken JMeter above those values, but you are
>> playing in Out of Memory territory.
>>
>> Even if you get the test to execute, 6,000 threads are simply going to
>> compete for resources and yield unreliable results on a single
>> machine.
>>
>> You either need to re-think your test plan to use less threads or
>> scale out the test to use multiple machines.
>>
>> Thanks,
>>
>> Anthony
>>
>> On Thu, Mar 1, 2012 at 11:38 AM, Flavio Cysne <fl...@gmail.com>
>> wrote:
>>> We used to execute distributed testing using JMeter agent (jmeter -s)
>>> loading almost 400 threads each. On that case we were using HEAP
>>> with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
>>> 3GB RAM box.
>>>
>>> Keep in mind that for better results the cpu/memory usage don't be higher
>>> than 80%. It can cause anomalies to test results in some cases.
>>>
>>> Hope it helps you.
>>> Flávio Cysne
>>>
>>> 2012/3/1 ZK <st...@gmail.com>
>>>
>>>> Hi,
>>>> 6000 threads seems like a lot to me for 1 machine
>>>> I normally dont go above 300 threads per load injector
>>>>
>>>> ZK
>>>>
>>>> --
>>>> View this message in context:
>>>>
>> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
>>>> Sent from the JMeter - User mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>>>> For additional commands, e-mail: user-help@jmeter.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: J Meter fails when thread count is increased.
Posted by Bruno Antunes <br...@gmail.com>.
How many threads does JMeter support?
http://wiki.apache.org/jmeter/HowManyThreads
--
Bruno Antunes
Software Engineer
On Thu, Mar 1, 2012 at 4:50 PM, Anthony Johnson <an...@gmail.com> wrote:
> I agree with everyone else about the 300-400 thread count being a good
> limit for JMeter. I have taken JMeter above those values, but you are
> playing in Out of Memory territory.
>
> Even if you get the test to execute, 6,000 threads are simply going to
> compete for resources and yield unreliable results on a single
> machine.
>
> You either need to re-think your test plan to use less threads or
> scale out the test to use multiple machines.
>
> Thanks,
>
> Anthony
>
> On Thu, Mar 1, 2012 at 11:38 AM, Flavio Cysne <fl...@gmail.com>
> wrote:
> > We used to execute distributed testing using JMeter agent (jmeter -s)
> > loading almost 400 threads each. On that case we were using HEAP
> > with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
> > 3GB RAM box.
> >
> > Keep in mind that for better results the cpu/memory usage don't be higher
> > than 80%. It can cause anomalies to test results in some cases.
> >
> > Hope it helps you.
> > Flávio Cysne
> >
> > 2012/3/1 ZK <st...@gmail.com>
> >
> >> Hi,
> >> 6000 threads seems like a lot to me for 1 machine
> >> I normally dont go above 300 threads per load injector
> >>
> >> ZK
> >>
> >> --
> >> View this message in context:
> >>
> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
> >> Sent from the JMeter - User mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
Re: J Meter fails when thread count is increased.
Posted by CHARLES BAKER <ch...@clemson.edu>.
I agree as well. And even when scaling out, if you use many machines running lots of threads all trying to report back to a central controlling instance of meter it's possible to overwhelm them all. I did this, without having adjusted any heap sizes, by trying to have 10 machines run hundreds of threads each. I exhausted heap space on all of them. Of course part of it could have also been my test design, but to really generate big load and collect meaningful, measurable, reliable results you've got to scale out beyond one machine.
--
Charles H. Baker, Systems Programmer II CCIT/CSO
Don't see me in my cubicle? Try AIM: rascharles GTalk: chbaker@g.clemson.edu
chbaker@clemson.edu | 864.656.8069 | 864.990.1297
Give a man a fish and you feed him for a day. Teach a man to fish and you feed
him for a lifetime. Chinese Proverb
On Mar 1, 2012, at 11:50 AM, Anthony Johnson wrote:
> I agree with everyone else about the 300-400 thread count being a good
> limit for JMeter. I have taken JMeter above those values, but you are
> playing in Out of Memory territory.
>
> Even if you get the test to execute, 6,000 threads are simply going to
> compete for resources and yield unreliable results on a single
> machine.
>
> You either need to re-think your test plan to use less threads or
> scale out the test to use multiple machines.
>
> Thanks,
>
> Anthony
>
> On Thu, Mar 1, 2012 at 11:38 AM, Flavio Cysne <fl...@gmail.com> wrote:
>> We used to execute distributed testing using JMeter agent (jmeter -s)
>> loading almost 400 threads each. On that case we were using HEAP
>> with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
>> 3GB RAM box.
>>
>> Keep in mind that for better results the cpu/memory usage don't be higher
>> than 80%. It can cause anomalies to test results in some cases.
>>
>> Hope it helps you.
>> Flávio Cysne
>>
>> 2012/3/1 ZK <st...@gmail.com>
>>
>>> Hi,
>>> 6000 threads seems like a lot to me for 1 machine
>>> I normally dont go above 300 threads per load injector
>>>
>>> ZK
>>>
>>> --
>>> View this message in context:
>>> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
>>> Sent from the JMeter - User mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>>> For additional commands, e-mail: user-help@jmeter.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: J Meter fails when thread count is increased.
Posted by Anthony Johnson <an...@gmail.com>.
I agree with everyone else about the 300-400 thread count being a good
limit for JMeter. I have taken JMeter above those values, but you are
playing in Out of Memory territory.
Even if you get the test to execute, 6,000 threads are simply going to
compete for resources and yield unreliable results on a single
machine.
You either need to re-think your test plan to use less threads or
scale out the test to use multiple machines.
Thanks,
Anthony
On Thu, Mar 1, 2012 at 11:38 AM, Flavio Cysne <fl...@gmail.com> wrote:
> We used to execute distributed testing using JMeter agent (jmeter -s)
> loading almost 400 threads each. On that case we were using HEAP
> with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
> 3GB RAM box.
>
> Keep in mind that for better results the cpu/memory usage don't be higher
> than 80%. It can cause anomalies to test results in some cases.
>
> Hope it helps you.
> Flávio Cysne
>
> 2012/3/1 ZK <st...@gmail.com>
>
>> Hi,
>> 6000 threads seems like a lot to me for 1 machine
>> I normally dont go above 300 threads per load injector
>>
>> ZK
>>
>> --
>> View this message in context:
>> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
>> Sent from the JMeter - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: J Meter fails when thread count is increased.
Posted by Flavio Cysne <fl...@gmail.com>.
We used to execute distributed testing using JMeter agent (jmeter -s)
loading almost 400 threads each. On that case we were using HEAP
with 1,5GB, under a virtualized Linux CentOS with 2 cores processors and
3GB RAM box.
Keep in mind that for better results the cpu/memory usage don't be higher
than 80%. It can cause anomalies to test results in some cases.
Hope it helps you.
Flávio Cysne
2012/3/1 ZK <st...@gmail.com>
> Hi,
> 6000 threads seems like a lot to me for 1 machine
> I normally dont go above 300 threads per load injector
>
> ZK
>
> --
> View this message in context:
> http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
> Sent from the JMeter - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>
RE: J Meter fails when thread count is increased.
Posted by ZK <st...@gmail.com>.
Hi,
6000 threads seems like a lot to me for 1 machine
I normally dont go above 300 threads per load injector
ZK
--
View this message in context: http://jmeter.512774.n5.nabble.com/J-Meter-fails-when-thread-count-is-increased-tp5527549p5527736.html
Sent from the JMeter - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
RE: J Meter fails when thread count is increased.
Posted by Naresh Kumar <na...@igatepatni.com>.
I have 2.40 GHs & 2 GB RAM on my machine from where iam running J meter
-----Original Message-----
From: Shaba K [mailto:shabazia09@gmail.com]
Sent: 01 March 2012 11:39
To: JMeter Users List
Subject: Re: J Meter fails when thread count is increased.
You need to increase the heapsize i guess .
Distributed way of JMeter setup will cater your need .. i don't think
anyone can give you a go saying yeah your tests would work absolutely fine
...
It depends on the h/w your jmeter is running as well isn't it.
Cheers,
-Shabana
On Thu, Mar 1, 2012 at 10:46 AM, Naresh Kumar
<na...@igatepatni.com>wrote:
> Hi,
>
> We are performing load testing on the web services, below is structure of
> our test plan.
>
>
> Ø Thread Group
>
> Ø Webservice SOAP Request
>
> Ø View Results in Table
>
> Ø View Results Tree
>
> Ø HTTP Authorization Manager
>
> We get below error when we try to run 6000 threads in 1 min ramp up time.
>
> Error Message : java.lang.OutOfMemoryError:unable to create new native
> thread' and the test stops.
> After increasing heap size also we are getting 'ERROR - jmeter.JMeter:
> Uncaught exception:
>
> Also what is the max threads J meter can support from single machine, we
> have plan to run 54000 threads in 1 hour
> Is there a workaround possible.
>
> Please help !
>
> Regard's
> Kumar
>
>
>
>
> ________________________________
> Information contained and transmitted by this e-mail is confidential and
> proprietary to iGATE Patni and its affiliates and is intended for use only
> by the recipient. If you are not the intended recipient, you are hereby
> notified that any dissemination, distribution, copying or use of this
> e-mail is strictly prohibited and you are requested to delete this e-mail
> immediately and notify the originator or mailadmin@igatepatni.com. iGATE
> Patni does not enter into any agreement with any party by e-mail. Any views
> expressed by an individual do not necessarily reflect the view of iGATE
> Patni. iGATE Patni is not responsible for the consequences of any actions
> taken on the basis of information provided, through this email. The
> contents of an attachment to this e-mail may contain software viruses,
> which could damage your own computer system. While iGATE Patni has taken
> every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software viruses.
> You should carry out your own virus checks before opening an attachment. To
> know more about iGATE Patni please visit www.igatepatni.com.
>
Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: J Meter fails when thread count is increased.
Posted by Shaba K <sh...@gmail.com>.
You need to increase the heapsize i guess .
Distributed way of JMeter setup will cater your need .. i don't think
anyone can give you a go saying yeah your tests would work absolutely fine
...
It depends on the h/w your jmeter is running as well isn't it.
Cheers,
-Shabana
On Thu, Mar 1, 2012 at 10:46 AM, Naresh Kumar
<na...@igatepatni.com>wrote:
> Hi,
>
> We are performing load testing on the web services, below is structure of
> our test plan.
>
>
> Ø Thread Group
>
> Ø Webservice SOAP Request
>
> Ø View Results in Table
>
> Ø View Results Tree
>
> Ø HTTP Authorization Manager
>
> We get below error when we try to run 6000 threads in 1 min ramp up time.
>
> Error Message : java.lang.OutOfMemoryError:unable to create new native
> thread' and the test stops.
> After increasing heap size also we are getting 'ERROR - jmeter.JMeter:
> Uncaught exception:
>
> Also what is the max threads J meter can support from single machine, we
> have plan to run 54000 threads in 1 hour
> Is there a workaround possible.
>
> Please help !
>
> Regard's
> Kumar
>
>
>
>
> ________________________________
> Information contained and transmitted by this e-mail is confidential and
> proprietary to iGATE Patni and its affiliates and is intended for use only
> by the recipient. If you are not the intended recipient, you are hereby
> notified that any dissemination, distribution, copying or use of this
> e-mail is strictly prohibited and you are requested to delete this e-mail
> immediately and notify the originator or mailadmin@igatepatni.com. iGATE
> Patni does not enter into any agreement with any party by e-mail. Any views
> expressed by an individual do not necessarily reflect the view of iGATE
> Patni. iGATE Patni is not responsible for the consequences of any actions
> taken on the basis of information provided, through this email. The
> contents of an attachment to this e-mail may contain software viruses,
> which could damage your own computer system. While iGATE Patni has taken
> every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software viruses.
> You should carry out your own virus checks before opening an attachment. To
> know more about iGATE Patni please visit www.igatepatni.com.
>
Re: J Meter fails when thread count is increased.
Posted by Fairul Rizal Fahrurazi <fa...@mimos.my>.
I think if you have maximized the heap size on jmeter server and client,the next thing to try out before looking on the hardware is to distribute jmeter server.
Probably you can distribute a few cluster that have jmeter server and client and each cluster kickoff at the same time..
Thanks,
Fairul
On Mar 1, 2012, at 6:47 PM, "Naresh Kumar" <na...@igatepatni.com> wrote:
> Hi,
>
> We are performing load testing on the web services, below is structure of our test plan.
>
>
> Ø Thread Group
>
> Ø Webservice SOAP Request
>
> Ø View Results in Table
>
> Ø View Results Tree
>
> Ø HTTP Authorization Manager
>
> We get below error when we try to run 6000 threads in 1 min ramp up time.
>
> Error Message : java.lang.OutOfMemoryError:unable to create new native thread' and the test stops.
> After increasing heap size also we are getting 'ERROR - jmeter.JMeter: Uncaught exception:
>
> Also what is the max threads J meter can support from single machine, we have plan to run 54000 threads in 1 hour
> Is there a workaround possible.
>
> Please help !
>
> Regard's
> Kumar
>
>
>
>
> ________________________________
> Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com.
-----------------------------------------------
A strategic agency under MOSTI
www.mimos.my
-----------------------------------------------
------------------------------------------------------------------
-
-
DISCLAIMER:
This e-mail (including any attachments) is for the addressee(s)
only and may contain confidential information. If you are not the
intended recipient, please note that any dealing, review,
distribution, printing, copying or use of this e-mail is strictly
prohibited. If you have received this email in error, please notify
the sender immediately and delete the original message.
MIMOS Berhad is a research and development institution under
the purview of the Malaysian Ministry of Science, Technology and
Innovation. Opinions, conclusions and other information in this e-
mail that do not relate to the official business of MIMOS Berhad
and/or its subsidiaries shall be understood as neither given nor
endorsed by MIMOS Berhad and/or its subsidiaries and neither
MIMOS Berhad nor its subsidiaries accepts responsibility for the
same. All liability arising from or in connection with computer
viruses and/or corrupted e-mails is excluded to the fullest extent
permitted by law.