[
https://issues.apache.org/jira/browse/STORM-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14732162#comment-14732162
]
ASF GitHub Bot commented on STORM-1007:
---------------------------------------
Github user wangli1426 commented on the pull request:
https://github.com/apache/storm/pull/716#issuecomment-138027523
Hi @HeartSaVioR,
I am glad to explain the mechanism of RateTracker as follows.
In general, RateTracker provides a way to monitor the rate of certain
event. We notify RateTracker upon the occurrence of the event by calling
```notify()``` method, and call ```reportRate``` to retrieve the instantaneous
rate of the event.
The rate is calculated as ```counts of occurrence``` / ```time```. As
RateTracker reports instantaneous rate, it only maintains the counts of
occurrences within a given period of time as specified by
```validTimeWindowInMils```. This is implemented by dividing the
```validTimeWindowInMils``` into ```numOfSlides``` time slides and employing a
timer to periodically (every ```validTimeWindowInMils```/ ```numOfSlides```
milliseconds) clean the count in the oldest time slide.
Finally, RateTracker is very efficient. First, ```notify()``` only does
addition on a count and thus can be finished within few CPU cycles. Second, the
update of the counts is also light-weight and only happens periodically, e.g.,
every 1 or 2 seconds. Third, all the instances of RateTracker share the same
timer, avoiding using too many threads.
If you have further question, please let me know.
Thanks.
> Add more metrics to DisruptorQueue
> ----------------------------------
>
> Key: STORM-1007
> URL: https://issues.apache.org/jira/browse/STORM-1007
> Project: Apache Storm
> Issue Type: New Feature
> Reporter: Li Wang
> Assignee: Li Wang
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> The metrics of the queues for each component are very helpful to reason about
> the performance issues of a topology.
> For instance, for the applications with strong time constraint (e.g., threat
> detection), if the elements in the input queue of a bolt have a long sojourn
> time, it indicates that the user should increase the parallelism of that bolt
> to reduce the processing delay.
> However, the metrics on the DisruptorQueue currently available are limited.
> More useful metrics, such as average sojourn time and average throughput are
> expected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
