Hi,
We have a new Saga and the number of events that that Saga need to listen is huge. This leads to a large waiting time until Saga finish to process all events.
Is it possible to setup the Saga as multi-thread? If not, which is the reason for that? Because the performance impact is big.
If there is any other configuration to speedup the process I would like to heard about it.
Thanks in advance
Kind regards
Filipe Marques
Interesting question FilipeMarques, if I understand your question correctly: are you implying that a Saga instance sequentially processes it’s events (i.e., Events meant for that Saga instance via an “association key” value) ?
Yes as far I know, a Saga is processing its events sequentially (by default). It will process 1 event from your event store, and will open the Saga(s) instances and does the necessary actions. Then the next event, etc. In the database token entry table you only see 1 event tracker, without multiple segments.
We are wondering if this is correct? If yes, is there a way to process it in a multi-threaded fashion?
Hi Filipe,
“A saga instance is never invoked concurrently by multiple threads. Therefore, a sequencing policy for a saga is irrelevant. Axon will ensure each saga instance receives the events it needs to process in the order they have been published on the event bus.” - https://docs.axoniq.io/reference-guide/axon-framework/events/event-processors#parallel-processing
A regular event handler (supported by Tracking Processors) scales better:
Tracking processors can use multiple threads to process an event stream. They do so by claiming a segment that is identified by a number. Normally, a single thread will process a single segment and the number of segments/threads can be configured in this case.
In comparison to regular Event Handlers, Sagas are persisting the state in some DB. Sagas are stateful. Regular Event Handlers do not persist its state in the DB (they do not have this step), which can influence performances in a positive way. DB operations are expensive.
If you can switch from Sagas to regular Event handlers to achieve the same goal (and implement Saga pattern), it would perform better in my opinion. This can be an easy or hard thing to do, and it depends on how much of the state you keep in your current Saga. If your current Saga keeps mostly associations, then you could use messages (events, commands) to share these associations, rather than keeping the state of the Saga component itself.
I hope this helps,
Ivan
Hi Ivan,
Thanks for your reply.
Event handlers might be a work around, but it’s a pitty that there is not a good testing framework as you have with Sagas. Saving to database etc we as well have to implement ourselves. Not that difficult but a lot of boiler plate code.
Besides of this, I am not sure without having the associations mechanism of sagas that we can determine a good SequenceIdentifier as data is split over two events. We are interested in Event B, but Event B doesn’t contain the sequence identifier at the moment, only a reference ID to Event A with a good candidate we can use as sequenceIdentifier. That’s the main reason we use a Saga as well, to collect the necessary data of multiple events to produce a new event.
I can imagine it’s not a good idea to use (database) state in the SequencingPolicy?
Out of curiosity, can you explain what’s the reason Sagas are never multi-threaded? Are there any improvements planned to boost performance of Sagas?
Kind regards,
Koen