Hey Rajini, Thanks for the KIP. I have some questions:
- I am wondering why throttling based on request rate is listed as a rejected alternative. Can you provide more specific reason why it is difficult for administrators to decide request rates to allocate? It seems to me that determination of request rate is not any more difficult than determination of request rate as both metrics are commonly used to measure performance and provide guarantee to user. On the other hand, the percentage of processing time provides a vague guarantee to user. For example, what performance can user expect if you provide 1% processing time quota to this user? How is administrator going to decide this quota? Should Kafka administrator continues to reduce this percentage quota as number of users grow? - The KIP suggests that LeaderAndIsrRequest and MetadataRequest will also be throttled by this quota. What is the motivation for throttling these requests? It is also inconsistent with rate-based quota which is only applied to ProduceRequest and FetchRequest. IMO it will be simpler to only throttle ProduceRequest and FetchRequest. - Do you think we should also throttle the inter-broker traffic using this quota as well similar to KIP-73? Thanks, Dong On Fri, Feb 17, 2017 at 9:05 AM, Rajini Sivaram <rajinisiva...@gmail.com> wrote: > Hi all, > > I have just created KIP-124 to introduce request rate quotas to Kafka: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-124+-+ > Request+rate+quotas > > The proposal is for a simple percentage request handling time quota that > can be allocated to *<client-id>*, *<user>* or *<user, client-id>*. There > are a few other suggestions also under "Rejected alternatives". Feedback > and suggestions are welcome. > > Thank you... > > Regards, > > Rajini >
