Increase max ConsumerWorkService block size to 256#814
Merged
Conversation
As suggested in #813. This has a few minor effects on consumers: * A low single-digit % throughput gain * A comparable reduction in mean consumer latency In general, it makes sense that consumers operating at peak throughput should run operations in blocks close to the QoS prefetch used. Since we usually recommend a value of 100-300 for environments that focus on throughput, the new default of 256 makes sense. The only negative effect I can think of a slightly higher GC pressure which can increase variability of the aforementioned metrics.
lukebakken
approved these changes
Jul 23, 2022
lukebakken
left a comment
Collaborator
There was a problem hiding this comment.
Wait for a 👍 from @acogoluegnes on this one!
acogoluegnes
approved these changes
Jul 25, 2022
Contributor
|
I did not notice any significant nor reproducible improvement after some local testing, but this block size is better aligned with our QoS recommendations, so I'm OK to merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As suggested in #813. This has a few
minor effects on consumers:
In general, it makes sense that consumers operating at peak throughput
should run operations in blocks close to the QoS prefetch used.
Since we usually recommend a value of 100-300 for environments that
focus on throughput, the new default of 256 makes sense.
The only negative effect I can think of a slightly higher GC pressure
which can increase variability of the aforementioned metrics.
Using development builds with PerfTest
To install a development version of this client locally, use
then change PerfTest dependency in
pom.xmlto use6.0.0-SNAPSHOTor whatever versionyou designate to this PR locally, and produce an uberjar:
then run it like so
java -jar ./target/perf-test.jar --queue block-size-256 -x 1 -y 2 --qos 256 --id "block-size-256"and compare it to a GA version, e.g.