Yonik, thanks for your explanation. I've created a ticket here
https://issues.apache.org/jira/browse/SOLR-3104
On Mon, Feb 6, 2012 at 4:28 PM, Yonik Seeley wrote:
> On Mon, Feb 6, 2012 at 6:16 PM, XJ wrote:
> > Sorry I didn't make this clear. Yeah we use dismax in main query, as
> well as
> > in
On Mon, Feb 6, 2012 at 5:53 PM, XJ wrote:
> Yes as I mentioned in previous email, we do dismax queries(with different mm
> values), solr function queries (map, etc) math calculations (sum, product,
> log). I understand those are expensive. But worst case it should only double
> the time not going
Yes as I mentioned in previous email, we do dismax queries(with different
mm values), solr function queries (map, etc) math calculations (sum,
product, log). I understand those are expensive. But worst case it should
only double the time not going from 200ms to 1200ms right?
XJ
On Mon, Feb 6, 201
On Mon, Feb 6, 2012 at 5:35 PM, XJ wrote:
> hm.. just looked at the log only 112 matched, and start=0, rows=30
Are any of the sort criteria sort-by-function with anything complex
(like an embedded relevance query)?
-Yonik
lucidimagination.com
>
> On Mon, Feb 6, 2012 at 1:33 PM, Yonik Seeley
>
hm.. just looked at the log only 112 matched, and start=0, rows=30
On Mon, Feb 6, 2012 at 1:33 PM, Yonik Seeley wrote:
> On Mon, Feb 6, 2012 at 3:30 PM, oleole wrote:
> > Thanks for your reply. Yeah that's the first thing I tried (adding
> fsv=true
> > to the query) and it surprised me too. Coul
On Mon, Feb 6, 2012 at 3:30 PM, oleole wrote:
> Thanks for your reply. Yeah that's the first thing I tried (adding fsv=true
> to the query) and it surprised me too. Could it due to we're using many
> complex sortings (20 sortings with dismax, and, or...). Any thing it can be
> optimized? Looks lik
the query) and it surprised me too. Could it due to we're using many
> complex sortings (20 sortings with dismax, and, or...). Any thing it can be
> optimized? Looks like it's calculated twice in solr?
>
> XJ
>
> --
> View this message in context:
> http://lucen
r?
XJ
--
View this message in context:
http://lucene.472066.n3.nabble.com/Performance-degradation-with-distributed-search-tp3715060p3720739.html
Sent from the Solr - User mailing list archive at Nabble.com.
On Sat, Feb 4, 2012 at 1:20 AM, XJ wrote:
> When I look into details (slow queries), I found some real issues that I
> need help with. For example, a query which takes 200ms with geo sharding,
> now timeout (>2000ms) with distributed search. And each shard query
> (isShard=true) takes about 1200ms
Hello,
I am experimenting with solr distributed search/random sharding (currently
use geo sharding), hope to gain some performance and also scalability in
the future. (index size keep growing and geo shard is hard to scale)
However I'm seeing worse performance with distributed search, on a testin
10 matches
Mail list logo
