I plan on adding the debug flag to my queries and collecting that from my logs. I don't think we're using highlighting. Would anyone be able to tell from a raw query?
q=%7B%21q.op%3DAND%7D*&defType=edismax&qf=color_en%5E2.0+q_vendorColor_en%5E17.0+q_bullet2_en%5E19.0+v irtualCategory_ens%5E77.0+q_saleAssortment_ens%5E1.0+q_bullet9_en%5E25.0+q_description_en%5E16.0+q_material_en%5E17.0+q_assortment_ens%5E40.0+q_name_en%5E92.0+brand_ ens%5E56.0+q_bullet4_en%5E18.0+q_bullet3_en%5E34.0+q_bullet8_en%5E58.0+searchIdAndSkuCollection_ens%5E1.0+q_bullet7_en%5E9.0+q_bullet6_en%5E19.0+q_bullet5_en%5E6.0+c ategory_ens%5E77.0+q_bullet1_en%5E12.0+&start=0&rows=48&sort=popularity_i+desc%2Cpopularity_i+desc&fq=id%3A%28320403401%29&f.q_category_ss.facet.prefix=0%7C&f.q_virt ualCategory_ss.facet.prefix=0%7C&facet=true&facet.limit=-1&facet.mincount=1&facet.sort=index&facet.range=daysSinceStart_i&facet.range=activePrice_l&f.daysSinceStart_ i.facet.range.start=0&f.daysSinceStart_i.facet.range.end=60&f.daysSinceStart_i.facet.range.gap=7&f.daysSinceStart_i.facet.method=fc&facet.field=q_virtualCategory_ss& facet.field=q_brand_s&facet.field=q_color_s&facet.field=q_category_ss&f.q_virtualCategory_ss.facet.method=enum&f.activePrice_l.facet.range.start=0&f.activePrice_l.fa cet.range.end=5000000&f.activePrice_l.facet.range.gap=5000&f.activePrice_l.facet.method=fc&f.q_brand_s.facet.method=enum&f.q_color_s.facet.method=enum&f.q_category_s s.facet.method=enum On Tue, Feb 4, 2014 at 2:00 PM, Jack Krupansky <j...@basetechnology.com>wrote: > 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...* > -- 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...*
