CODEWITHSUNDEEP
jmeter
Tarun
Tarun

Reputation: 3496

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 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?

Upvotes: 1

Views: 1573

Answers (2)

UBIK LOAD PACK
UBIK LOAD PACK

Reputation: 34536

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

Upvotes: 0

RaGe
RaGe

Reputation: 23707

Hmm, interesting. Could it be that the additional time required to do the backend write means that 1 iteration takes a bit longer to complete, which in turn would mean a drop in throughput per thread? Since you're keeping the number of threads constant, your overall throughput would, as a result, drop a bit.

Here's an experiment I would conduct: Turn off backend listener, but put a 500ms constant timer in your test threads. Does it result in an overall throughput drop?

Upvotes: 0

Related Questions