Jack Vanlightly continues a series on Dimster. First up is a benchmark of consumer groups versus share groups:
In this first share group benchmarking post, we’re going to use share groups as they are not intended to be used, but for a good reason. Share groups allow you to move past partitions as the unit of parallelism by allowing multiple consumers to read from the same partition, using message queue semantics. We’ll run those kinds of tests in the next post. In this post I just want to understand if the mechanics of how share groups work add any additional overhead compared to consumer groups. So we’ll use share groups as if they were consumer groups (by capping consumer count to partition count).
Objective: Use synthetic tests to measure the overhead of share groups compared to consumer groups in identical conditions.
After that, Jack simulates processing time:
In this post we’re going to simulate processing time in the consumers to make these benchmarks more realistic and show the utility of share groups (namely the ability to parallelize processing beyond the partition count).
We’ll see how the following two configurations play an important role in parallelizing consumption with share groups:
- max.poll.records (consumer config)
- group.share.partition.max.record.locks (broker-side config)
And there’s one more post in the series so far:
In the last post we used simulated consumer processing time to reveal how important it is to set an appropriate value for max.poll.records to ensure the consumer parallelism that we expect. With a uniform distribution of messages over partitions, the rule of thumb was a value somewhat lower than:
group.share.partition.max.record.locks / number of consumers per partition
But there’s more to parallel consumption than max.poll.records. The size of producer batches also plays a role when using the default share.acquire.mode (batch_optimized).
Stay tuned for the next post in the series.