I haven't read this whole thread, so maybe it's already come up. Have
you turned on the garbage collection logging to see if the jvm is busy
cleaning up when you are seeing the slowness? Maybe the jvm is
struggling to keep the heap size within a particular limit?
//Ed
On Wed, Jul 22, 2009 at 10:22 AM, Jeff Newburn<jnewb...@zappos.com> wrote:
> We can never reproduce the slowness with the same query. As soon as we try
> to run them again they are fine. I have even tried running the same query
> the next day and it is fine.
>
> All of our requests go through our dismax handler which is part of why it is
> so weird. Most queries are fine, however just occasionally they aren't.
> Additionally, why would the command=details command also go slow? That
> seems like a server issue.
>
> It appears that for FieldValueCache and FilterCache we have no evictions,
> but for queryResultCache and DocumentCache there are a good number of
> evictions. How would I help lower the evictions to see if that is the
> problem?
>
> Dismax Config below:
> <requestHandler name="dismax" class="solr.DisMaxRequestHandler"
> default="true">
> ?
> <lst name="defaults">
> <str name="echoParams">explicit</str>
> <float name="tie">0.5</float>
> ?
> <str name="qf">
>
> productId^10.0
>
> personality^8.0
> subCategory^8.0
> category^6.0
> productType^5.0
>
> brandName^1.0
> realBrandName^1.0
> productNameSearch^1.0
>
> size^1.2
> width^1.0
> heelHeight^1.0
>
> productDescription^1.0
> color^10.0
> price^1.0
> attrs^5.0
>
> expandedGender^0.5
>
> </str>
> ?
> <str name="pf">
>
> attrs^3 brandName^10.0 productNameSearch^8.0
> productDescription^2.0 personality^4.0 subCategory^12.0 category^10.0
> productType^8.0
>
> </str>
> ?
> <str name="fl">
>
> productId, productName, price, originalPrice,
> brandNameFacet, productRating, imageUrl, productUrl, isNew, onSale, styleId
>
> </str>
> <str name="mm">100%</str>
> <int name="ps">1</int>
> <int name="qs">5</int>
> <str name="q.alt">*:*</str>
> <!-- More like this search parameters -->
> ?
> <str name="mlt.fl">
> brandNameFacet,productTypeFacet,productName,categoryFacet,subCategoryFacet,p
> ersonalityFacet,colorFacet,heelHeight,expandedGender
> </str>
> <int name="mlt.mindf">1</int>
> <int name="mlt.mintf">1</int>
> </lst>
> ?
> <arr name="last-components">
> <str>spellcheck</str>
> </arr>
> </requestHandler>
>
> --
> Jeff Newburn
> Software Engineer, Zappos.com
> jnewb...@zappos.com - 702-943-7562
>
>
>> From: Erik Hatcher <e...@ehatchersolutions.com>
>> Reply-To: <solr-user@lucene.apache.org>
>> Date: Wed, 22 Jul 2009 00:36:30 -0400
>> To: <solr-user@lucene.apache.org>
>> Subject: Re: Random Slowness
>>
>>
>> On Jul 21, 2009, at 6:52 PM, Jeff Newburn wrote:
>>
>>> We are experiencing random slowness on certain queries. I have been
>>> unable
>>> to diagnose what the issue is. We are using SOLR 1.4 and 99.99% of
>>> queries
>>> return in under 250 ms. The remaining queries are returning in 2-5
>>> seconds
>>> for no apparent reason. There does not seem to be any commonality
>>> between
>>> the queries. This problem also includes admin system queries. Any
>>> help or
>>> direction would be much appreciated.
>>
>> Do you experience the same slow speeds when you manually issue those
>> queries? In other words, is it repeatable? If so, try
>> &debugQuery=true and see the component timings and where the time is
>> going.
>>
>> What's the query parsing too? Anything unusually large due to synonym
>> lists or something like that?
>>
>> What about your filter cache - how's it looking when these slow
>> queries take place? evictions > 0?
>>
>>> params
>>> ={facet=true&facet.mincount=1&facet.limit=-1&wt=javabin&rows=0&facet.s
>>> ort
>>> =
>>> true
>>> &start=0&q=shoes&facet.field=colorFacet&facet.field=brandNameFacet&f
>>> acet
>>> .field
>>> =heelHeight&facet.field=attrFacet_Style&qt=dismax&fq=productTypeFa
>>> cet:Shoes
>>> &fq=gender:Womens&fq=categoryFacet:Sandals&fq=width:EE&fq=size:10.5
>>> &fq=priceFacet:"$100.00+and+Under"&fq=personalityFacet:Sexy} hits=19
>>> status=0 QTime=3689
>>
>> What's the config of your dismax handler look like?
>>
>> Erik
>>
>
>
