Support autocommit interval < 100ms about franz-go HOT 7 CLOSED

Thanks @twmb. We've some workloads where we tune for lower latency (financial transactions) at the expense of CPU. It's a careful trade-off. Either way, I think it isn't ideal for a client lib to impose opinionated config when the spec allows it, except for sanity checking config values. In that case, commit should ideally be the minimum practical value, something like 1ms.

from franz-go.

Hello! Yes this is possible, but I’m curious what the use case is here? I worry about the ramifications of consumers committing up to 1000x / second.

from franz-go.

Is the goal to rely on autocommitting but try to commit frequently enough that you avoid the risk of losing data in the event of a server crash? Just trying to understand the use case, and I'm happy to drop this to 1ms (as pointed out, this is a two character patch in the code 😄), I know somebody else ran into problems with another client where their consumers were committing 10,000x / sec / client, which caused undue load on their brokers.

from franz-go.

Is the goal to rely on autocommitting but try to commit frequently enough that you avoid the risk of losing data in the event of a server crash?

It's to get a message pushed to the stream with the lowest possible latency. Realistically, it won't be a 1ms interval but probably around 5-10ms (as mentioned earlier, at the cost of CPU). With a 100ms commit interval, the latency for messages written can vary from ~1 to 100ms; wild standard deviation which wouldn't be acceptable for workloads where latency is a critical metric.

Either way, these decisions should be left to the implementer. Not ideal for neutral client lib to enforce opinionated values.

And, thanks for the lib! 🚀 We've found that it uses significantly less CPU and RAM compare to other Go Kafka libs.

from franz-go.

The autocommitting is unrelated to producing and consuming, so it is unrelated to the latency of messages written. Is there an external system monitoring the commits / waiting for commits before consuming (i.e., is this trying to be similar to EOS but not quite)?

Again, the change is simple and I will be making it, but I'm trying to figure out what the use case here. It can help me potentially add documentation on why a lower value may be chosen, for example.

from franz-go.

Ah, sorry, we have the wires crossed here! I've been referring to the producer commit / flush frequency all along. We've a generic stream config abstraction on top of franz, hence the confusion with terms. Consumption autocommit is a non-issue for us.

Please close this issue. That said, I guess the original argument still stands, that the value should ideally be left to the implementer to configure. Thanks for your time!

from franz-go.

Cool. I may leave the min setting for now then until I somebody points out a workflow where it is necessary to drop the min autocommit interval—this is the type of thing that I think people may confuse and then break their cluster a little bit. The configuration knob you’re looking for is Linger, which there is no default (no lingering at all), and if you do configure, there is no minimum, only a maximum (1min).

Currently I think if a person is looking for autocommitting less than 100ms they may prefer just using manual comitting, because looking for autocommitting less than 100ms to me implies looking for some behavioral guarantees that autocomitting just inherently cannot provide.

However! It may still be useful to drop to 10ms or 1ms min, I just want to know a valid use case before I do so so that I can include a bit of documentation for why a person may want a small autocommit. So I agree it can be left to the implementer, but having a higher min at the moment may be the forcing function for a person to notify me of what I can add for documentation. What do you think?

from franz-go.