Hi Otis, Sorry I missed your reply, and thanks for trying to find a similar report.
Wondering if I should file a Jira issue? That might get more attention :) -- Ken On Jul 5, 2013, at 1:05pm, Otis Gospodnetic wrote: > Hi Ken, > > Uh, I left this email until now hoping I could find you a reference to > similar reports, but I can't find them now. I am quite sure I saw > somebody with a similar report within the last month. Plus, several > people have reported issues with performance dropping when they went > from 3.x to 4.x and maaaaaybe this is why. > > Otis > -- > Solr & ElasticSearch Support -- http://sematext.com/ > Performance Monitoring -- http://sematext.com/spm > > > > On Tue, Jul 2, 2013 at 3:01 PM, Ken Krugler <kkrugler_li...@transpac.com> > wrote: >> Hi all, >> >> After upgrading from Solr 3.5 to 4.2.1, I noticed our filterCache hit ratio >> had dropped significantly. >> >> Previously it was at 95+%, but now it's < 50%. >> >> I enabled recording 100 entries for debugging, and in looking at them it >> seems that edismax (and faceting) is creating entries for me. >> >> This is in a sharded setup, so it's a distributed search. >> >> If I do a search for the string "bogus text" using edismax on two fields, I >> get an entry in each of the shard's filter caches that looks like: >> >> item_+(((field1:bogus | field2:bogu) (field1:text | field2:text))~2): >> >> Is this expected? >> >> I have a similar situation happening during faceted search, even though my >> fields are single-value/untokenized strings, and I'm not using the enum >> facet method. >> >> But I'll get many, many entries in the filterCache for facet values, and >> they all look like "item_<facet field>:<facet value>:" >> >> The net result of the above is that even with a very big filterCache size of >> 2K, the hit ratio is still only 60%. >> >> Thanks for any insights, >> >> -- Ken -------------------------- Ken Krugler +1 530-210-6378 http://www.scaleunlimited.com custom big data solutions & training Hadoop, Cascading, Cassandra & Solr
