On Tue, Sep 18, 2012 at 11:49 AM, jimtronic <jimtro...@gmail.com> wrote: > I've got a set up as follows: > > - 13 cores > - 2 servers > - running Solr 4.0 Beta with numShards=1 and an external zookeeper. > > I'm trying to figure out why some complex queries are running so slowly in > this setup versus quickly in a standalone mode. > > Given a query like: /select?q=(some complex query) > > It runs fast and gets faster (caches) when only running one server: > > 1. ?fl=*&q=(complex query)&wt=json&rows=24 (QTime 3) > > When, I issue the same query to the cluster and watch the logs, it looks > like it's actually performing the query 3 times like so: > > 1. ?q=(complex > query)&distrib=false&wt=javabin&rows=24&version=2&NOW=1347911018556&shard.url=(server1)|(server2)&fl=id,score&df=text&start=0&isShard=true&fsv=true > (QTime 2) > > 2. ?ids=(ids from query > 1)&distrib=false&wt=javabin&rows=24&version=2&df=text&fl=*&shard.url=(server1)|(server2)&NOW=1347911018556&start=0&q=(complex > query)&isShard=true (QTime 4) > > 3. ?fl=*&q=(complex query)&wt=json&rows=24 (QTime 459)
#1 and #2 are sub-requests (different phases of the top level request). #3 is the log for the top level original request that made #1 and #2 and encompasses the time for both of them. > Why is it performing #3? It already has everything it needs in #2 and #3 > seems to be really slow even when warmed and cached. > > As stated above, this query is fast when running on a single server that is > warmed and cached. > > Since my query is complex, I could understand some slowness if I was > attempting this across multiple shards, but since there's only one shard, > shouldn't it just pick one server and query it? A distributed search that happens to only hit a single shard is something we haven't optimized for yet. -Yonik http://lucidworks.com > I can "fix" this by adding "distrib=false" to my original queries, but then > that sort of makes the whole cluster meaningless. > > Ideally, I'd just spin up a new server that attaches itself to zookeeper and > add it to my load balancer and forget about it. > > Thanks! > Jim --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
