Hi Michael, thanks for your feedback and I will create an epic for this. I will divide into following stories and please let me know if this makes sense
1. quota configuration - metric key and value, format, storage 2. metrics collection and export - storage/rate/watch/connection 3. throttling implementation based on metrics inside server/client On Wed, Jul 17, 2019 at 8:02 PM Michael Han <[email protected]> wrote: > >> a more complete quota/throttling system would be valuable here > > Absolutely. This will improve the stability of a shared zookeeper cluster, > which is a very common use case. Because the lack of enforce quota (and > other soft isolation mechanisms such as flow control / request limiting), > the usual practice of dealing with such excessive client usages is to > provision dedicated ZK cluster per customer which creates additional > operation overheads and is waste of resource. > > >> We'd be happy to submit the work for review > > Sounds great. I would suggest we create an epic around this and then break > down the stories to multiple sub tasks and move existing issues that's > relevant under the epic, so we can consolidate efforts and have a single > place to track the progress. > > > On Tue, Jul 16, 2019 at 12:46 PM Mocheng Guo <[email protected]> wrote: > > > Hi, currently Zookeeper has a storage quota feature which is > informational > > only and there are a few JIRAs to enforce throttling. > > > > ZOOKEEPER-451 > > ZOOKEEPER-2593 > > ZOOKEEPER-3301 > > > > I am wondering if a more complete quota/throttling system covering > metrics > > such as storage/rate/watch/connection would be valuable here? We at FB > have > > been battling with excessive system usage from clients and did some work > in > > this area. We'd be happy to submit the work for review and consolidate > with > > existing efforts if people feel this is a good feature to add. > > > > thanks > > Mocheng > > >
