Add the debug=true parameter to some test queries and look at the "timing"
section to see which search components are taking the time. Traditionally,
highlighting for large documents was a top culprit.
Are you returning a lot of data or field values? Sometimes reducing the
amount of data processed can help. Any multivalued fields with lots of
values?
-- Jack Krupansky
-----Original Message-----
From: Joel Cohen
Sent: Tuesday, February 4, 2014 1:43 PM
To: solr-user@lucene.apache.org
Subject: Re: Lowering query time
1. We are faceting. I'm not a developer so I'm not quite sure how we're
doing it. How can I measure?
2. I'm not sure how we'd force this kind of document partitioning. I can
see how my shards are partitioned by looking at the clusterstate.json from
Zookeeper, but I don't have a clue on how to get documents into specific
shards.
Would I be better off with fewer shards given the small size of my indexes?
On Tue, Feb 4, 2014 at 12:32 PM, Yonik Seeley <yo...@heliosearch.com> wrote:
On Tue, Feb 4, 2014 at 12:12 PM, Joel Cohen <joel.co...@bluefly.com>
wrote:
> I'm trying to get the query time down to ~15 msec. Anyone have any
> tuning
> recommendations?
I guess it depends on what the slowest part of the query currently is.
If you are faceting, it's often that.
Also, it's often a big win if you can somehow partition documents such
that requests can normally be serviced from a single shard.
-Yonik
http://heliosearch.org - native off-heap filters and fieldcache for solr
--
joel cohen, senior system engineer
e joel.co...@bluefly.com p 212.944.8000 x276
bluefly, inc. 42 w. 39th st. new york, ny 10018
www.bluefly.com <http://www.bluefly.com/?referer=autosig> | *fly since
2013...*
