Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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
