Paul Chibulcuteanu created OAK-8011:
---------------------------------------
Summary: 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
Reporter: Paul Chibulcuteanu
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)
