You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Isaac Hebsh (JIRA)" <ji...@apache.org> on 2013/07/30 22:51:49 UTC
[jira] [Comment Edited] (SOLR-5092) Send shard request to multiple
replicas
[ https://issues.apache.org/jira/browse/SOLR-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724376#comment-13724376 ]
Isaac Hebsh edited comment on SOLR-5092 at 7/30/13 8:51 PM:
------------------------------------------------------------
Submitting initial patch.
As [~erickoerickson] suggested on mailing list, changes are only in solrj, so nothing should be changed in core.
This change should be very easy. Just move the single HTTP request into CompletionService :)
But, the most complicated thing in this patch, is to preserve the original exception handling. There are some exceptions which are considered as temporary, while other exceptions are fatal. Moreover, we want to preserve the zombie list maintenance as is.
was (Author: isaachebsh):
Submitting initial patch.
As Erick suggested on mailing list, changes are only in solrj, so nothing should be changed in core.
This change should be very easy. Just move the single HTTP request into CompletionService :)
But, the most complicated thing in this patch, is to preserve the original exception handling. There are some exceptions which are considered as temporary, while other exceptions are fatal. Moreover, we want to preserve the zombie list maintenance as is.
> Send shard request to multiple replicas
> ---------------------------------------
>
> Key: SOLR-5092
> URL: https://issues.apache.org/jira/browse/SOLR-5092
> Project: Solr
> Issue Type: Improvement
> Components: clients - java, SolrCloud
> Affects Versions: 4.4
> Reporter: Isaac Hebsh
> Priority: Minor
> Labels: distributed, performance, shard, solrcloud
> Attachments: SOLR-5092.patch
>
>
> We have a case on a SolrCloud cluster. Queries takes too much QTime, due to a randomly slow shard request. In a noticeable part of queries, the slowest shard consumes more than 4 times qtime than the average.
> Of course, deep inspection of the performance factor should be made on the specific environment.
> But, there is one more idea:
> If shard request will be sent to all of the replicas of each shard, the probability of all the replicas of the same shard to be the slowest is very small. Obviously cluster works harder, but on a (very) low qps, it might be OK.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org