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

Christine Poerschke commented on SOLR-13257:
--------------------------------------------

Thanks [~tomasflobbe] for the ping! I left some comments on the pull requests 
but have no concerns, it's a very elegant code solution indeed, thank you 
[~mgibney] for developing and contributing it.

> 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
>            Assignee: Tomás Fernández Löbbe
>            Priority: Minor
>         Attachments: AffinityShardHandlerFactory.java, SOLR-13257.patch, 
> SOLR-13257.patch
>
>          Time Spent: 2h 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.14#76016)

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

Reply via email to