Hi, David, Thanks for the KIP. A few quick comments.
1. About quota.partition.mutations.rate. I am not sure if it's very easy for the user to set the quota as a rate. For example, each partition mutation could take a different number of ZK operations (depending on things like retry). The time to process each ZK operation may also vary from cluster to cluster. An alternative way to model this is to do sth similar to the request (CPU) quota, which exposes quota as a percentage of the server threads that can be used. The current request quota doesn't include the controller thread. We could add something that measures/exposes the percentage of time that a request ties up the controller thread, which seems to be what we really care about. 2. Is the new quota per user? Intuitively, we want to only penalize applications that overuse the broker resources, but not others. Also, in existing types of quotas (request, bandwidth), there is a hierarchy among clientId vs user and default vs customized (see https://cwiki.apache.org/confluence/display/KAFKA/KIP-55%3A+Secure+Quotas+for+Authenticated+Users ). Does the new quota fit into the existing hierarchy? 3. It seems that you are proposing a new quota mechanism based on Token Bucket algorithm. Could you describe its tradeoff with the existing quota mechanism? Ideally, it would be better if we have a single quota mechanism within Kafka. Jun On Fri, Apr 24, 2020 at 9:52 AM David Jacot <dja...@confluent.io> wrote: > Hi folks, > > I'd like to start the discussion for KIP-599: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-599%3A+Throttle+Create+Topic%2C+Create+Partition+and+Delete+Topic+Operations > > It proposes to introduce quotas for the create topics, create partitions > and delete topics operations. Let me know what you think, thanks. > > Best, > David >
