8877
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8876
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8875
|
|
|
Henrik Nordstrom |
|
15 years ago
|
|
|
8874
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8873
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8872
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8871
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8870
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8869
|
|
|
Amos Jeffries |
SQUID_3_0_STABLE8 |
15 years ago
|
|
|
8868
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8867
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8866
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8865
|
|
Author: Mark Nottingham <mnot@pobox.com> Bug #2376: Round-Robin becomes unbalanced when a peer dies and comes back
When a peer goes down and then comes back, its round-robin counters aren't reset, causing it to get a disproportionate amount of traffic until it "catches up" with the rest of the peers in the round-robin pool.
If it was down for load-related issues, this has the effect of making it more likely that it will go down again, because it's temporarily handling the load of the entire pool.
Normally, this isn't a concern, because the number of requests that it can get out-of-step is relatively small (bounded to how many requests it can be given before it is considered down -- is this 10 in all cases, or are there corner cases?), but in an accelerator case where the origin has a process-based request-handling model, or back-end processes are CPU-intensive, it is.
This patch resets the counters each time a peer changes state.
|
Amos Jeffries |
|
15 years ago
|
|
|
8864
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8863
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8862
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8861
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8860
|
|
|
Guido Serassio |
|
15 years ago
|
|
|
8859
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|
8858
|
|
|
Amos Jeffries |
|
15 years ago
|
|
|