activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <clebert.suco...@gmail.com>
Subject Re: [DISCUSS] Artemis IOPS Limiter strategy
Date Fri, 12 May 2017 16:37:06 GMT
There is a class we use on producer.  TokenLimiter.  Perhaps you could
reuse that one ?


On Fri, May 12, 2017 at 11:00 AM nigro_franz <nigro.fra@gmail.com> wrote:

> I was thinking of a similar solution but I've discovered that couldn't work
> (in the old or the new TimedBuffer too), because of the
> TimedBuffer::checkSize method that could force a flush if the batch buffer
> if not big enough to receive new data, going IOPS.
> Sadly TimedBuffer::checkSize is outside any timeout, but depends on the
> writers.
>
> That's why I've implemented the "compensation" right after any flush, in
> order to work with forced flushes too:
>
>
> https://github.com/franz1981/activemq-artemis/blob/4b831021dab3e0dd276f477e3ea665e11ab54d0e/artemis-journal/src/main/java/org/apache/activemq/artemis/core/io/buffer/TimedBuffer.java#L338
>
> Doing it on TimedBuffer::flush all the flushes on disk will be compensated
> (half of the story: ASYNCIO is async so depends on libAIO partially!)
> Regarding the IOPS computation I've built this, as you've suggested:
>
> https://github.com/franz1981/activemq-artemis/blob/4b831021dab3e0dd276f477e3ea665e11ab54d0e/artemis-journal/src/main/java/org/apache/activemq/artemis/core/io/buffer/TimedBuffer.java#L119
>
> The performance seems pretty good, it compensates well but it is faster
> than
> the original version, limiting IOPS too!
>
> Thanks,
> Franz
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-IOPS-Limiter-strategy-tp4725875p4726057.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
-- 
Clebert Suconic

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message