Just skimming, but if I'm reading this right, your suggestion is that queries be served locally rather than being forwarded to another replica when possible.
So let's take the one-shard case with N replicas to make sure I understand. In a one-shard case, no query really needs to be forwarded, since any replica can fully get the results so in this case no query would be forwarded. If this is a fair summary, then consider the situation where the outside world connects to a single server rather than to a fronting load balancer. Then only one shard would be doing any work.... Or am I off in the weeds? That aside, if I've gotten it wrong and you want to put up a patch (or even just outline a better approach), feel free to open a JIRA and attach a patch... Best, Erick On Tue, Dec 9, 2014 at 11:55 PM, S G <sg.online.em...@gmail.com> wrote: > Hello Solr Devs, > > I am a developer using Solr and wanted to have some opinion on a performance > change request. > > Currently, I see that code flow for a query in SolrCloud is as follows: > > For distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> HttpShardHandler.submit() > > For non-distributed query: > SolrCore -> SearchHandler.handleRequestBody() -> QueryComponent.process() > > > For a distributed query, the request is always sent to all the shards even > if the originating SolrCore (handling the original distributed query) is a > replica of one of the shards. > If the original Solr-Core can check itself before sending http requests for > any shard, we can probably save some network hopping and gain some > performance. > > If this idea seems feasible, I can submit a JIRA ticket and work on it. > I am planning to change SearchHandler.handleRequestBody() or > HttpShardHandler.submit() > > Thanks > SG > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
