[
https://issues.apache.org/jira/browse/SOLR-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077745#comment-14077745
]
Ramkumar Aiyengar commented on SOLR-6275:
-----------------------------------------
I added a rudimentary test for {{System.nanoTime}} performance, there's some
perf degradation when you increase the number of threads but it's not alarming.
And actually beyond a certain number of threads, I think some kind of caching
kicks in and the average time dips considerably. I have
[updated|https://github.com/apache/lucene-solr/pull/70/files] the pull request
with the test.
The following output was from a Linux machine with 16 cores..
{code}
718 T11 oasu.TestUtils.testNanoTimeSpeed testNanoTime: maxNumThreads = 100,
numIters = 1000
723 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 1, time_per_call = 423ns
724 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 2, time_per_call = 295ns
725 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 3, time_per_call = 109ns
726 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 4, time_per_call = 491ns
727 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 5, time_per_call = 747ns
728 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 6, time_per_call = 851ns
729 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 7, time_per_call = 1031ns
731 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 8, time_per_call = 453ns
731 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 9, time_per_call = 42ns
732 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 10, time_per_call = 77ns
733 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 11, time_per_call = 78ns
733 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 12, time_per_call = 44ns
734 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 13, time_per_call = 74ns
736 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 14, time_per_call = 47ns
737 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 15, time_per_call = 46ns
738 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 16, time_per_call = 68ns
738 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 17, time_per_call = 45ns
738 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 18, time_per_call = 46ns
739 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 19, time_per_call = 46ns
739 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 20, time_per_call = 47ns
740 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 21, time_per_call = 47ns
741 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 22, time_per_call = 65ns
741 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 23, time_per_call = 48ns
742 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 24, time_per_call = 47ns
...
795 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 96, time_per_call = 48ns
796 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 97, time_per_call = 47ns
796 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 98, time_per_call = 47ns
799 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 99, time_per_call = 67ns
800 T11 oasu.TestUtils.testNanoTimeSpeed numThreads = 100, time_per_call = 55ns
{code}
> Improve accuracy of QTime reporting
> -----------------------------------
>
> Key: SOLR-6275
> URL: https://issues.apache.org/jira/browse/SOLR-6275
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Ramkumar Aiyengar
> Priority: Minor
>
> Currently, {{QTime}} uses {{currentTimeMillis}} instead of {{nanoTime}} and
> hence is not suitable for time measurements. Further, it is really started
> after all the dispatch logic in {{SolrDispatchFilter}} (same with the top
> level timing reported by {{debug=timing}}) which may or may not be expensive,
> and hence may not fully represent the time taken by the search. This is to
> remedy both cases.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]