[
https://issues.apache.org/jira/browse/SOLR-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847375#comment-13847375
]
philip hoy edited comment on SOLR-4449 at 12/13/13 10:47 AM:
-------------------------------------------------------------
Otis, it does work in the way that you have suggested, any backup requests are
only sent after a configurable backupRequestDelay millis which could of course
be 0. The number of concurrent requests is limited by maximumConcurrentRequests.
Also i have recently implemented inflight request counting and added that to
the backup request load balancer. Now the load balancer will pick the server
that is currently handling the fewest requests.
Currently the backup request load balancer is running live in our production
environment alongside a standard solr load balancer, i have configured a socket
timeout of 30 secs and a retry after 15 secs, also worth noting is we have only
two replicas of the data. Here are some numbers from yesterday:
||Seconds|| Count(standard)|| Count(with backups) ||
|0.0 |279635 |281384 |
|5.0 |3141 |2668 |
|10.0 |585 |421|
|15.0 |176 |209|
|20.0 |145 |54 |
|25.0 |147 |42 |
|30.0 |137 |79 |
|35.0 |22 |14 |
|40.0 |30 |11 |
|45.0 |20 |37|
|50.0 |17 |5 |
|55.0 |7 |0|
|60.0 |213 |68|
As you can see the numbers do look a little better with backups however i think
with more replicas of the data one could be more aggressive with the retry time
without the risk of flooding all the servers in which case the improvement
would be more marked.
was (Author: phloy):
Otis, it does work in the way that you have suggested, any backup requests are
only sent after a configurable backupRequestDelay millis which could of course
be 0. The number of concurrent requests is limited by maximumConcurrentRequests.
Also i have recently implemented inflight request counting and added that to
the backup request load balancer. Now the load balancer will pick the server
that is currently handling the fewest requests.
Currently the backup request load balancer is running live in our production
environment alongside a standard solr load balancer, i have configured a socket
timeout of 30 secs and a retry after 15 secs, also worth noting is we have only
two replicas of the data. Here are some numbers from yesterday:
Seconds Count(standard) Count(with backups)
0.0 279635 281384
5.0 3141 2668
10.0 585 421
15.0 176 209
20.0 145 54
25.0 147 42
30.0 137 79
35.0 22 14
40.0 30 11
45.0 20 37
50.0 17 5
55.0 7 0
60.0 213 68
As you can see the numbers do look a little better with backups however i think
with more replicas of the data one could be more aggressive with the retry time
without the risk of flooding all the servers in which case the improvement
would be more marked.
> Enable backup requests for the internal solr load balancer
> ----------------------------------------------------------
>
> Key: SOLR-4449
> URL: https://issues.apache.org/jira/browse/SOLR-4449
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: philip hoy
> Priority: Minor
> Attachments: SOLR-4449.patch, SOLR-4449.patch, SOLR-4449.patch,
> patch-4449.txt, solr-back-request-lb-plugin.jar
>
>
> Add the ability to configure the built-in solr load balancer such that it
> submits a backup request to the next server in the list if the initial
> request takes too long. Employing such an algorithm could improve the latency
> of the 9xth percentile albeit at the expense of increasing overall load due
> to additional requests.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
