Add experimental alternative fetch strategies #970
Conversation
erikvanoosten
force-pushed
the
more-fetch-strategies
branch
from
5c3bac7 to
deb81f3
Compare
erikvanoosten
force-pushed
the
more-fetch-strategies
branch
from
b479904 to
556d421
Compare
1. `ManyPartitionsQueueSizeBasedFetchStrategy`, a variation on the default `QueueSizeBasedFetchStrategy` which limits total memory usage. 2. `PredictiveFetchStrategy` an improved predictive fetching strategy (compared to the predictive strategy from zio-kafka 2.3.x) which uses history to calculate the average number of polls the stream needed to process, and uses that to estimate when the stream needs more data.
erikvanoosten
force-pushed
the
more-fetch-strategies
branch
from
f92b8b2 to
b6d9d7a
Compare
|
|
|
|
||
| import scala.collection.mutable | ||
|
|
||
| /** |
There was a problem hiding this comment.
Number of polls is quite a discrete measurement, what do you think of converting this into a running average (like exponentially weighed moving average) of the number of records dequeued each poll?
There was a problem hiding this comment.
That will work against people that use something like Grafana. First you need to collect and sum the raw counters from each instance of your service. Then, and only then, you can calculate a running average, an integral, or whatever other operation.
|
@erikvanoosten Shall we close this PR? It's well over a year old now |
Sure. I have put a lot of effort in |
ManyPartitionsQueueSizeBasedFetchStrategy, a variation on the defaultQueueSizeBasedFetchStrategywhich limits total memory usage.PredictiveFetchStrategyan improved predictive fetching strategy (compared to the predictive strategy from zio-kafka 2.3.x) which uses history to calculate the average number of polls the stream needed to process, and uses that to estimate when the stream needs more data.To do: