lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Gibney (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-13257) Enable replica routing affinity for better cache usage
Date Tue, 14 May 2019 17:38:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839653#comment-16839653
] 

Michael Gibney commented on SOLR-13257:
---------------------------------------

[PR created|https://github.com/apache/lucene-solr/pull/677]. This ended up being a bit more
involved than I'd anticipated, because I ended up integrating replica affinity with {{shards.preference}}.
This seemed like the most natural place to add this functionality, and it will allow deterministic
routing to be used in conjunction with other replica routing preferences (as a fallback/tie-breaker).
There's also support for configuring default "base routing" preference in solrconfig.xml.

> Enable replica routing affinity for better cache usage
> ------------------------------------------------------
>
>                 Key: SOLR-13257
>                 URL: https://issues.apache.org/jira/browse/SOLR-13257
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrCloud
>    Affects Versions: 7.4, master (9.0)
>            Reporter: Michael Gibney
>            Priority: Minor
>         Attachments: AffinityShardHandlerFactory.java
>
>
> For each shard in a distributed request, Solr currently routes each request randomly
via [ShufflingReplicaListTransformer|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/ShufflingReplicaListTransformer.java]
to a particular replica. In setups with replication factor >1, this normally results in
a situation where subsequent requests (which one would hope/expect to leverage cached results
from previous related requests) end up getting routed to a replica that hasn't seen any related
requests.
> The problem can be replicated by issuing a relatively expensive query (maybe containing
common terms?). The first request initializes the {{queryResultCache}} on the consulted replicas.
If replication factor >1 and there are a sufficient number of shards, subsequent requests
will likely be routed to at least one replica that _hasn't_ seen the query before. The replicas
with uninitialized caches become a bottleneck, and from the client's perspective, many subsequent
requests appear not to benefit from caching at all.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message