jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davide Giannella (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (OAK-8011) Benchmark on QUERY_DURATION metrics implemented in OAK-7904
Date Mon, 15 Apr 2019 09:20:08 GMT

     [ https://issues.apache.org/jira/browse/OAK-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Davide Giannella closed OAK-8011.

bulk close 1.12.0

> 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.0
> 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
> 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

View raw message