[
https://issues.apache.org/jira/browse/OAK-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-8011:
------------------------------------
Fix Version/s: 1.12
> Benchmark on QUERY_DURATION metrics implemented in OAK-7904
> -----------------------------------------------------------
>
> Key: OAK-8011
> URL: https://issues.apache.org/jira/browse/OAK-8011
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: indexing, query
> Reporter: Paul Chibulcuteanu
> Priority: Major
> Fix For: 1.12
>
>
> As part of OAK-7904, there are some possible performance concerns on adding
> additional metrics in code which is executed a lot.
> See [~tmueller]'s comment:
> {code}
> Some comments on overhead of measuring:
> We measure here very common, and very fast operations. I don't know how fast
> next() could be, but if everything is in memory, it could be faster than 600
> ns. I measured the fastest measured operation was processed at 0.091904
> milliseconds , that would be 91904 nanoseconds. Measures was this divided by
> 256, so just 359 nanoseconds.
> System.nanoTime() can be slower than that, according to this older article it
> can be 650 nanoseconds. We need to call it twice to measure, so 1'300
> nanoseconds. Meaning, measuring in the worst case seens so far slows down the
> operation by factor 4.6 (worst case seen so far).
> What we could do is use org.apache.jackrabbit.oak.stats Clock.Fast, which has
> a much lower overhead than calling System.nanoTime(). The name "Fast" is
> somewhat of a misnomer: the clock isn't really faster than other clocks, it's
> just less overhead. So getting the current time is fast. Resolution is low,
> but that wouldn't be a problem in our case, it's just that most of the time,
> operations would be 0 ns, and rarely 100s of ns. On average, that would even
> out (same as with the sampling it is using right now). The problems with
> Clock.Fast are:
> Hard to get a hand on this instance.
> It uses a thread pool executor service, which is problematic. If the same
> service is used by other threads that take milliseconds, then the clock is
> extremely inaccurate. I would be better to use a simple, separate daemon
> thread.
> {code}
> Seeing that there is the possibility to enable/disable the metrics stats two
> separate benchmark tests can be run:
> * specifying the _oak.query.timerDisabled_ system prop
> * without specifying the _oak.query.timerDisabled_ system prop
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
