Depending on how you're measuring performance (and whether your use case benefits from caching), it might be worth looking into stable replica routing (configured with the "replica.base" sub-parameter of the shards.preference <https://lucene.apache.org/solr/guide/8_4/distributed-requests.html#shards-preference-parameter> parameter). With a single replica per shard, every request is routed to a single replica for a given shard, ensuring effective use of replica-level caches. With multiple replicas per shard, by default each request is routed randomly to specific replicas. The more shards you have (and the more replicas), the longer it takes to "warm" caches to the point where the user actually perceives decreased latency. For replication factor > 1, stable cache entries can be initialized by warming queries, but transient cache entries (particularly the queryResultCache) can in some cases be rendered effectively useless in combination with the default random replica routing. More discussion can be found at SOLR-13257 <https://issues.apache.org/jira/browse/SOLR-13257>.
To be sure, this may not affect your case, but if you're seeing performance degradation associated with adding replicas, it's probably worth considering. On Mon, Apr 13, 2020 at 9:48 AM Jae Joo <jaejo...@gmail.com> wrote: > I have multiple 100 M documents using Nested Document for joining. It is > the fastest way for joining in a single replica. By adding more replicas (2 > or 3), the performance is slow down significantly. (about 100x times). > Does anyone have same experience? > > Jae >
