queueDepth

The size of the ring buffer.

This knob controls the size of the ring buffer. It is best to choose a power of 2 for ring buffer. The buffer should be sized large enough to absorb spikes in application traffic without blocking the offering thread, but otherwise should generally be kept small enough to keep the amount of active data in the pipeline small enough to avoid taxing CPU caches.

The default size for most disruptors is 1024.

queueWaitStrategy

Controls how the thread draining events from the ring buffer waits for more events. One of BusySpin|Yielding|Sleeping|Blocking.

For applications that want the lowest latency possible using BusySpin causes the draining thread to spin without signally to the OS that it should be context switched which avoids jitter. This policy is most appropriate when the number of cores available in the machine is adequate for each reader to occupy its own core. Otherwise, a Yielding wait strategy can be used. Both BusySpin and Yielding are CPU intensive and are most appropriate for applications where performance is critical and run on hardware dedicated to the application.

queueDrainerCpuAffinityMask

queueOfferStrategy

The engine thread that dequeues and dispatch application messages and events. This is the main application thread on which application events are dispatched. They are suffixed with a global counter to allow differentiating between stats emitted by multiple instances of the same application running in the same JVMAep.

The detached threads described outlined below can offload work from this thread which can improve throughput and latencies in your application.

Note that when running in an XVM you will see AEP engine threads created for the XVM's admin application which is used to handle XVM admin requests.

When the application is configured with a detached outbound message logger, this thread offloads the work of writing to disk from the engine's input multiplexer which can serve as a buffer against disk I/O spikes.

When the application is configured with a detached per transaction stats logger, this thread offloads the work of writing to disk from the engine multiplexer which can serve as a buffer against disk I/O spikes.

 If your application's transaction load is not high, a detached per transaction stats logger message logger may not be needed. The cepilo (commit epilogue) transaction latency statistic covers per transaction stats logging costs. High values or spikes in cepilo is an indicator that a detached per transactions stats logger can help.

When the bus is configured for detached send, this thread offloads the work of serialization and writing of outbound messages from the engine's input multiplexer which serves as a buffer against spikes caused by message bus flow control.

 High values in the 'o2p, s, s2w, ws' message bus bindings stats are indicators that a detached bus sender can improve performance  

Each bus configured for your application is managed by a Bus Manager internal to the AEP engine.

Handles establishment of the bus connects and reconnects.

The IO thread for the store which is used to read replication traffic from cluster peers.

When the store is configured for detached persistence, this thread offloads the work of writing recovery data to disk from the engine's input multiplexer which can serve as a buffer against disk I/O spikes.

 High values in the 'pers' (persistence) store binding stats is an indicator that a detached store sender can improve performance.

When the store is configured for detached send, this thread offloads the work of writing recovery data to the network for backup instances from the engine's input multiplexer which can serve as a buffer against network I/O spikes.

 High values in the 's2w' (serialize to wire) store binding stats is an indicator that a detached store sender can improve performance.

When the store is configured for detached dispatch, this thread allows the store reader thread to offload work of dispatching deserialized replication traffic to the engine for processing this is useful in cases where the cost of deserializing replication traffic is high.

 A high value for the store binding deserialize stat ('d'), can indicate that setting this property could improve throughput or latency.

Each discovery provider that is opened will create a timer thread that will periodically wake up to perform discovery broadcasts.

Each discovery provider typically will create additional threads specific to the discovery provider type. For example, when using an SMA-based discovery provider, message bus binding threads will be created.

When the server is configured for multithreading, additional IO threads beyond the XVM main thread are created that service connections that are affinitized to it.

 When using the direct binding the IO thread is on the critical path for received messages.