[cf-dev] Proposal for weighted routing user experience in Cloud Foundry

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[cf-dev] Proposal for weighted routing user experience in Cloud Foundry

Shubha Anjur Tupil

The CF Routing team has received feedback from many users that support for weighted routing would make it easier to accomplish their goals. We have a proposal on the preferred user experience for weighted routing and the considerations we have taken into account.


If you have thoughts on this or have experience working with traffic splitting on other platforms, please share your feedback with us. Feel free to comment on the doc or reply here.


Regards,

CF Routing Team



_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8146) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Proposal for weighted routing user experience in Cloud Foundry

Filip Hanik
I put a long comment in the doc, maybe comments are good for short notes. here is the spiel

"The sum of weights must add to 100"
I would say this is where being user friendly ends. If I add reviews-v4 I have to go in and rebalance the whole thing just to figure out how to get to 100.

an alternate solution can be much simpler:

What if you just used a single integer that is relative to the whole cluster. let's call it "base1-lb"

reviews-v1: 6
reviews-v2: 3
reviews-v3: 1

there are two ways to think of this

relative to each other:
In this scenario, v1 gets twice as many requests as v2, and six times as many requests as v3

or in consideration of X requests: (and this is most likely how the code implements it so that it doesn't have to do a lot of math)
This is saying is that for every (total) 10 requests, this is how they distributed.

to add v4
reviews-v1: 6
reviews-v2: 3
reviews-v3: 1
reviews-v4: 1

this is still super simple to look at. v1 gets 6x more than v3/v4, still gets 2x more than v2. I don't have to figure out how to "add up to a 100"

and it's not complicated to calculate either. for every 11 requests:
v1 gets 6
v2 gets 3
v3 gets 1
v4 gets 1

Implementation: "Randomized Round Robin" is also super simple [pseudo code follows]

clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v3] //very easy to create based on base1 solution
randomCluster = random(clusterWeight) 
int atomicPointer = 0;
for each request:
  next = atomicPointer.getAndIncrease();
  application = randomCluster[atomicPointer];

and that's it. the router doesn't have to figure out where the next request goes. This is a simple, elegant and easy to understand solution.

Filip








On Fri, Jul 13, 2018 at 3:09 PM Shubha Anjur Tupil <[hidden email]> wrote:

The CF Routing team has received feedback from many users that support for weighted routing would make it easier to accomplish their goals. We have a proposal on the preferred user experience for weighted routing and the considerations we have taken into account.


If you have thoughts on this or have experience working with traffic splitting on other platforms, please share your feedback with us. Feel free to comment on the doc or reply here.


Regards,

CF Routing Team



_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8147) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Proposal for weighted routing user experience in Cloud Foundry

Filip Hanik
aaarrgh, there is a bug in my psuedo code

clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v3] should be
clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v4]

Full solution:
Implementation: "Randomized Round Robin" is also super simple [pseudo code follows]

clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v4] //very easy to create based on base1 solution
randomCluster = random(clusterWeight) 
int atomicPointer = 0;
for each request:
  next = atomicPointer.getAndIncrease();
  application = randomCluster[atomicPointer];


On Fri, Jul 13, 2018 at 8:09 PM Filip Hanik <[hidden email]> wrote:
I put a long comment in the doc, maybe comments are good for short notes. here is the spiel

"The sum of weights must add to 100"
I would say this is where being user friendly ends. If I add reviews-v4 I have to go in and rebalance the whole thing just to figure out how to get to 100.

an alternate solution can be much simpler:

What if you just used a single integer that is relative to the whole cluster. let's call it "base1-lb"

reviews-v1: 6
reviews-v2: 3
reviews-v3: 1

there are two ways to think of this

relative to each other:
In this scenario, v1 gets twice as many requests as v2, and six times as many requests as v3

or in consideration of X requests: (and this is most likely how the code implements it so that it doesn't have to do a lot of math)
This is saying is that for every (total) 10 requests, this is how they distributed.

to add v4
reviews-v1: 6
reviews-v2: 3
reviews-v3: 1
reviews-v4: 1

this is still super simple to look at. v1 gets 6x more than v3/v4, still gets 2x more than v2. I don't have to figure out how to "add up to a 100"

and it's not complicated to calculate either. for every 11 requests:
v1 gets 6
v2 gets 3
v3 gets 1
v4 gets 1

Implementation: "Randomized Round Robin" is also super simple [pseudo code follows]

clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v3] //very easy to create based on base1 solution
randomCluster = random(clusterWeight) 
int atomicPointer = 0;
for each request:
  next = atomicPointer.getAndIncrease();
  application = randomCluster[atomicPointer];

