You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by "Bhadauria, Tarun Kumar" <ta...@zalando.de> on 2015/12/16 10:45:32 UTC
Backend Listener and reduced throughput
Test Summary -
Jmeter Version - 2.13
Jmeter Machines - 10 AWS EC2 m4.4xlarge instances
Number of threads on each instance 72 hence in total 720 threads in
distributed mode
Test is executed in non GUI mode
I was experimenting with Backend listener as described here
<http://jmeter.apache.org/usermanual/realtime-results.html> and came across
drastic reduction in throughput against a static html file. These are the
results are received for 5 minutes test -
Throughput with backend listener - 5000/sec
Throughput without backend listener - 9800/sec
I have repeated the test over a period of one week and test results have
been consistent.
I did not see any significant difference in load avg or cpu utilization on
load agents with or without backend listener.
Is JMeter performance degradation a known issue with Backend listener?
Re: Backend Listener and reduced throughput
Posted by Deepak Shetty <sh...@gmail.com>.
>JMeter Client, InfluxDB, Graphite server all are on one machine.
This is almost always a bad idea. Run Jmeter on its own and see if that
helps too.
On Mon, Dec 28, 2015 at 4:41 AM, Bhadauria, Tarun Kumar <
tarun.kumar.bhadauria@zalando.de> wrote:
> On 16 December 2015 at 15:53, UBIK LOAD PACK Support <
> support@ubikloadpack.com> wrote:
>
> > As per my explanation in previous mail you can understand the impact
>
>
> - Network quality between JMeter and the InfluxDB or Graphite server
>
>
> JMeter Client, InfluxDB, Graphite server all are on one machine. Test is
> run in distributed mode.
>
> - Number of Samples that you track
> > - The queue size, if you test is at high throughput (no timer), then
> the
> > Async Queue Size will slow down compared to no using backend listener.
>
>
> I want to track all samples, would there be a reason to not track all?
> So if I have 12000 samples/sec then should Async Queue Size be set to
> 12000. Is that one on one co-relation?
>
> - Bear in mind also that Increasing Async Queue Size will increase
> > memory footprint
>
>
> I will experiment with diff queue size and post result when I am back to
> work next year.
>
Re: Backend Listener and reduced throughput
Posted by "Bhadauria, Tarun Kumar" <ta...@zalando.de>.
On 16 December 2015 at 15:53, UBIK LOAD PACK Support <
support@ubikloadpack.com> wrote:
> As per my explanation in previous mail you can understand the impact
- Network quality between JMeter and the InfluxDB or Graphite server
JMeter Client, InfluxDB, Graphite server all are on one machine. Test is
run in distributed mode.
- Number of Samples that you track
> - The queue size, if you test is at high throughput (no timer), then the
> Async Queue Size will slow down compared to no using backend listener.
I want to track all samples, would there be a reason to not track all?
So if I have 12000 samples/sec then should Async Queue Size be set to
12000. Is that one on one co-relation?
- Bear in mind also that Increasing Async Queue Size will increase
> memory footprint
I will experiment with diff queue size and post result when I am back to
work next year.
Re: Backend Listener and reduced throughput
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
On Wed, Dec 16, 2015 at 3:51 PM, Bhadauria, Tarun Kumar <
tarun.kumar.bhadauria@zalando.de> wrote:
> @Steven
> Given that I run test in distributed mode, I was hoping that the
> controller machine would push stats to influx db after it receives results
> from agents pumping the load and this should not have
>
any impact on test results, but that does not seem to be the case here Or I
> missed something.
>
As per my explanation in previous mail you can understand the impact
>
> @UBIK
> Where can I set Async Queue Size?
>
In BackendListener GUI
>
>
> Thanks
> Tarun K
>
> On 16 December 2015 at 14:47, UBIK LOAD PACK Support <
> support@ubikloadpack.com> wrote:
>
>> Hello,
>> Did you try playing with Async Queue Size 5000 might be very short for a
>> test that has no timer?
>>
>> The difference can be explained by many factors:
>>
>> - Network quality between JMeter and the InfluxDB or Graphite server
>> - Number of Samples that you track
>> - The queue size, if you test is at high throughput (no timer), then
>> the
>> Async Queue Size will slow down compared to no using backend listener.
>> - Bear in mind also that Increasing Async Queue Size will increase
>>
>> memory footprint
>>
>> Regards
>>
>> On Wed, Dec 16, 2015 at 2:38 PM, Steven Swor <sw...@gmail.com>
>> wrote:
>>
>> > Generally speaking, performance degradation is a known issue with all
>> > listeners (more processing = more cpu cycles consumed per loop).
>> However,
>> > with the GraphiteBackendListener(
>> >
>> >
>> https://github.com/apache/jmeter/blob/v2_13/src/components/org/apache/jmeter/visualizers/backend/graphite/GraphiteBackendListenerClient.java
>> > ),
>> > there seems to be a lot of thread synchronization going on, which could
>> > potentially be contributing to a performance degradation. It's hard to
>> say
>> > for sure, though, without doing some actual measurements on it.
>> >
>> > On Wed, Dec 16, 2015 at 8:45 PM, Bhadauria, Tarun Kumar <
>> > tarun.kumar.bhadauria@zalando.de> wrote:
>> >
>> > > Test Summary -
>> > >
>> > > Jmeter Version - 2.13
>> > > Jmeter Machines - 10 AWS EC2 m4.4xlarge instances
>> > > Number of threads on each instance 72 hence in total 720 threads in
>> > > distributed mode
>> > > Test is executed in non GUI mode
>> > >
>> > > I was experimenting with Backend listener as described here
>> > > <http://jmeter.apache.org/usermanual/realtime-results.html> and came
>> > > across
>> > > drastic reduction in throughput against a static html file. These are
>> the
>> > > results are received for 5 minutes test -
>> > >
>> > > Throughput with backend listener - 5000/sec
>> > > Throughput without backend listener - 9800/sec
>> > >
>> > > I have repeated the test over a period of one week and test results
>> have
>> > > been consistent.
>> > >
>> > > I did not see any significant difference in load avg or cpu
>> utilization
>> > on
>> > > load agents with or without backend listener.
>> > >
>> > > Is JMeter performance degradation a known issue with Backend listener?
>> > >
>> >
>>
>>
>>
>> --
>>
>> Regards
>> Ubik Load Pack <http://ubikloadpack.com> Team
>> Follow us on Twitter <http://twitter.com/ubikloadpack>
>>
>>
>> Cordialement
>> L'équipe Ubik Load Pack <http://ubikloadpack.com>
>> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>>
>
>
--
Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>
Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
Re: Backend Listener and reduced throughput
Posted by "Bhadauria, Tarun Kumar" <ta...@zalando.de>.
@Steven
Given that I run test in distributed mode, I was hoping that the controller
machine would push stats to influx db after it receives results from agents
pumping the load and this should not have any impact on test results, but
that does not seem to be the case here Or I missed something.
@UBIK
Where can I set Async Queue Size?
Thanks
Tarun K
On 16 December 2015 at 14:47, UBIK LOAD PACK Support <
support@ubikloadpack.com> wrote:
> Hello,
> Did you try playing with Async Queue Size 5000 might be very short for a
> test that has no timer?
>
> The difference can be explained by many factors:
>
> - Network quality between JMeter and the InfluxDB or Graphite server
> - Number of Samples that you track
> - The queue size, if you test is at high throughput (no timer), then the
> Async Queue Size will slow down compared to no using backend listener.
> - Bear in mind also that Increasing Async Queue Size will increase
> memory footprint
>
> Regards
>
> On Wed, Dec 16, 2015 at 2:38 PM, Steven Swor <sw...@gmail.com>
> wrote:
>
> > Generally speaking, performance degradation is a known issue with all
> > listeners (more processing = more cpu cycles consumed per loop). However,
> > with the GraphiteBackendListener(
> >
> >
> https://github.com/apache/jmeter/blob/v2_13/src/components/org/apache/jmeter/visualizers/backend/graphite/GraphiteBackendListenerClient.java
> > ),
> > there seems to be a lot of thread synchronization going on, which could
> > potentially be contributing to a performance degradation. It's hard to
> say
> > for sure, though, without doing some actual measurements on it.
> >
> > On Wed, Dec 16, 2015 at 8:45 PM, Bhadauria, Tarun Kumar <
> > tarun.kumar.bhadauria@zalando.de> wrote:
> >
> > > Test Summary -
> > >
> > > Jmeter Version - 2.13
> > > Jmeter Machines - 10 AWS EC2 m4.4xlarge instances
> > > Number of threads on each instance 72 hence in total 720 threads in
> > > distributed mode
> > > Test is executed in non GUI mode
> > >
> > > I was experimenting with Backend listener as described here
> > > <http://jmeter.apache.org/usermanual/realtime-results.html> and came
> > > across
> > > drastic reduction in throughput against a static html file. These are
> the
> > > results are received for 5 minutes test -
> > >
> > > Throughput with backend listener - 5000/sec
> > > Throughput without backend listener - 9800/sec
> > >
> > > I have repeated the test over a period of one week and test results
> have
> > > been consistent.
> > >
> > > I did not see any significant difference in load avg or cpu utilization
> > on
> > > load agents with or without backend listener.
> > >
> > > Is JMeter performance degradation a known issue with Backend listener?
> > >
> >
>
>
>
> --
>
> Regards
> Ubik Load Pack <http://ubikloadpack.com> Team
> Follow us on Twitter <http://twitter.com/ubikloadpack>
>
>
> Cordialement
> L'équipe Ubik Load Pack <http://ubikloadpack.com>
> Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
>
Re: Backend Listener and reduced throughput
Posted by UBIK LOAD PACK Support <su...@ubikloadpack.com>.
Hello,
Did you try playing with Async Queue Size 5000 might be very short for a
test that has no timer?
The difference can be explained by many factors:
- Network quality between JMeter and the InfluxDB or Graphite server
- Number of Samples that you track
- The queue size, if you test is at high throughput (no timer), then the
Async Queue Size will slow down compared to no using backend listener.
- Bear in mind also that Increasing Async Queue Size will increase
memory footprint
Regards
On Wed, Dec 16, 2015 at 2:38 PM, Steven Swor <sw...@gmail.com>
wrote:
> Generally speaking, performance degradation is a known issue with all
> listeners (more processing = more cpu cycles consumed per loop). However,
> with the GraphiteBackendListener(
>
> https://github.com/apache/jmeter/blob/v2_13/src/components/org/apache/jmeter/visualizers/backend/graphite/GraphiteBackendListenerClient.java
> ),
> there seems to be a lot of thread synchronization going on, which could
> potentially be contributing to a performance degradation. It's hard to say
> for sure, though, without doing some actual measurements on it.
>
> On Wed, Dec 16, 2015 at 8:45 PM, Bhadauria, Tarun Kumar <
> tarun.kumar.bhadauria@zalando.de> wrote:
>
> > Test Summary -
> >
> > Jmeter Version - 2.13
> > Jmeter Machines - 10 AWS EC2 m4.4xlarge instances
> > Number of threads on each instance 72 hence in total 720 threads in
> > distributed mode
> > Test is executed in non GUI mode
> >
> > I was experimenting with Backend listener as described here
> > <http://jmeter.apache.org/usermanual/realtime-results.html> and came
> > across
> > drastic reduction in throughput against a static html file. These are the
> > results are received for 5 minutes test -
> >
> > Throughput with backend listener - 5000/sec
> > Throughput without backend listener - 9800/sec
> >
> > I have repeated the test over a period of one week and test results have
> > been consistent.
> >
> > I did not see any significant difference in load avg or cpu utilization
> on
> > load agents with or without backend listener.
> >
> > Is JMeter performance degradation a known issue with Backend listener?
> >
>
--
Regards
Ubik Load Pack <http://ubikloadpack.com> Team
Follow us on Twitter <http://twitter.com/ubikloadpack>
Cordialement
L'équipe Ubik Load Pack <http://ubikloadpack.com>
Suivez-nous sur Twitter <http://twitter.com/ubikloadpack>
Re: Backend Listener and reduced throughput
Posted by Steven Swor <sw...@gmail.com>.
Generally speaking, performance degradation is a known issue with all
listeners (more processing = more cpu cycles consumed per loop). However,
with the GraphiteBackendListener(
https://github.com/apache/jmeter/blob/v2_13/src/components/org/apache/jmeter/visualizers/backend/graphite/GraphiteBackendListenerClient.java),
there seems to be a lot of thread synchronization going on, which could
potentially be contributing to a performance degradation. It's hard to say
for sure, though, without doing some actual measurements on it.
On Wed, Dec 16, 2015 at 8:45 PM, Bhadauria, Tarun Kumar <
tarun.kumar.bhadauria@zalando.de> wrote:
> Test Summary -
>
> Jmeter Version - 2.13
> Jmeter Machines - 10 AWS EC2 m4.4xlarge instances
> Number of threads on each instance 72 hence in total 720 threads in
> distributed mode
> Test is executed in non GUI mode
>
> I was experimenting with Backend listener as described here
> <http://jmeter.apache.org/usermanual/realtime-results.html> and came
> across
> drastic reduction in throughput against a static html file. These are the
> results are received for 5 minutes test -
>
> Throughput with backend listener - 5000/sec
> Throughput without backend listener - 9800/sec
>
> I have repeated the test over a period of one week and test results have
> been consistent.
>
> I did not see any significant difference in load avg or cpu utilization on
> load agents with or without backend listener.
>
> Is JMeter performance degradation a known issue with Backend listener?
>