[jira] [Resolved] (SOLR-3104) Bad performance with distributed search when sort contains relevancy queries

["Shalin Shekhar Mangar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shalin Shekhar Mangar resolved SOLR-3104.
-----------------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 4.7)
                   4.0
         Assignee: Yonik Seeley

This was released with Solr 4.0

> Bad performance with distributed search when sort contains relevancy queries
> ----------------------------------------------------------------------------
>
>                 Key: SOLR-3104
>                 URL: https://issues.apache.org/jira/browse/SOLR-3104
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>    Affects Versions: 3.6
>            Reporter: XJ Wang
>            Assignee: Yonik Seeley
>            Priority: Critical
>             Fix For: 4.0
>
>         Attachments: SOLR-3104-3x.patch, SOLR-3104.patch
>
>
> So I found this issue when trying out distributed search with solr 3.5 and noticed big performance degradation for some queries comparing to the single box search.
> After some query analysis and comparison, it turns out that shard queries with "fsv=true" are much slower than the same queries w/o "fsv=true". Some examples are like 1200ms vs 200ms (start=0, rows=30, hits<100).
> From the discussions with Yonik Seeley on solr mailing list, it may due to fact that I'm using lot of relevancy queries in sorting. But Solr is not retrieving those sort values efficiently .
> This is critical for us and prevents us from moving to distributed search. I believe users like our scenarios will also suffer from this issue. Any patch/idea is welcomed.   
> Quote from Yonik Seeley on solr-user mailing list:
> "OK, so basically it's slow because functions with embedded relevancy
> queries are "forward only" - if you request the value for a docid
> previous to the last, we need to reboot the query (re-weight, ask for
> the scorer, etc).  This means that for your 30 documents, that will
> require rebooting the query about 15 times (assuming that roughly half
> of the time the next docid will be less than the previous one).
> Unfortunately there's not much you can do externally... we need to
> implement optimizations at the Solr level for this."



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org