pmouawad commented on pull request #602: URL: https://github.com/apache/jmeter/pull/602#issuecomment-650604266
> > is always in our tests when the storage becomes full > > Well, technically speaking, you produce too many samples and the writer can't cope with them. I made samples with 10ms pause and ones with no pause. Fulling the Queue will surely happen right ? In this case it is ok for me to block until queue is consumed. > > It does not look like ABQ/Disruptor/JCTools can magically make the writer faster. > Yes but where ABQ seems to have a "stable" behaviour, Disruptor varies a lot from one computer to another. We have different results depending on machine and in my case (MacBook Pro (Retina, 15-inch, Mid 2015), 2,5 GHz Intel Core i7, ) For JCTools , I was not able to find a good way to handle full queue in an efficient way, maybe you have better ideas. At least on my computer: - No improvement seen with Disruptor - No improvement seen with JCTools - Stable and reproducable 69% increase in throughput with 2000 threads, queue of 524288, 0ms pause > Can you please clarify the hardware you used for the test? I see you are launching 3000 threads non-stop. What is the number of CPUs you have? > MacBook Pro Retina, 15-inch, Mid 2015, 2,5 GHz Intel Core i7, 8 cores AFAIU Default JMeter settings for Java > As we can't make the "result saver" / "result processor" infinitely fast, we might want to allow to use multiple threads for result processing. > Yes, but what level of CPUs can we consume for handling SampleResults writing vs requesting ? > WDYT? ---------------------------------------------------------------- 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: [email protected]
