[
https://issues.apache.org/jira/browse/OAK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023912#comment-15023912
]
Ian Boston commented on OAK-3654:
---------------------------------
My tests showed that timing measurements of operations that took less than
1E-7s contained a 10% overhead which concurs with the observation that
System.nanoTime() takes order 1E-8s to complete. If you need to measure metrics
at that level, then using a Timer wrapping an individual call is the wrong
approach as you will need a timer with an overhead of more like 1E-9 or 1E-10s
and an accuracy of 1E-8 or 1E-9s. Realistically, continuous and routine timing
at that level is not particularly useful in production and best left to
attaching a profiler with sampling support.
> Integrate with Metrics for various stats collection
> ----------------------------------------------------
>
> Key: OAK-3654
> URL: https://issues.apache.org/jira/browse/OAK-3654
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Fix For: 1.4
>
> Attachments: OAK-3654-v1.patch, query-stats.png
>
>
> As suggested by [~ianeboston] in OAK-3478 current approach of collecting
> TimeSeries data is not easily consumable by other monitoring systems. Also
> just extracting the last moment data and exposing it in simple form would not
> be useful.
> Instead of that we should look into using Metrics library [1] for collecting
> metrics. To avoid having dependency on Metrics API all over in Oak we can
> come up with minimal interfaces which can be used in Oak and then provide an
> implementation backed by Metric.
> This task is meant to explore that aspect and come up with proposed changes
> to see if its feasible to make this change
> * metrics-core ~100KB in size with no dependency
> * ASL Licensee
> [1] http://metrics.dropwizard.io
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
