NealSun96 edited a comment on pull request #1056: URL: https://github.com/apache/helix/pull/1056#issuecomment-639015066
> I have 2 questions, > > 1. What is the expected ZK throughput? It sounds a very scary idea. Note that ZK writes traffic is the current performance bottleneck. > 2. If we are doing this, I suggest doing this as an additional metric reporting channel outside the monitor classes, or even outside the Helix lib. MBean is a generic way to report metrics. To expose that data to any other metric collection system or to ZK is not related to the MBeans. Adding this option and extra logic into the monitors just increase the unnecessary complexity of those classes. 1. Unfortunately I can't answer this question with confidence - as noted in the design doc, @narendly believes this is not a major performance concern; without much context on performance bottleneck myself, I trust @narendly's assessment. In terms of throughput, the syncing happens every time a data point is added to this metric. Lastly, to achieve the goal of "providing metrics on client side", this is the only method I can think of: using ZK. Is there any other good ways to achieve this goal? 2. There isn't any means to access the gauges outside JobMonitor, which is why I placed the logic inside JobMonitor. I don't think adding support for JobMonitor to optionally sync values to Zk is "complexity"; it's just an option. But if you insist, I'm happy to leave the logic to an outer class. I will need to have JobMonitor providing access to the gauges. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
