[
https://issues.apache.org/jira/browse/OAK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024367#comment-15024367
]
Ian Boston edited comment on OAK-3654 at 11/24/15 12:30 PM:
------------------------------------------------------------
Metrics provides "bad stats" because its being given "bad data", have a look at
the patch to the methods, copied here.
(I am assuming this is the code being tested and reported in the tests)
{code}
@@ -622,14 +623,14 @@ public class SessionDelegate {
if (op.isUpdate()) {
sessionCounters.writeTime = t0;
sessionCounters.writeCount++;
- writeCounter.incrementAndGet();
- writeDuration.addAndGet(dt);
+ writeCounter.mark();
+ writeDuration.update(dt, TimeUnit.MILLISECONDS);
updateCount++;
} else {
sessionCounters.readTime = t0;
sessionCounters.readCount++;
- readCounter.incrementAndGet();
- readDuration.addAndGet(dt);
+ readCounter.mark();
+ readDuration.update(dt, TimeUnit.MILLISECONDS);
}
{code}
It should be using
{code}
Context c = metric.time();
....
c.stop();
{code}
IIRC if done that way Metrics uses nanoseconds.
Internally Metics will probably use nanoseconds even it it reports in
microseconds.
As mentioned earlier, using the context.stop() pattern avoids inadvertent bugs.
BTW, according to the output, it was given 136M (136121718) samples, which
should be enough samples to generate something statistically relevant.
was (Author: ianeboston):
Metrics provides "bad stats" because its being given "bad data", have a look at
the patch to the methods, copied here.
{code}
@@ -622,14 +623,14 @@ public class SessionDelegate {
if (op.isUpdate()) {
sessionCounters.writeTime = t0;
sessionCounters.writeCount++;
- writeCounter.incrementAndGet();
- writeDuration.addAndGet(dt);
+ writeCounter.mark();
+ writeDuration.update(dt, TimeUnit.MILLISECONDS);
updateCount++;
} else {
sessionCounters.readTime = t0;
sessionCounters.readCount++;
- readCounter.incrementAndGet();
- readDuration.addAndGet(dt);
+ readCounter.mark();
+ readDuration.update(dt, TimeUnit.MILLISECONDS);
}
{code}
It should be using
{code}
Context c = metric.time();
....
c.stop();
{code}
IIRC if done that way Metrics uses nanoseconds.
Internally Metics will probably use nanoseconds even it it reports in
microseconds.
As mentioned earlier, using the context.stop() pattern avoids inadvertent bugs.
BTW, according to the output, it was given 136M (136121718) samples, which
should be enough samples to generate something statistically relevant.
> 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.3.12
>
> 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)
