Sharding adds inevitable overhead. Particularly each request, rather than being serviced on a single replica has to send out a first request to each replica, get the ID and sort criteria back, then send out a second request to get the actual docs.
Especially if you're asking for a lot of rows this can get very expensive. And you're now serving your queries on 1/4 of the machines. In the first setup, an incoming request was completely serviced on 1 node. Now you're requiring 4 nodes to participate. Sharding is always a second choice and always has some overhead. As long as your QTimes are acceptable, you should stick with only a single replica. Best, Erick On Mon, Dec 12, 2016 at 12:14 PM, Piyush Kunal <piyush.ku...@myntra.com> wrote: > All our shards and replicas reside on different machines with 16GB RAM and > 4 cores. > > On Tue, Dec 13, 2016 at 1:44 AM, Piyush Kunal <piyush.ku...@myntra.com> > wrote: > >> We did the following change: >> >> 1. Previously we had 1 shard and 32 replicas for 1.2million documents of >> size 5 GB. >> 2. We changed it to 4 shards and 8 replicas for 1.2 million documents of >> size 5GB >> >> We have a combined RPM of around 20k rpm for solr. >> >> But unfortunately we saw a degrade in performance with RTs going insanely >> high when we moved to setup 2. >> >> What could be probable reasons and how it can be fixed? >>
