[squid-dev] [RFC] CRUSH peer selection method

[Alex Rousskov]

On 04/19/2017 09:48 AM, Loic Dachary wrote:
> On 04/19/2017 04:31 PM, Alex Rousskov wrote:

>> Another test shows better CRUSH performance. It is not clear to me
>> whether some other tests will show better CARP performance.

> The test program I wrote[1] displays the properties of CARP that help
> comparing it with CRUSH, that is:

> - requests are evenly distributed among peers, in accordance to the weights

This CARP behavior feels natural/reasonable. How does this compare to CRUSH?


> - when a peer is added or removed, the amount of requests moving to
> or from the new or old peer is in proportion of its weight

This CARP behavior feels natural/reasonable. How does this compare to CRUSH?


> - when the weight of a peer is changed, the amount of requests moving
> to or from the changed peer is in proportion of the weight change

This CARP behavior feels natural/reasonable. How does this compare to CRUSH?


> While conducting these tests I discovered that CARP does not perform
> as well as CRUSH when changing weights. 

AFAICT, you showed one data point where the above is true. Would it be
possible to _generalize_, based on all the other tests you have done
and/or based on your understanding of how the algorithms work? In other
words, can you formulate a general statement of the following form?

  CRUSH outperforms CARP when ... . Under those conditions, CRUSH
  results in X% fewer reassigned requests. CRUSH gets Y% close to
  the hypothetical ideal algorithm that minimizes reassignment
  while still balancing the load.

(The last sentence is _optional_ -- I do not know whether you have
enough information to make such a statement and whether it is possible
to make such an estimate at all.)


> If there are other tests that
> you think relevant to compare the two algorithms, I'd be happy to
> work on that.

There may be a misunderstanding: I am not trying to force you to run
more or different tests. I just want to understand the performance
difference between the two algorithms. How you discover/document/present
that difference is your call. Running tests and generalizing from them
could be a valid approach (but one isolated measurement does not tell me
much).


> I hope this shows you the work done is better than a random
> exploration of meaningless tests.

Again, I am not trying to request "more work" or belittle the value of
the work already performed. I am just saying that you have not given us
enough information to get excited about CRUSH. That does not mean we
should not be excited about it. It only means that you have not proven
that adding CRUSH is worth it. And if we do not know whether or how
CRUSH is better (beyond one data point), how can we "sell" switching to
this new algorithm to the admins? (Rhetorical).

Finally, I do not speak for others, but please do not expect me to read
scientific articles or study code at least until you convince me that
CRUSH is probably significantly better than CARP (again, based on
whatever proof method that you think will work). I need a convincing
executive summary first.


Thank you,

Alex.