We are using Axon Server version 2025.0.1.
From the interface, I filtered events with this query to see their size:
select (length(payloadData) as length, payloadType, formatDate(timestamp, "yyyy/MM/dd HH:mm") as time)
| payloadType contains "X"
However, for the same event type, I sometimes see different sizes.
Is there a way to get the event with the largest payload size?
There is no ascending or descending operation in Axon Sever’s query language I am afraid. Hence, your easiest way forward would be to perform a simple “greater than {some-value}” task step by step, until you’ve found the largest.
By the way, do note that the length operation returns the number of characters the payloadData contains! Hence, it is not the stored size, strictly speaking. Although you might already know, I figured it would be important to stress this point regardless.
Thanks, @Steven_van_Beelen
Is there a way to retrieve the stored size of the event?
Sure thing, @Aymen_Kanzari!
Sadly, there is not such a feature.
For Axon Server, the stored size can differ slightly, depending on the amount of events in a transaction. Is it just one event? Then the event is paired with its own transaction headers. Are you publishing several events in one go, they get lumped together in one transaction, thus with one set of headers.
Anyhow, long story short, it’s not functionality that currently exists. So, let me ask you a follow-up: What do you need the stored size of a specific event for?
To follow up on my original intent:
We are exploring the performance impact of event size in our Axon-based system (using Axon Server version 2025.0.1).
So here’s the core question:
Is there any performance recommendation or practical limit on the number of characters in an event?
For example, will an event with a payload of ~199,999 characters perform significantly worse (in terms of publishing, storing, and replaying) compared to one with ~1,500 characters?
I know Axon Server stores events efficiently, but I wonder if very large events (even just textual data) could negatively impact:
Event store write/read throughput
Event processor handling time
Replay performance
Are there any known thresholds, or best practices around event size we should follow?
There is little performance impact in using larger events in Axon Server. Of course, it takes slightly more time to transfer a larger event across the network and to read/write to disk, but this should be minimal, unless you increase the size to many MB.
There is one limit to consider, which is the maximum message size in Axon Framework and in Axon Server. This limit is set to 4MB by default, but can be increased if you want to send messages that are larger. Note that you have to configure this both in the framework application (axon.axonserver.max-message-size) and for Axon Server (axoniq.axonserver.max-message-size).
I understand that Axon Server (and Axon Framework) has a default max message size of 4MB, and this can be configured via:
Now I’d like to know, how can we programmatically or operationally detect when an event exceeds this limit?
More specifically:
Does Axon Framework throw a specific exception when the payload is too large?
Is there a way to calculate or estimate the serialized size of an event before sending it?
Would Axon Server log this kind of issue? If so, where?
We’d like to avoid runtime surprises and potentially add validation or logging before publishing large events.
Also, while reading the Axon Server 2024 upgrade documentation
This leads me to a few additional questions:
What exactly is the “Control DB” used for in Axon Server?
Is it possible to encounter a situation where the H2 database becomes full or saturated?
Is it possible to replace the H2 database used for the Control DB with something else, such as PostgreSQL?
Are events also stored in this H2 database, or somewhere else?
We have actually added a component for that exact purpose in 4.11.0 of Axon Framework, called the GrpcMessageSizeInterceptor. Axon Framework automatically configures this gRPC interceptor within the AxonServerConnectionManager, ensuring that every connection with Axon Server has this logging interceptor.
So, if you’re on a recent version of Axon Framework, @Aymen_Kanzari, you should be good in that regard!