TrackingEventProcessorConfiguration

Imported from Google Groups
#1

Hi guys,

I’m working on an application which uses Axon Framework and I would like to increase number of thread for TrackingEventProcessor.
I did it by using registerTrackingEventProcessorConfiguration method of EventProcessingConfigurer and I set thread count to 15.
I have 5 processors and for every of them only 10 TrackingSegmentWorkers were created.

Is there some maximum number of threads in Axon for TrackingEventProcessor?
Is it possible to change this maximum?
Is it better approach to split event handlers to more processors? (currently I have 3 of them for sagas and 2 processors for all event handlers in classes in same packages)

Thanks in advance for your help.

Kind regards,

Matus

#2

Hi Matus,

note that there are 2 numbers you need to tune:

  • number of threads - which is configured per instance of the Tracking Processor
  • the initial number of segments - which defines the maximum number of concurrently active threads across all nodes.

The number of segments is only used the very first time a processor starts. When no TrackingTokens are available for a specific processor, it will initialize the defined number of segments. You’re probably not seeing more active threads, because all Segments that are available are all claimed, already.
If you want to increase or decrease the number of Segments at runtime, you can use Axon’s Split and Merge functionality to increase and decrease the number of segments, respectively.

Note that a Thread count of 15 on a single processor instance is generally quite high (unless you have many CPUs available).

Hope this clarifies things for you.
Cheers,

twitter-icon_128x128.png

#3

Hi Allard,

we still play with the perfect segments thread number

I have 4 nodes with 2 cpu each. So is the perfect config 8 segments and 8 threads?
We have currently 16 which is 4 threads per node.

We still think the Saga is our bottleneck. We have the highest load during tests there. And we already have a saga cache in place which we think is not relevant as test with and without are basically the same.

Also if we have different process groups (one for querys one for event handlers). Should we split then the numbers by 2. Means not 8 but 4 each?

Best, Michael

#4

Hi Michael,

it’s hard to give advice on the number of segments. It mainly depends on the type of logic your sagas execute. If they spend a lot of time waiting for external systems, it may be worth having more segments. If they spend most time calculating, then the number of segments should be closer to the number of CPUs.

Caching will reduce the time spent on loading sagas, but storing them will still write-through to the underlying storage. Did you configure a batch size on the processor that handles your Sagas? Increasing that may also have a positive impact on performance, especially when multiple events hit the same saga within a batch.

Hope this helps.
Cheers,

#5

Hi Allard,

Thanks for the feedback. Most of the time the saga we only use to store e.g. a cart, address…. To send out an order at the end. The only place where we compute when we do a cart clone.

But very often we only get an event and depending on that we do a or b.

About batch. Yes - we use 20 right now which shows an improvement in the load test.

Also we more and more reduce the data we read from the saga and keep this only as a collector for the final order.

Best, Michael

#6

Hi Allard,

about the batchsize. Any recommendations here? 20, 100, 1000? I did not fully understand this setting. I thought the processors getting the ping from the server when there is something for them. Or do the processors check when there is something todo for them. And if yes - how often?

Best, Michael

#7

Batch size sets the number of events that may be executed as part of the same transaction. Axon doesn’t wait for a batch to be completely full before handling an event. If will only check for the immediate availability of more events once the first event has arrived.

Setting it to an order of magnitude 100 is usually a sensible choice. If you handlers are batch-optimized (i.e. the internally optimize for batching), then setting it to higher values (magnitude 1000) can help improve throughput.

Cheers,

#8

Hi Allard,

thanks. I will do some tests with 100.

Best, Michael