[
https://issues.apache.org/jira/browse/SOLR-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075756#comment-14075756
]
Erick Erickson commented on SOLR-6275:
--------------------------------------
Hmmm, I'm not sure I agree. QTime is useful for knowing how long the lower
level stuff took.
Thus it's useful as it stands.
Having the dispatch time reported _too_ seems valuable, but I don't think
folding it into
QTime is a good idea. Reporting both, however, gives me more information to
work
with and a much better idea of what to look for for explaining query slowness
than
if the dispatch time was folded into QTime. A better alternative would be to
include
this time as a separate component in the return timings block?
-1 on switching to nanoTime for reporting
I mean we're talking human-time here. When I'm asking how long a query took,
my frail human system is not capable of noticing a difference of a millisecond
or two.
nanoTime is not necessarily all that accurate either. Sure, it gives a lot or
precision,
but that's different from accuracy.
"This method provides nanosecond precision, but not necessarily nanosecond
accuracy.
No guarantees are made about how frequently values change"
Frankly, this doesn't seem worth the change to me. And especially if we return
the full
nanoTime string which would render any current tools for reporting performance
metrics invalid by a factor 100,000, all for extremely questionable utility.
> 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]
