[
https://issues.apache.org/jira/browse/SOLR-13257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16882628#comment-16882628
]
Michael Gibney commented on SOLR-13257:
---------------------------------------
Thanks, [~cpoerschke] and [~tomasflobbe]! Responses shortly to PR comments.
[~cpoerschke], I think the examples (and answers) you set out are all
illustrative and accurate (with the exception that the syntax would be
{{shards.preference=replica.base:stable:dividend:fooBar&fooBar=0}} or
{{shards.preference=replica.base:stable:hash:fooBar&fooBar=0)}}
A couple of comments on the initial example cases (though again it seems that
the the answers you provide are accurate as far as I understand it):
2.Example: opt for possibility 2: It's a nitpicky semantic point, but the
deterministic preference param doesn't ever really resolve directly to a
particular replica, rather it resolves to a particular rotation of the replica
preferences list. The first of these will in most (all?) cases be chosen to
serve the request, but there's nothing special about the "top" replica _per
se_, and thus nothing different about the _other_ replicas (that would cause
them to be sorted differently).
4. "Does the new shard affinity logic influence the ordering within the end
portion of the list too?"
Yes; each grouping of otherwise equivalent options is sorted and
deterministically rotated according to the specified affinity param.
5. Same as 4; the new affinity logic only affects groupings of options that are
otherwise (according to specified {{shards.preference}} param) considered to be
equivalent; and it affects all such groupings, no matter how many hierarchical
preferences are specified, or how many otherwise-equivalent groups there are.
> Enable replica routing affinity for better cache usage
> ------------------------------------------------------
>
> Key: SOLR-13257
> URL: https://issues.apache.org/jira/browse/SOLR-13257
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: Michael Gibney
> Priority: Minor
> Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch,
> SOLR-13257.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
