jiajunwang commented on pull request #1056:
URL: https://github.com/apache/helix/pull/1056#issuecomment-639033501
> > 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.
1. Then the problem is how you can convince us : ) This current explanation
is not satisfying, to be frank. Please schedule a meeting so we can talk
offline.
2. Please check how we are using MBeanServer in our code base. That is the
way. "complexity" means,
- The JobMonitor will be a larger file. And there are 2 systems of
reporting mechanism inside one class.
- MBean is the generic mean for Java process to report it's status. The
emitting part should be built above that. If you mixed emitting part with the
MBean, it definitely makes it harder to understand.
- If you want to add this type of support to the other monitors, you
will need to do this again. However, if you do this outside as service, then
you just need to register your MBean there. I guess no more than 10 lines of
change given the ZK based metric emitting service is designed well.
----------------------------------------------------------------
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]
