Good day all, I have a few questions. We are using Kafka as an underlying message source for a microservice that utilizes Axon’s Saga support. We are seeing less than desirable perf test throughput when using a SEP.
When using subscribing mode, is there any way to scale event processing processing aside deploying multiple instances, increasing topic partitions, setting ScribibleKafkaMessageSource.Builder.consumerCount to match the number of partitions?
As per my understanding, using tracking mode while configuring an initial-segment-count/thread-count is a way to scale within an instance itself, however I came across this post and wondered if using Axon Server is a requisite having the scaling work. With a JPA backend, I see the token_entry table with multiple entries, one for each segment. I just want to verify this functionality is present without Axon Server in v4.1+.
When using a TEP, can you scale out your instances horizontally without worry? I’m pretty sure this is a yes, but I want to verify.
Is it advisable to use only SEP or TEP for both producing and consuming or can you comfortably have both within the same JVM?
I’m wondering if any of the following settings can help improve performance as well.
- Using a TRANSACTIONAL confirmation-mode and setting DefaultProducerFactory.Builder.producerCacheSize(). If the confirmation-mode is NONE, will setting the cache size have any effect?
- Using a FullConcurrencyPolicy where multiple threads may be spun up.
- Lastly, we’re developing a custom CassandraTokenStore but are facing issues with TEP and we’re noticing duplicate entries in the token_entry table. Surely the implementation needs review, but from an Axon perspective, is there an inherit reason the TEP API wouldn’t work well with a Cassandra based token store (e.g. locking, ACID vs BASE)?
Thanks to all participating in advance!