and that's it. the router doesn't have to figure out where the next request goes. This is a simple, elegant and easy to understand solution.

Filip








On Fri, Jul 13, 2018 at 3:09 PM Shubha Anjur Tupil <[hidden email]> wrote:

The CF Routing team has received feedback from many users that support for weighted routing would make it easier to accomplish their goals. We have a proposal on the preferred user experience for weighted routing and the considerations we have taken into account.


If you have thoughts on this or have experience working with traffic splitting on other platforms, please share your feedback with us. Feel free to comment on the doc or reply here.


Regards,

CF Routing Team



_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8148) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] Proposal for weighted routing user experience in Cloud Foundry

Filip Hanik
In reply to this post by Filip Hanik
Use case: I want v1-stable to receive 5 times more traffic than each individual upgrade version I deploy


Phase 1: Deploy alpha 1

Proposed (sum MUST add up to a 100):
 v1-stable: 83
 v2-alpha1: 17

Suggested (simpler base1-lb)
v1-stable: 5
v2-alpha1: 1

Phase 2: Deploying Alpha 1 and 2

Proposed (sum MUST add up to a 100):
 v1-stable: 72
 v2-alpha1: 14
 v2-alpha2: 14

Suggested (simpler base1-lb)
v1-stable: 5
v2-alpha1: 1
v2-alpha2: 1

Why the simpler is better:
When adding v2-alpha2 I don't need to change the load balancing algorithm on all my settings. The relationship between v1 and v2-alpha1 remains exactly the same.
I also don't need to be doing any math to understand the relationship between the two.

The proposed base1-lb simply removes the need for percentages and calculations. 






On Fri, Jul 13, 2018 at 8:11 PM Filip Hanik <[hidden email]> wrote:
aaarrgh, there is a bug in my psuedo code

clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v3] should be
clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v4]

Full solution:
Implementation: "Randomized Round Robin" is also super simple [pseudo code follows]

clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v4] //very easy to create based on base1 solution
randomCluster = random(clusterWeight) 
int atomicPointer = 0;
for each request:
  next = atomicPointer.getAndIncrease();
  application = randomCluster[atomicPointer];


On Fri, Jul 13, 2018 at 8:09 PM Filip Hanik <[hidden email]> wrote:
I put a long comment in the doc, maybe comments are good for short notes. here is the spiel

"The sum of weights must add to 100"
I would say this is where being user friendly ends. If I add reviews-v4 I have to go in and rebalance the whole thing just to figure out how to get to 100.

an alternate solution can be much simpler:

What if you just used a single integer that is relative to the whole cluster. let's call it "base1-lb"

reviews-v1: 6
reviews-v2: 3
reviews-v3: 1

there are two ways to think of this

relative to each other:
In this scenario, v1 gets twice as many requests as v2, and six times as many requests as v3

or in consideration of X requests: (and this is most likely how the code implements it so that it doesn't have to do a lot of math)
This is saying is that for every (total) 10 requests, this is how they distributed.

to add v4
reviews-v1: 6
reviews-v2: 3
reviews-v3: 1
reviews-v4: 1

this is still super simple to look at. v1 gets 6x more than v3/v4, still gets 2x more than v2. I don't have to figure out how to "add up to a 100"

and it's not complicated to calculate either. for every 11 requests:
v1 gets 6
v2 gets 3
v3 gets 1
v4 gets 1

Implementation: "Randomized Round Robin" is also super simple [pseudo code follows]

clusterWeight = [v1,v1,v1,v1,v1,v1,v2,v2,v2,v3,v3] //very easy to create based on base1 solution
randomCluster = random(clusterWeight) 
int atomicPointer = 0;
for each request:
  next = atomicPointer.getAndIncrease();
  application = randomCluster[atomicPointer];

and that's it. the router doesn't have to figure out where the next request goes. This is a simple, elegant and easy to understand solution.

Filip








On Fri, Jul 13, 2018 at 3:09 PM Shubha Anjur Tupil <[hidden email]> wrote:

The CF Routing team has received feedback from many users that support for weighted routing would make it easier to accomplish their goals. We have a proposal on the preferred user experience for weighted routing and the considerations we have taken into account.


If you have thoughts on this or have experience working with traffic splitting on other platforms, please share your feedback with us. Feel free to comment on the doc or reply here.


Regards,

CF Routing Team



_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8152) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_