You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Applabs Performance Team <pe...@applabs.net> on 2004/01/20 05:20:22 UTC
Remote Testing - Tuning CPU usage at controller
Hi All
When we conduct a remote test with heavier loads always the controller is a bottleneck as it utilizes almost all times 100% CPU utilization.
So as to bridge this gap, we modified two classes (ResultCollector.java and RemoteListenerWrapper.java) besides adding 3 properties in the 'jmeter.properties' file.
The first property added in the 'jmeter.properties' file, decides when to send the sample results to the controller from the remote server. The value for this property should be one of the following three.
1.Live: It is the existing behavior i.e. sending the sample result to the central controller, soon after receiving the sample result.
2.Batch Mode: Sample Results will be transferred to the controller in a batch mode from the remote server. The size of the batch is configurable from the 'jmeter.properties' file (2nd property added). So in this case, first the sample results are collected at the remote server until the number of sample results is equal to the specified batch size, and once the number reaches the specified batch size, the collected sample results will be transferred to the controller.
So as to further control the CPU utilization at the controller, we used one more property in the 'jmeter.properties' file (3rd property added), which specifies the delay between consecutive sample results transfer, while transferring the sample results to the controller. This helps a lot in tuning the CPU usage at the controller.
3.End of the test: In this all the sample results are collected at the remote server until the end of the test. Once the test is stopped, the sample results collected at the remote server will be transferred to the controller.
Out of these three transfer modes, we found the 2nd type as most useful. We felt that it is behaving superb.
We successfully conducted a load test using a load of 500 virtual users using the 'Batch Mode'. In this test, JMeter controller was running on 1 machine, which was listening to 5 remote servers with 100 virtual users on each remote server. My test plan contains 5 http samplers within a single thread group. We conducted the test for a period of 1 hour. Controller never took 100% CPU utilization and it was always used less than 80% CPU.
The configuration of the controller machine used is Pentium 4, 1.8 GHZ, 512 MB ram.
Is there any one interested in helping us in testing this feature and sharing your views? If any one is interested to help us we will share the modifications, which we made to the source code.
Thanks
Applabs Team
Re: Remote Testing - Tuning CPU usage at controller
Posted by Jordi Salvat i Alabart <js...@atg.com>.
This sounds really interesting. I suggest that you open an enhancement
request in Bugzilla and attach your code to it. Or just send it to the
jmeter-dev list. I'm sure there's people there who will be interested to
help.
--
Salut,
Jordi.
En/na Applabs Performance Team ha escrit:
> Hi All
>
> When we conduct a remote test with heavier loads always the controller is a bottleneck as it utilizes almost all times 100% CPU utilization.
>
> So as to bridge this gap, we modified two classes (ResultCollector.java and RemoteListenerWrapper.java) besides adding 3 properties in the 'jmeter.properties' file.
>
> The first property added in the 'jmeter.properties' file, decides when to send the sample results to the controller from the remote server. The value for this property should be one of the following three.
>
> 1.Live: It is the existing behavior i.e. sending the sample result to the central controller, soon after receiving the sample result.
>
> 2.Batch Mode: Sample Results will be transferred to the controller in a batch mode from the remote server. The size of the batch is configurable from the 'jmeter.properties' file (2nd property added). So in this case, first the sample results are collected at the remote server until the number of sample results is equal to the specified batch size, and once the number reaches the specified batch size, the collected sample results will be transferred to the controller.
>
> So as to further control the CPU utilization at the controller, we used one more property in the 'jmeter.properties' file (3rd property added), which specifies the delay between consecutive sample results transfer, while transferring the sample results to the controller. This helps a lot in tuning the CPU usage at the controller.
>
> 3.End of the test: In this all the sample results are collected at the remote server until the end of the test. Once the test is stopped, the sample results collected at the remote server will be transferred to the controller.
>
> Out of these three transfer modes, we found the 2nd type as most useful. We felt that it is behaving superb.
>
> We successfully conducted a load test using a load of 500 virtual users using the 'Batch Mode'. In this test, JMeter controller was running on 1 machine, which was listening to 5 remote servers with 100 virtual users on each remote server. My test plan contains 5 http samplers within a single thread group. We conducted the test for a period of 1 hour. Controller never took 100% CPU utilization and it was always used less than 80% CPU.
>
> The configuration of the controller machine used is Pentium 4, 1.8 GHZ, 512 MB ram.
>
> Is there any one interested in helping us in testing this feature and sharing your views? If any one is interested to help us we will share the modifications, which we made to the source code.
>
> Thanks
> Applabs Team
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Adding Notes?
Posted by Craig Palmer <cr...@peace.com>.
I am in the process of prototyping a performance test system solution
using Jmeter which requires me to translate a previously developed
jython scripted solution.
What has occurred to me is that Jmeter doesnt seem to support the
capability to add notes to the test structure? Something that can
explain to others the reasoning/understanding behind the component and
sub component structure. For us, the performance test users will be
different from those who compile them and we'll be providing test
scenarios specific to each version of our product.
Our test scenarios are quite complex and our scripts have detailed
notes to explain why the test does what it does at each point. So far,
my prototype has components that are nested up to 9 levels deep but
they will get deeper yet. Added notes/details would be useful for
those new to the script and as a reminder at later dates.
In short, it would be really cool if each screen has a place where
test notes could be added, or some kind of test pop-up when you hold
the mouse over an icon in the JTree or similar. This information would
be saved in the XML .jmx file.
Craig.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Remote Testing - Tuning CPU usage at controller
Posted by Applabs Performance Team <pe...@applabs.net>.
Hi Craig Palmer
We posted a new bug (id: 26337), requesting for related enhancement.
We attached the modified files to this bug. The attached zip file also
contains a readme file.
Now you can download the files from there.
Please let us know for any help or issues.
Thanks
Applabs Team
----- Original Message -----
From: "Craig Palmer" <cr...@peace.com>
To: "JMeter Users List" <jm...@jakarta.apache.org>
Sent: Tuesday, January 20, 2004 10:27 AM
Subject: Re: Remote Testing - Tuning CPU usage at controller
> Please include me. I have just picked up on Jmeter last week and am in
> the process of prototyping how it could be a solution for load testing
> our browser based product. Already I have added a new controller
> (random probability based branching) and a new timer. Our solution
> uses Java Samplers to handle RMI access.
>
> I am eventually looking to emulate up to 2000 concurrent users but
> only about 600 users in the shorter term.
>
> thanks,
>
> Craig Palmer.
>
> Applabs Performance Team wrote:
> > Hi All
> >
> > When we conduct a remote test with heavier loads always the controller
is a bottleneck as it utilizes almost all times 100% CPU utilization.
> >
> > So as to bridge this gap, we modified two classes (ResultCollector.java
and RemoteListenerWrapper.java) besides adding 3 properties in the
'jmeter.properties' file.
> >
> > The first property added in the 'jmeter.properties' file, decides when
to send the sample results to the controller from the remote server. The
value for this property should be one of the following three.
> >
> > 1.Live: It is the existing behavior i.e. sending the sample result to
the central controller, soon after receiving the sample result.
> >
> > 2.Batch Mode: Sample Results will be transferred to the controller in a
batch mode from the remote server. The size of the batch is configurable
from the 'jmeter.properties' file (2nd property added). So in this case,
first the sample results are collected at the remote server until the number
of sample results is equal to the specified batch size, and once the number
reaches the specified batch size, the collected sample results will be
transferred to the controller.
> >
> > So as to further control the CPU utilization at the controller, we used
one more property in the 'jmeter.properties' file (3rd property added),
which specifies the delay between consecutive sample results transfer, while
transferring the sample results to the controller. This helps a lot in
tuning the CPU usage at the controller.
> >
> > 3.End of the test: In this all the sample results are collected at the
remote server until the end of the test. Once the test is stopped, the
sample results collected at the remote server will be transferred to the
controller.
> >
> > Out of these three transfer modes, we found the 2nd type as most useful.
We felt that it is behaving superb.
> >
> > We successfully conducted a load test using a load of 500 virtual users
using the 'Batch Mode'. In this test, JMeter controller was running on 1
machine, which was listening to 5 remote servers with 100 virtual users on
each remote server. My test plan contains 5 http samplers within a single
thread group. We conducted the test for a period of 1 hour. Controller never
took 100% CPU utilization and it was always used less than 80% CPU.
> >
> > The configuration of the controller machine used is Pentium 4, 1.8 GHZ,
512 MB ram.
> >
> > Is there any one interested in helping us in testing this feature and
sharing your views? If any one is interested to help us we will share the
modifications, which we made to the source code.
> >
> > Thanks
> > Applabs Team
> >
>
>
> --
> Craig Palmer Mobile NZ: +64 21 755 254
> Peace Software URL: http://www.peace.com
> Email: craig.palmer@peace.com
>
>
> ---------------------------------------------------------------------
> 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: Remote Testing - Tuning CPU usage at controller
Posted by Craig Palmer <cr...@peace.com>.
Please include me. I have just picked up on Jmeter last week and am in
the process of prototyping how it could be a solution for load testing
our browser based product. Already I have added a new controller
(random probability based branching) and a new timer. Our solution
uses Java Samplers to handle RMI access.
I am eventually looking to emulate up to 2000 concurrent users but
only about 600 users in the shorter term.
thanks,
Craig Palmer.
Applabs Performance Team wrote:
> Hi All
>
> When we conduct a remote test with heavier loads always the controller is a bottleneck as it utilizes almost all times 100% CPU utilization.
>
> So as to bridge this gap, we modified two classes (ResultCollector.java and RemoteListenerWrapper.java) besides adding 3 properties in the 'jmeter.properties' file.
>
> The first property added in the 'jmeter.properties' file, decides when to send the sample results to the controller from the remote server. The value for this property should be one of the following three.
>
> 1.Live: It is the existing behavior i.e. sending the sample result to the central controller, soon after receiving the sample result.
>
> 2.Batch Mode: Sample Results will be transferred to the controller in a batch mode from the remote server. The size of the batch is configurable from the 'jmeter.properties' file (2nd property added). So in this case, first the sample results are collected at the remote server until the number of sample results is equal to the specified batch size, and once the number reaches the specified batch size, the collected sample results will be transferred to the controller.
>
> So as to further control the CPU utilization at the controller, we used one more property in the 'jmeter.properties' file (3rd property added), which specifies the delay between consecutive sample results transfer, while transferring the sample results to the controller. This helps a lot in tuning the CPU usage at the controller.
>
> 3.End of the test: In this all the sample results are collected at the remote server until the end of the test. Once the test is stopped, the sample results collected at the remote server will be transferred to the controller.
>
> Out of these three transfer modes, we found the 2nd type as most useful. We felt that it is behaving superb.
>
> We successfully conducted a load test using a load of 500 virtual users using the 'Batch Mode'. In this test, JMeter controller was running on 1 machine, which was listening to 5 remote servers with 100 virtual users on each remote server. My test plan contains 5 http samplers within a single thread group. We conducted the test for a period of 1 hour. Controller never took 100% CPU utilization and it was always used less than 80% CPU.
>
> The configuration of the controller machine used is Pentium 4, 1.8 GHZ, 512 MB ram.
>
> Is there any one interested in helping us in testing this feature and sharing your views? If any one is interested to help us we will share the modifications, which we made to the source code.
>
> Thanks
> Applabs Team
>
--
Craig Palmer Mobile NZ: +64 21 755 254
Peace Software URL: http://www.peace.com
Email: craig.palmer@peace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org