[
https://issues.apache.org/jira/browse/OAK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023775#comment-15023775
]
Chetan Mehrotra commented on OAK-3654:
--------------------------------------
bq. hence when ACCURATE.getTime() is called it will generally be slower than
just calling System.nanoTime().
Ack
bq. it explains why System.getCurrentTimeMillis() is faster than
System.nanoTime() (measured at 13ns vs 18ns).
Yes thats the understanding. Key point here is that Metrics is being called in
very critical path of read and write and if every such call involves a call to
System.nanoTime then that raise a bit of concern.
Now looking back at the change done so far I think there is some extra
duplicate work now. Currently we maintain a pair of metrics
* SESSION_READ_COUNTER and SESSION_READ_DURATION
* SESSION_WRITE_COUNTER and SESSION_WRITE_DURATION
* QUERY_COUNT and QUERY_DURATION
In current approach for each pair we manage a pair of Meter and Timer. Hence
any call now involve 2 calls to System.nanoTime(). Would have to refactor that
to avoid the extra call
bq. Metrics has considerable production experience. I would avoid making
fundamental changes unilaterally. If there is a real problem with the Metrics
code and how they measure time, I would open an issue on their bug tracker to
validate the issue is real.
Sure. Would try to get some numbers to benchmark
> 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)
