[
https://issues.apache.org/jira/browse/OAK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015528#comment-15015528
]
Ian Boston commented on OAK-3654:
---------------------------------
Patch LGTM, some comments.
The Timer.update(...) isn't very clean compared to the other patterns that
leave performing the timing operation to the implementation.
eg (Metrics notation).
{code}
Context c = timerMetric.time();
Do work
c.stop();
{code}
is cleaner than, and potentially less buggy than:
{code}
long nanos = System.nanoTime();
Do work
timerMetric.update(System.nanoTime()-nanos, TimeUnit.NANOS);
{code}
Perhaps consider exposing a wrapper for Context in the TimerStats interface. It
would reduce the volume of code require to instrument a section/method and
trigger HotSpot earlier on that code. It is marginal, but could save some bugs.
(incorrect sum, wrong time units, wrong start time).
----
nanoTimer and performance. I have measured the overhead of the metrics library
to be about 10% timing calls of about 1E-7s. (ie 1E-8s). Timing to operations
that take less than 1E-7s tends to be counter productive. I haven't tested
counting. Testing was done using JDK7, OSX 10.10 on a 2.53 GHz Intel Core 2
Duo, late 2008 model.
-----
If we had detailed reliable metrics on more things (eg queues, rates of
indexing, query rates, etc) not just database calls we would be able to get a
snapshot of the entire stack operation in a single json file. Seeing which
queries are slow does help, but seeing a 99 percentile response time is 5
orders of magnitude greater than the median is a sure indicator of trouble that
needs investigation, wherever it is in the stack. Metrics are not that useful
if they only cover a very small area of the stack.
MongoDB already logs slow queries its log files, with good OS tools to analyse.
Having that information has helped in the past, but often issues doen show up
in that way (Oak commit queue overflow or stall).
> 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)
