[
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: [email protected]
For additional commands, e-mail: [email protected]
