-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Commit method respond slow (was: Make poll interval adaptive) #128
Comments
Could you elaborate why we might want to do this? Are you running into any problems with the current behaviour? |
Sure, this is primarily related to performance with
All timestamps will differ with 100ms (default poll interval):
That is because commit
and if zero:
Zero is good but it will lead to continuous load for polling. While 100ms is too slow when there are a lot of data. Therefore I suggest to be adaptive to number of events and e.g. continue processing events non-stop (or Task.yield()) while KafkaClient provide them and tweak time between sleep within some min/max interval.
At the same time, if there are no event or they are not often, interval will be adjusted to corresponding message/offset commit rate. If compare time just for 100 messages and default pollInterval the difference for test time will be the following (I've modified test 'testProduceAndConsumeWithMessageHeaders' for 100 events and time measurement before/after loop).
For fixed poll interval (20ms):
For fixed poll interval (1ms):
For zero:
For adaptive (with max 100ms):
For adaptive (with max 20ms):
For adaptive (with max 1ms):
For adaptive (with max 0ms) - just for sanity
So, that should allow to maintain low cpu usage when there are a small number of events (make rare polls) and be pro-active when there are spikes of data. |
I've renamed the issue to the problem that we see. While benchmark infrastructure is on the way, I wrote couple of tests within not merged infrastructure. There are some results, with current swift-kafka-client implementation. Results:
With adaptive poll. Sources can be found at: https://github.com/ordo-one/swift-kafka-client/tree/perf-consumer-with-backpressure--adaptive Results:
The difference is about 2 times by wall clock and 1.5 by cpu time. |
Currently, even if there are move than 100 events (which is hardcoded), we won't continue polling but call
Task.sleep()
which seems pretty strange.I would like to suggest some adaptive polling interval, which would be depending on events: e.g.:
The idea is to then adjust polling time the following way:
That might be also useful to adjust events size but not sure if it is feasible.
The text was updated successfully, but these errors were encountered: