[
https://issues.apache.org/jira/browse/ARTEMIS-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883015#comment-15883015
]
Justin Bertram commented on ARTEMIS-994:
----------------------------------------
[~michael.andre.pearce], I have no reason to disagree with Clebert here, and I
don't doubt that native epoll is relatively faster than Java NIO. However, I'm
curious about any actual performance data you may have collected because
Artemis is, of course, comprised of many more components than just a Netty
transport and those components interact with each other and impact performance
in different ways for different use-cases. For example, when Clebert
implemented the libaio integration there was clear data to indicate that the
disk was a performance bottleneck for certain use-cases. In fact, for most
use-cases involving durable messages the disk is the main performance limiter.
To reiterate, I'm not really concerned with Netty-specific performance data.
I'm interested in Artemis-specific performance data (e.g. use-cases, test
methodology, results, performance goals, etc.) which identified the Netty
transport as the main performance limiter (i.e. bottleneck). I think anything
you could provide here would be helpful to me as a developer and also to those
in the wider community who will be or are now chiefly concerned with
performance.
> Support Netty Native Epoll on Linux
> -----------------------------------
>
> Key: ARTEMIS-994
> URL: https://issues.apache.org/jira/browse/ARTEMIS-994
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Affects Versions: 2.0.0, 1.5.3
> Reporter: Michael Andre Pearce (IG)
>
> Netty has support for native epoll, this is available only on linux systems.
> This is more performant.
> http://netty.io/wiki/native-transports.html
> This is inline with supporting asyncio with libaio using such native feature
> to bring perfomance benefits to artemis.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
