[
https://issues.apache.org/jira/browse/ARTEMIS-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-3335:
------------------------------------
Description:
ARTEMIS-3303, ARTEMIS-3289 and ARTEMIS-3045 shown how much it is worth
improving the mechanical sympathy of broker, regardless specific hardware.
A well tuned broker can easily improve performance and helping users exposing
the right hooks to perform programmatically and/or automatically such tuning is
a nice addition and traction for high-performance scenarios.
Thread affinity plays a big role on this and there are already Apache libraries
that could help setting it for specific thread pools in the broker (global
thread pool, I/O thread pool, netty acceptor thread pools, netty connector
thread pools, timed buffer thread, ASYNCIO background thread etc etc) e.g.
https://github.com/OpenHFT/Java-Thread-Affinity
There are other projects that employ an ad-hoc affinity strategy e.g.
Hazelcast, failback to OpenHFT one in case HZC one cannot be used: the reason
for that is that OpenHFT requires some dependencies and settings in order to
work.
HZC strategy is pretty basic and it allows to configure the application using a
system property in order to use a limited set of cores that the application is
going to "distribute" to each of the application threads; this strategy is
sub-optimal for our use cases because:
* requires users to know their CPU topology upfront in order to feed the right
one to the application
* Artemis has very different types of Threads: Netty acceptor/connectors, I/O,
global, Timed Buffer and ASYNCIO poller, scheduled timed: some use long-living
threads while other not; just "distributing" the provided list of cores to them
isn't enough to guarantee best performance eg TimedBuffer and ASYNCIO poller
doesn't make sense will end up using the same thread of a Netty acceptor(!)
was:
https://issues.apache.org/jira/browse/ARTEMIS-3303,
https://issues.apache.org/jira/browse/ARTEMIS-3289 and
https://issues.apache.org/jira/browse/ARTEMIS-3045 shown how much it worth to
improve the mechanical sympathy of broker, regardless specific hardware.
A well tuned broker can easily improve performance and helping users exposing
the right hooks to perform programmatically and/or automatically such tuning is
a nice addition and traction for high-performance scenarios.
Thread affinity plays a big role on this and there are already Apache libraries
that could help setting it for specific thread pools in the broker (global
thread pool, I/O thread pool, netty acceptor thread pools, netty connector
thread pools, timed buffer thread, ASYNCIO background thread etc etc) eg
https://github.com/OpenHFT/Java-Thread-Affinity
There are other projects that employ an ad-hoc affinity strategy eg Hazelcast,
failback to OpenHFT one in case HZC one cannot be used: the reason for that is
that OpenHFT requires some dependencies and settings in order to work.
HZC strategy is pretty basic and it allows to configure the application using a
system property in order to use a limited set of cores that's the application
is going to "distribute" to each of the application threads; this strategy is
suboptimal for our use cases because:
* requires users to know their CPU topology upfront in order to feed the right
one to the application
* Artemis has very different types of Threads: Netty acceptor/connectors, I/O,
global, Timed Buffer and ASYNCIO poller, scheduled timed: some use long-living
threads while other not; just "distributing" the provided list of cores to them
isn't enough to guarantee best performance eg TimedBuffer and ASYNCIO poller
doesn't make sense will end up using the same thread of a Netty acceptor(!)
> Improve Artemis Thread affinity
> -------------------------------
>
> Key: ARTEMIS-3335
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3335
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker, Configuration
> Reporter: Francesco Nigro
> Priority: Major
>
> ARTEMIS-3303, ARTEMIS-3289 and ARTEMIS-3045 shown how much it is worth
> improving the mechanical sympathy of broker, regardless specific hardware.
> A well tuned broker can easily improve performance and helping users exposing
> the right hooks to perform programmatically and/or automatically such tuning
> is a nice addition and traction for high-performance scenarios.
> Thread affinity plays a big role on this and there are already Apache
> libraries that could help setting it for specific thread pools in the broker
> (global thread pool, I/O thread pool, netty acceptor thread pools, netty
> connector thread pools, timed buffer thread, ASYNCIO background thread etc
> etc) e.g. https://github.com/OpenHFT/Java-Thread-Affinity
> There are other projects that employ an ad-hoc affinity strategy e.g.
> Hazelcast, failback to OpenHFT one in case HZC one cannot be used: the reason
> for that is that OpenHFT requires some dependencies and settings in order to
> work.
> HZC strategy is pretty basic and it allows to configure the application using
> a system property in order to use a limited set of cores that the application
> is going to "distribute" to each of the application threads; this strategy is
> sub-optimal for our use cases because:
> * requires users to know their CPU topology upfront in order to feed the
> right one to the application
> * Artemis has very different types of Threads: Netty acceptor/connectors,
> I/O, global, Timed Buffer and ASYNCIO poller, scheduled timed: some use
> long-living threads while other not; just "distributing" the provided list of
> cores to them isn't enough to guarantee best performance eg TimedBuffer and
> ASYNCIO poller doesn't make sense will end up using the same thread of a
> Netty acceptor(!)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
