FWIW, since it seemed like there was at least one bug here (and possibly more), I filed https://issues.apache.org/jira/browse/SOLR-8171
On 10/6/15, 3:58 PM, "Jeff Wartes" <jwar...@whitepages.com> wrote: > >I dug far enough yesterday to find the GET_DOCSET, but not far enough to >find why. Thanks, a little context is really helpful sometimes. > > >So, starting with an empty filterCache... > >http://localhost:8983/solr/techproducts/select?q=name:foo&rows=1&facet=tru >e >&facet.field=popularity > >New values: lookups: 0, hits: 0, inserts: 1, size: 1 > >So for the reasons you explained, "inserts" is incremented for this new >search > >http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=tru >e >&facet.field=popularity > >New values: inserts: lookups: 0, hits: 0, inserts 2, size: 2 > > >Another new search, another new insert. No "lookups" though, so how does >it know name:boo wasn’t cached? > >http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=tru >e >&facet.field=popularity >New values: inserts: lookups: 1, hits: 1, inserts: 2, size: 2 > > >But it clearly does know - when I repeat the search, I get both a lookup >and a hit. (and no insert) So is this just >a bug in the stats reporting, perhaps? > > >When I first started looking at this, it was in a solrcloud cluster, and >one interesting thing about that cluster is that it was configured with >the queryResultCache turned off, so let’s repeat the above experiment >without the queryResultCache. (I’m just commenting it out in the >techproducts config for this run.) > > >Starting with an empty filterCache... > >http://localhost:8983/solr/techproducts/select?q=name:foo&rows=1&facet=tru >e >&facet.field=popularity >New values: lookups: 0, hits: 0, inserts: 1, size: 1 > >Same as before... > >http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=tru >e >&facet.field=popularity >New values: inserts: lookups: 0, hits: 0, inserts 2, size: 2 > >Same as before... > >http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=tru >e >&facet.field=popularity >New values: inserts: lookups: 0, hits: 0, inserts 3, size: 2 > >No cache hit! We get an insert instead, but it’s already in there, so the >size doesn’t change. So disabling the queryResultCache apparently causes >facet queries to be unable to use the filterCache? > > > > >I’m increasingly thinking that different use cases need different >filterCaches, rather than try to bundle every explicit or unexpected >use-case under one cache with one size and one regenerator. > > > > > > >On 10/6/15, 2:45 PM, "Chris Hostetter" <hossman_luc...@fucit.org> wrote: > >>: So, no SolrCloud, default example config, about as basic as you get. I >>: didn’t even bother indexing any docs. Then I issued this query: >>: >>: >>http://localhost:8983/solr/techproducts/select?q=name:foo&rows=1&facet=tr >>u >>e >>: &facet.field=popularity&facet.mincount=0&facet.limit=-1 >> >>: This still causes an insert into the filterCache. >> >>the faceting component is a type of operation that indicates in the >>QueryCommand that it needs to GET_DOCSET for the set of all documents >>matching the query (independent of pagination) -- the point of this >>DocSet >>is so the faceting logic can then compute the intersection of the set of >>all matching documents with the set of documents matching each facet >>constraint. the cached DocSet will be re-used both within the context >>of the current request, and in future facet requests over the >>same query+filters. >> >>: The only real difference I’m noticing vs my solrcloud collection is >>that >>: repeating the query increments cache lookups and hits. It’s still odd >>: though, because issuing new distinct queries causes a reported insert, >>but >>: not a lookup, so the cache hit ratio is always exactly 1. >> >>i'm not following what you are saying at all ... can you give some >>concrete examples (ie: "starting with an empty cache i do this request, >>then i see these cache stats, then i do this identical/different query >>and >>then the cache stats look like this...") >> >> >> >>-Hoss >>http://www.lucidworks.com/ >
