[
https://issues.apache.org/jira/browse/SOLR-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765888#comment-16765888
]
Jan Høydahl commented on SOLR-6730:
-----------------------------------
Hi, commenting on this old issue, as I had a discussion with a customer
yesterday regarding replica affinity to utilise caches better. They fire more
than 100 requests to draw a dashboard, and you get much better cache
utilisation and faster load time with replicationFactor=1 than
replicationFactor=3 since you need to warm three times as many caches. Looks
like the feature suggested here could help with this as well, e.g. by adding a
"seed" param if you want sticky replicas for a "session". Right?
> select?replicaAffinity=(node|host) and replicaAffinity.hostPriorities support
> -----------------------------------------------------------------------------
>
> Key: SOLR-6730
> URL: https://issues.apache.org/jira/browse/SOLR-6730
> Project: Solr
> Issue Type: New Feature
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
>
> If no shards parameter is supplied with a select request then sub-requests
> will go to a random selection of live solr nodes hosting shards for the
> collection of interest. All sub-requests must complete before results can be
> collated i.e. the slowest sub-request determines how fast the search
> completes.
> Use of optional replicaAffinity can reduce the number of JVMs hit by a given
> search (the more JVMs are hit, the higher the chance of hitting a garbage
> collection pause in one of many JVMs). Preferentially directing requests to
> certain areas of the cloud can also be useful for debugging or when some
> replicas reside on 'faster' machines.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
