Hi Clebert!

Before reverting anything I think could be good to perform some tests to be
sure of regressions, AFAIK the are only performance improving, but the final
word I think will go to proper load tests.

Instead, I've already done sanity tests trying to push IOPS over the limits
with the 2 TimedBuffer implementations (old and new one) and both suffer
from the same issue, simply in different ways, but TBH, as I've said before,
is not a big issue: it's more a possible chance of improvement from what we
have now.

The test I'm talking is in this branch (using the original TimedBuffer):
https://github.com/franz1981/activemq-artemis/tree/timed_buffer_iops_test
Is the  shouldNotFlushUntilTimeout test
<https://github.com/franz1981/activemq-artemis/blob/12c34475f16a73d669c3307999e6fa03601c6cb3/tests/unit-tests/src/test/java/org/apache/activemq/artemis/tests/unit/core/journal/impl/TimedBufferTest.java#L137-L137>
 
, but I can build another couples of tests that do something similar and
producing the same effect.

What the test verify is straightforward: a TimedBuffer can't accept 2
flushes to happen before the timeout expiration, because this would force a
disk to perform too many IOPS than expected...and the test fails for both
the TimedBuffer.

As I've said I propose to wait proper load tests before reverting it,
considering that the test shows that the original version was suffering the
same issue.
What do you think?

Franz






--
View this message in context: 
http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-IOPS-Limiter-strategy-tp4725875p4725924.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Reply via email to