You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2011/12/08 22:04:42 UTC
Re: IF Controller degrading throughput
Hello,
I confirm the issue is due to a memory leak but not in Heap zone but in Non
Heap zone. I reproduced the issue.
See :
- https://issues.apache.org/bugzilla/show_bug.cgi?id=52305
Issue is due to either a leak in rhino or in our JMeter usage of rhino.
Workaround is to use expression in your IfController
${__jexl(${JMeterThread.last_sample_ok} == true)}
Regards
Philippe
On Thu, Dec 8, 2011 at 9:58 PM, Stanton W Derry <de...@cpt.com> wrote:
> **
> Hi Phillippe,
>
> Memory isn't an issue as there are no heap dumps for any of my runs. Also
> my heap settings are -Xms2048m -Xmx2048m. I noticed the issue with my
> performance runs and started eliminating the HTTP/Soap Samplers in my test
> plan. When I disabled the IF Controller the throughput increased. I then
> created a three Sampler plan using the Java Request Sampler and an If
> Controller to verify my findings. The Java Request Sampler settings are:
>
> Sleep_Time 20
> Sleep_Mask 0x00
>
> The only listener used is the Summary Listener.
>
> Easily recreated.
>
> Stan
>
>
>
> On 12/8/11 3:07 PM, Philippe Mouawad wrote:
>
> Hello,
> Can you make your test plan available on a public URL (or maybe open a
> Bugzilla issue attaching it).
> What kind of sampler do you use ?
> What Listeners do you have except "Generate Summary Results" ?
> Can you open jmeter and search for:
> DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>
> And add this to it
> -XX:HeapDumpPath=<change path here>
>
> Run you test and check no file is generated in the path, if you find
> something put the hprof file on external website.
>
>
> Regards
> Philippe
> http://www.ubik-ingenierie.com
>
> On Thu, Dec 8, 2011 at 7:18 PM, Stanton W Derry <de...@cpt.com> wrote:
>
>> I'm using JMeter 2.5.1 r1177103 and noticed when an If Controller is used
>> it degrades the throughput till a full gc occurs at which time the
>> throughput is back up. I used two different test scripts to verify this
>> anomaly.
>>
>> The test plans used are:
>>
>> Thread Group 1 - Threads 40 - Forever - Duration -3600
>> Sampler
>> Sampler
>> Sampler
>>
>> and
>>
>> Thread Group 2 - Threads 40 - Forever - Duration -3600
>> Sampler
>> IF Controller - ${JMeterThread.last_sample_ok}
>> Sampler
>> Sampler
>>
>> The samplers response times are ~20ms and in the Summary Listener for
>> Thread Group 1 see a total throughput of 1136.6/sec. For Thread Group2 the
>> max reached is 714/sec, declines to about 600/sec, gc executed, and then
>> climbs back to ~670 starting the cycle over.
>>
>> Has anyone encountered a similar issue when using the IF Controller?
>>
>> Thanks
>> Stan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>> For additional commands, e-mail: user-help@jmeter.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: IF Controller degrading throughput
Posted by Stanton W Derry <de...@cpt.com>.
Philippe,
Setting "Interpret condition as Variable expression" solved the problem.
Stan
On 12/8/11 4:49 PM, Philippe Mouawad wrote:
> Hello,
> After further analysis, this is not a memory leak but a size
> misconfiguration:
> Fix is to add this in jmeter file to HEAP variable.:
> -XX:MaxPermSize=128m
>
>
> Another simpler option is to check:
> "Interpret condition as Variable expression"
>
> Please let me know which one of the two works.
>
> Regards
> Philippe.
> http://www.ubik-ingenierie.com
>
> On Thu, Dec 8, 2011 at 10:04 PM, Philippe Mouawad
> <philippe.mouawad@gmail.com <ma...@gmail.com>> wrote:
>
> Hello,
> I confirm the issue is due to a memory leak but not in Heap zone
> but in Non Heap zone. I reproduced the issue.
> See :
>
> * https://issues.apache.org/bugzilla/show_bug.cgi?id=52305
>
>
> Issue is due to either a leak in rhino or in our JMeter usage of
> rhino.
>
> Workaround is to use expression in your IfController
>
> ${__jexl(${JMeterThread.last_sample_ok} == true)}
>
>
>
>
>
>
> Regards
> Philippe
>
> On Thu, Dec 8, 2011 at 9:58 PM, Stanton W Derry <derry@cpt.com
> <ma...@cpt.com>> wrote:
>
> Hi Phillippe,
>
> Memory isn't an issue as there are no heap dumps for any of my
> runs. Also my heap settings are -Xms2048m -Xmx2048m. I
> noticed the issue with my performance runs and started
> eliminating the HTTP/Soap Samplers in my test plan. When I
> disabled the IF Controller the throughput increased. I then
> created a three Sampler plan using the Java Request Sampler
> and an If Controller to verify my findings. The Java Request
> Sampler settings are:
>
> Sleep_Time 20
> Sleep_Mask 0x00
>
> The only listener used is the Summary Listener.
>
> Easily recreated.
>
> Stan
>
>
>
> On 12/8/11 3:07 PM, Philippe Mouawad wrote:
>> Hello,
>> Can you make your test plan available on a public URL (or
>> maybe open a Bugzilla issue attaching it).
>> What kind of sampler do you use ?
>> What Listeners do you have except "Generate Summary Results" ?
>> Can you open jmeter and search for:
>> DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>>
>> And add this to it
>> -XX:HeapDumpPath=<change path here>
>>
>> Run you test and check no file is generated in the path, if
>> you find something put the hprof file on external website.
>>
>>
>> Regards
>> Philippe
>> http://www.ubik-ingenierie.com
>>
>> On Thu, Dec 8, 2011 at 7:18 PM, Stanton W Derry
>> <derry@cpt.com <ma...@cpt.com>> wrote:
>>
>> I'm using JMeter 2.5.1 r1177103 and noticed when an If
>> Controller is used it degrades the throughput till a full
>> gc occurs at which time the throughput is back up. I used
>> two different test scripts to verify this anomaly.
>>
>> The test plans used are:
>>
>> Thread Group 1 - Threads 40 - Forever - Duration -3600
>> Sampler
>> Sampler
>> Sampler
>>
>> and
>>
>> Thread Group 2 - Threads 40 - Forever - Duration -3600
>> Sampler
>> IF Controller - ${JMeterThread.last_sample_ok}
>> Sampler
>> Sampler
>>
>> The samplers response times are ~20ms and in the Summary
>> Listener for Thread Group 1 see a total throughput of
>> 1136.6/sec. For Thread Group2 the max reached is
>> 714/sec, declines to about 600/sec, gc executed, and then
>> climbs back to ~670 starting the cycle over.
>>
>> Has anyone encountered a similar issue when using the IF
>> Controller?
>>
>> Thanks
>> Stan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> user-unsubscribe@jmeter.apache.org
>> <ma...@jmeter.apache.org>
>> For additional commands, e-mail:
>> user-help@jmeter.apache.org
>> <ma...@jmeter.apache.org>
>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
Re: IF Controller degrading throughput
Posted by Philippe Mouawad <ph...@gmail.com>.
Then your issue CAN come from soapXml/rpc sampler.
Because my tests of the 2 propositions i made don't show any issue anymore,
Max perm gen reached is 110 m with javascript and 40 mo with expression.
Maybe you should open a Bugzilla issue attaching your test plan.
Regards
Philippe
Http://www.Ubik-Ingenierie.com
On Thursday, December 8, 2011, Stanton W Derry <de...@cpt.com> wrote:
> Hello,
>
> I have already exceeded your recommendation, my setting is at 256m. I
came to this value running with SoapXML/RPC samplers. If I change to just
HTTP samplers I don't see the same growth in Permgen. Will try the
Variable expression setting.
>
> Stan
>
> On 12/8/11 4:49 PM, Philippe Mouawad wrote:
>
> Hello,
> After further analysis, this is not a memory leak but a size
misconfiguration:
> Fix is to add this in jmeter file to HEAP variable.:
> -XX:MaxPermSize=128m
>
>
> Another simpler option is to check:
> "Interpret condition as Variable expression"
>
> Please let me know which one of the two works.
>
> Regards
> Philippe.
> http://www.ubik-ingenierie.com
>
> On Thu, Dec 8, 2011 at 10:04 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
>
> Hello,
> I confirm the issue is due to a memory leak but not in Heap zone but in
Non Heap zone. I reproduced the issue.
> See :
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52305
>
> Issue is due to either a leak in rhino or in our JMeter usage of rhino.
>
> Workaround is to use expression in your IfController
>
> ${__jexl(${JMeterThread.last_sample_ok} == true)}
>
>
>
>
>
>
> Regards
> Philippe
> On Thu, Dec 8, 2011 at 9:58 PM, Stanton W Derry <de...@cpt.com> wrote:
>
> Hi Phillippe,
>
> Memory isn't an issue as there are no heap dumps for any of my runs. Also
my heap settings are -Xms2048m -Xmx2048m. I noticed the issue with my
performance runs and started eliminating the HTTP/Soap Samplers in my test
plan. When I disabled the IF Controller the throughput increased. I then
created a three Sampler plan using the Java Request Sampler and an If
Controller to verify my findings. The Java Request Sampler settings are:
>
> Sleep_Time 20
> Sleep_Mask 0x00
>
> The only listener used is the Summary Listener.
>
> Easily recreated.
>
> Stan
>
>
> On 12/8/11 3:07 PM, Philippe Mouawad wrote:
>
> Hello,
> Can you make your test plan available on a public URL (or maybe open a
Bugzilla issue attaching it).
> What kind of sampler do you use ?
> What Listeners do you have except "Generate Summary Results" ?
> Can you open jmeter and search for:
> DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>
> And add this to it
> -XX:HeapDumpPath=<change path here>
>
> Run you test and check no file is generated in the path, if you find
something put the hprof file on external website.
>
>
> Regards
> Philippe
> http://www.ubik-ingenierie.com
>
> On Thu, Dec 8, 2011 at 7:18 PM, Stanton W Derry <de...@cpt.com> wrote:
>
> I'm using JMeter 2.5.1 r1177103 and noticed when an If Controller is used
it degrades the throughput till a full gc occurs at which time the
throughput is back up. I used two different test scripts to verify this
anomaly.
>
> The test plans used are:
>
> Thread Group 1 - Threads 40 - Forever - Duration -3600
> Sampler
> Sampler
> Sampler
>
> and
>
> Thread Group 2 - Threads 40 - Forever - Duration -3600
> Sampler
> IF Controller - ${JMeterThread.last_sample_ok}
> Sampler
> Sampler
>
> The samplers response times are ~20ms and in the Summary Listener for
Thread Group 1 see a total throughput of 1136.6/sec. For Thread Group2 the
max reached is 714/sec, declines to about 600/sec, gc executed, and then
climbs back to ~670 starting the cycle over.
>
> Has anyone encountered a similar issue when using the IF Controller?
>
> Thanks
> Stan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail:
--
Cordialement.
Philippe Mouawad.
Re: IF Controller degrading throughput
Posted by Stanton W Derry <de...@cpt.com>.
Hello,
I have already exceeded your recommendation, my setting is at 256m. I
came to this value running with SoapXML/RPC samplers. If I change to
just HTTP samplers I don't see the same growth in Permgen. Will try the
Variable expression setting.
Stan
On 12/8/11 4:49 PM, Philippe Mouawad wrote:
> Hello,
> After further analysis, this is not a memory leak but a size
> misconfiguration:
> Fix is to add this in jmeter file to HEAP variable.:
> -XX:MaxPermSize=128m
>
>
> Another simpler option is to check:
> "Interpret condition as Variable expression"
>
> Please let me know which one of the two works.
>
> Regards
> Philippe.
> http://www.ubik-ingenierie.com
>
> On Thu, Dec 8, 2011 at 10:04 PM, Philippe Mouawad
> <philippe.mouawad@gmail.com <ma...@gmail.com>> wrote:
>
> Hello,
> I confirm the issue is due to a memory leak but not in Heap zone
> but in Non Heap zone. I reproduced the issue.
> See :
>
> * https://issues.apache.org/bugzilla/show_bug.cgi?id=52305
>
>
> Issue is due to either a leak in rhino or in our JMeter usage of
> rhino.
>
> Workaround is to use expression in your IfController
>
> ${__jexl(${JMeterThread.last_sample_ok} == true)}
>
>
>
>
>
>
> Regards
> Philippe
>
> On Thu, Dec 8, 2011 at 9:58 PM, Stanton W Derry <derry@cpt.com
> <ma...@cpt.com>> wrote:
>
> Hi Phillippe,
>
> Memory isn't an issue as there are no heap dumps for any of my
> runs. Also my heap settings are -Xms2048m -Xmx2048m. I
> noticed the issue with my performance runs and started
> eliminating the HTTP/Soap Samplers in my test plan. When I
> disabled the IF Controller the throughput increased. I then
> created a three Sampler plan using the Java Request Sampler
> and an If Controller to verify my findings. The Java Request
> Sampler settings are:
>
> Sleep_Time 20
> Sleep_Mask 0x00
>
> The only listener used is the Summary Listener.
>
> Easily recreated.
>
> Stan
>
>
>
> On 12/8/11 3:07 PM, Philippe Mouawad wrote:
>> Hello,
>> Can you make your test plan available on a public URL (or
>> maybe open a Bugzilla issue attaching it).
>> What kind of sampler do you use ?
>> What Listeners do you have except "Generate Summary Results" ?
>> Can you open jmeter and search for:
>> DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>>
>> And add this to it
>> -XX:HeapDumpPath=<change path here>
>>
>> Run you test and check no file is generated in the path, if
>> you find something put the hprof file on external website.
>>
>>
>> Regards
>> Philippe
>> http://www.ubik-ingenierie.com
>>
>> On Thu, Dec 8, 2011 at 7:18 PM, Stanton W Derry
>> <derry@cpt.com <ma...@cpt.com>> wrote:
>>
>> I'm using JMeter 2.5.1 r1177103 and noticed when an If
>> Controller is used it degrades the throughput till a full
>> gc occurs at which time the throughput is back up. I used
>> two different test scripts to verify this anomaly.
>>
>> The test plans used are:
>>
>> Thread Group 1 - Threads 40 - Forever - Duration -3600
>> Sampler
>> Sampler
>> Sampler
>>
>> and
>>
>> Thread Group 2 - Threads 40 - Forever - Duration -3600
>> Sampler
>> IF Controller - ${JMeterThread.last_sample_ok}
>> Sampler
>> Sampler
>>
>> The samplers response times are ~20ms and in the Summary
>> Listener for Thread Group 1 see a total throughput of
>> 1136.6/sec. For Thread Group2 the max reached is
>> 714/sec, declines to about 600/sec, gc executed, and then
>> climbs back to ~670 starting the cycle over.
>>
>> Has anyone encountered a similar issue when using the IF
>> Controller?
>>
>> Thanks
>> Stan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> user-unsubscribe@jmeter.apache.org
>> <ma...@jmeter.apache.org>
>> For additional commands, e-mail:
>> user-help@jmeter.apache.org
>> <ma...@jmeter.apache.org>
>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
Re: IF Controller degrading throughput
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
After further analysis, this is not a memory leak but a size
misconfiguration:
Fix is to add this in jmeter file to HEAP variable.:
-XX:MaxPermSize=128m
Another simpler option is to check:
"Interpret condition as Variable expression"
Please let me know which one of the two works.
Regards
Philippe.
http://www.ubik-ingenierie.com
On Thu, Dec 8, 2011 at 10:04 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
> Hello,
> I confirm the issue is due to a memory leak but not in Heap zone but in
> Non Heap zone. I reproduced the issue.
> See :
>
> - https://issues.apache.org/bugzilla/show_bug.cgi?id=52305
>
>
> Issue is due to either a leak in rhino or in our JMeter usage of rhino.
>
> Workaround is to use expression in your IfController
>
> ${__jexl(${JMeterThread.last_sample_ok} == true)}
>
>
>
> Regards
> Philippe
>
> On Thu, Dec 8, 2011 at 9:58 PM, Stanton W Derry <de...@cpt.com> wrote:
>
>> **
>> Hi Phillippe,
>>
>> Memory isn't an issue as there are no heap dumps for any of my runs. Also
>> my heap settings are -Xms2048m -Xmx2048m. I noticed the issue with my
>> performance runs and started eliminating the HTTP/Soap Samplers in my test
>> plan. When I disabled the IF Controller the throughput increased. I then
>> created a three Sampler plan using the Java Request Sampler and an If
>> Controller to verify my findings. The Java Request Sampler settings are:
>>
>> Sleep_Time 20
>> Sleep_Mask 0x00
>>
>> The only listener used is the Summary Listener.
>>
>> Easily recreated.
>>
>> Stan
>>
>>
>>
>> On 12/8/11 3:07 PM, Philippe Mouawad wrote:
>>
>> Hello,
>> Can you make your test plan available on a public URL (or maybe open a
>> Bugzilla issue attaching it).
>> What kind of sampler do you use ?
>> What Listeners do you have except "Generate Summary Results" ?
>> Can you open jmeter and search for:
>> DUMP="-XX:+HeapDumpOnOutOfMemoryError"
>>
>> And add this to it
>> -XX:HeapDumpPath=<change path here>
>>
>> Run you test and check no file is generated in the path, if you find
>> something put the hprof file on external website.
>>
>>
>> Regards
>> Philippe
>> http://www.ubik-ingenierie.com
>>
>> On Thu, Dec 8, 2011 at 7:18 PM, Stanton W Derry <de...@cpt.com> wrote:
>>
>>> I'm using JMeter 2.5.1 r1177103 and noticed when an If Controller is
>>> used it degrades the throughput till a full gc occurs at which time the
>>> throughput is back up. I used two different test scripts to verify this
>>> anomaly.
>>>
>>> The test plans used are:
>>>
>>> Thread Group 1 - Threads 40 - Forever - Duration -3600
>>> Sampler
>>> Sampler
>>> Sampler
>>>
>>> and
>>>
>>> Thread Group 2 - Threads 40 - Forever - Duration -3600
>>> Sampler
>>> IF Controller - ${JMeterThread.last_sample_ok}
>>> Sampler
>>> Sampler
>>>
>>> The samplers response times are ~20ms and in the Summary Listener for
>>> Thread Group 1 see a total throughput of 1136.6/sec. For Thread Group2 the
>>> max reached is 714/sec, declines to about 600/sec, gc executed, and then
>>> climbs back to ~670 starting the cycle over.
>>>
>>> Has anyone encountered a similar issue when using the IF Controller?
>>>
>>> Thanks
>>> Stan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
>>> For additional commands, e-mail: user-help@jmeter.apache.org
>>>
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
--
Cordialement.
Philippe Mouawad.