jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [jmeter] pmouawad commented on pull request #603: Bug 64558 - Improve performances and throughput of Sample Results by lifting contention on writing SampleResults in CSV/XML
Date Mon, 06 Jul 2020 07:36:27 GMT

pmouawad commented on pull request #603:

   > My concerns are:
   >     1. "marker interfaces". The pattern was invented long ago when no other means
were possible. Now we can have annotations and other means that enable better metadata tracking.
Marker interfaces do make the maintenance more complicated, and it not clear why do you add
interfaces to "sample listeners" only. For instance, do you intend to create "JMeterThreadBound..."
for every JMeter component class type? Then we'll end up in 100 useless interfaces.
   As I said I am ok to switch to annotation in this case.
   > Then, as we move to async-based test plan execution, the notion of `JMeterThreadBound`
would be even mooter.
   >     1. The test you use looks contrived. Does the change produce noticeable improvement
for, say, HTTP testing?
   > I see you observe improvements like 1M -> 1.7M requests/sec when doing no-op test.
Ok. What is the number of requests per second you can achieve on the same machine with a single
HTTP sampler (or HTTP + regexp extractor)? Is it 10K/sec?
   the No-op test is to only test the throughput of writing. 
   If I do a test with HTTP then it will involve other parameters.
   > Then the maximum possible rate after the improvement would be `1/(1/10K-1/(1.7M-1M))`
== 10.1K/sec. Of course, I might be wrong, but it would be surprising if the end-users would
observe more than say 2-5% improvement.
   The contention was really faced in a real life test with real HTTP test.
   The impact on test is very important and breaks the simulation. It's not only about throughput.
   Did you try the PR build ? 
   From where do you get this 2-5% improvements number ?
   > Of course, we can always rework or even undo the change, however, adding interfaces
like `JMeterThreadBoundSampleListener` to the public API looks super weird.
   Ok,let's stick to annotations then

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:

View raw message