Multiple caches can have the same hit rate as a single cache if the same query
is always sent back to the same replica. This works great until a replica goes
down. If the queries are redistributed, all the caches have the wrong content,
very expensive. Instead. the queries need to be
Tangentially related, possibly of interest regarding solr-internal cache
hit ratio (esp. with a lot of replicas):
https://issues.apache.org/jira/browse/SOLR-13257
On Mon, Feb 25, 2019 at 11:33 AM Walter Underwood
wrote:
> Don’t worry about one and two character queries, because they will almost
Don’t worry about one and two character queries, because they will almost
always be served from cache.
There are only 26 one-letter queries (36 if you use numbers). Almost all of
those will be in the query results cache and will be very fast with very little
server load. The common two-letter
Maybe you could add a length filter factory to filter out queries with 2 or
3 characters using
https://lucene.apache.org/solr/guide/7_4/filter-descriptions.html#FilterDescriptions-LengthFilter
?
PS: this filter requires a max length too.
Edward
Em qui, 21 de fev de 2019 04:52, Furkan KAMACI
Hi Joakim,
I suggest you to read these resources:
http://lucene.472066.n3.nabble.com/Varnish-td4072057.html
http://lucene.472066.n3.nabble.com/SolrJ-HTTP-caching-td490063.html
https://wiki.apache.org/solr/SolrAndHTTPCaches
which gives information about HTTP Caching including Varnish Cache,
Hello dear user list!
I work at a company in retail where we use solr to perform searches as you
type.
As soon as you type more than 1 characters in the search field solr starts
serving hits.
Of course this generates a lot of "unnecessary" queries (in the sense that
they are never shown to the
