I'm happy that no evident regressions due to the new implementation were found: IMHO only feedback and proper tests will give a baseline to reason on it and improve the options to the end users.
I've a couple of results with an all out throughput test anyway, but it is not representative of any production use case; it is simply a crash test. No real system AFAIK (maybe trading ticks) send infinite burst of durable data with all out throughput AND expecting to have exceptional latencies too: see "How NOT to Measure Latency" by Gil Tene - Safely sustainable throughput example <https://youtu.be/lJ8ydIuPFeU?t=1686> . Instead, what I'm expecting is the measurement of the level of service quality (eg end to end responsiveness) under different production load profiles (eg using a target throughput or with message scheduling reflecting real production use). Anyway, the results are not bad at all: the new TimedBuffer behaves pretty well (with and without the IO limiter) even when a disk is being maxed out. Just as comparison, it provides slightly better throughput (>30% with ASYNCIO) with a similar latency profile of the original one, as stated in the first posts: <http://activemq.2283324.n4.nabble.com/file/n4726119/image_%282%29.png> <http://activemq.2283324.n4.nabble.com/file/n4726119/image_%283%29.png> My only concern is that I was expecting a little worse results by it and that' s why I've discussed about using an IO limiter on it (adapting the existent TokenXXX would be cool, kudos to Clebert about it)... -- View this message in context: http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-IOPS-Limiter-strategy-tp4725875p4726119.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
