I remember seeing some performance impact (even when not using it) and it was attributed to the calls to System.nanoTime. See SOLR-7875 and SOLR-7876 (fixed for 5.3 and 5.4). Those two Jiras fix the impact when timeAllowed is not used, but I don't know if there were more changes to improve the performance of the feature itself. The problem was that System.nanoTime may be called too many times on indices with many different terms. If this is the problem Jeff is seeing, a small degradation of System.nanoTime could have a big impact.
Tomás On Tue, May 2, 2017 at 10:23 AM, Walter Underwood <wun...@wunderwood.org> wrote: > Hmm, has anyone measured the overhead of timeAllowed? We use it all the > time. > > If nobody has, I’ll run a benchmark with and without it. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > > > On May 2, 2017, at 9:52 AM, Chris Hostetter <hossman_luc...@fucit.org> > wrote: > > > > > > : I specify a timeout on all queries, .... > > > > Ah -- ok, yeah -- you mean using "timeAllowed" correct? > > > > If the root issue you were seeing is in fact clocksource related, > > then using timeAllowed would probably be a significant compounding > > factor there since it would involve a lot of time checks in a single > > request (even w/o any debugging enabled) > > > > (did your coworker's experiements with ES use any sort of equivilent > > timeout feature?) > > > > > > > > > > > > -Hoss > > http://www.lucidworks.com/ > >
