Re: Result merging takes too long

[remi tassing <ta...@gmail.com>]

Hi,

After looking at SearchHandler.java I believe we might have a bug on debug
information shown for distributed queries.

>@Erick: So as you can see, there's an extra round trip to each shard to
get the full document. Perhaps this is what you're seeing? <4> seems like
it might be what you're seeing, I don't think it's counted in QTime.

As Erick mentioned, the debug info is probably for one of the steps for
only one node and not the 'aggregrated' time (QTime represents the total
RTT so it includes everything I suppose).

Should a JIRA case be registered for this?

Remi


On Tue, Mar 18, 2014 at 12:41 PM, Shalin Shekhar Mangar <
shalinmangar@gmail.com> wrote:

> That's great Jeff! Thanks for sharing your experience. SOLR-5768 will
> make it even better.
>
> https://issues.apache.org/jira/browse/SOLR-5768
>
> On Tue, Mar 18, 2014 at 3:35 AM, Jeff Wartes <jw...@whitepages.com>
> wrote:
> >
> > This is highly anecdotal, but I tried SOLR-1880 with 4.7 for some tests I
> > was running, and saw almost a 30% improvement in latency. If you¹re only
> > doing document selection, it¹s definitely worth having.
> >
> > I¹m reasonably certain that the patch would work in 4.6 too, but the test
> > file relies on some test infrastructure changes in 4.7, so I couldn¹t try
> > that without re-writing the test.
> >
> >
> >
> > On 3/16/14, 7:31 AM, "Shalin Shekhar Mangar" <sh...@gmail.com>
> > wrote:
> >
> >>On Thu, Mar 13, 2014 at 1:49 PM, remi tassing <ta...@gmail.com>
> >>wrote:
> >>>
> >>> I've used the fl=id parameter to avoid retrieving the actual documents
> >>> (step <4> in your mail) but the problem still exists.
> >>> Any ideas on how to find the merging time(step <3>)?
> >>
> >>Actually that doesn't skip steps #4 and #5. That optimization will be
> >>available in Solr 4.8 (the next release). See
> >>https://issues.apache.org/jira/browse/SOLR-1880
> >>
> >>--
> >>Regards,
> >>Shalin Shekhar Mangar.
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>