True true. I always group byCost and addPrediction together. That
said, I've included the config that we use (works very well right now!), and
am curious to know if there is some mix/match ideal that you
personally/academically/professionally prefer?
<Location />
Backhand byAge 2
BackhandFromSO libexec/byHostname.so byHostname (app)
Backhand byRandom
Backhand byLogWindow
Backhand byCost
Backhand addPrediction
</Location>
Does anyone know of a way to improve this? Here's the quickie
drawing:
---
| High availability
---
|
V
---
|Proxy w/ mod_backhand (w/ backhand config above)
---
|
V
---
|App w/ mod_backhand (but no proxying/relaying of requests in config)
---
-sc
-----Original Message-----
From: Theo E. Schlossnagle [mailto:theos@cnds.jhu.edu]
Sent: Tuesday, August 01, 2000 12:29 PM
To: Sean Chittenden
Cc: backhand-users@lists.backhand.org; Stephen Nickels
Subject: Re: FW: [mod_backhand-users] Another New Candidacy Function:
byChooseMeOverLocal
Sean Chittenden wrote:
> Quickie, but wasn't the point of byCost to prevent overloading a
> single machine?
Quickie question... Not quickie answer :) Here we go:
Not exactly. Actually, not at all. byCost suffers from problems
similar to byLoad. byCost is a reproach of the problem based on the
idea that "load isn't all that matters". Memory utilization is
important to. byCost is an algorithm designed to take into account the
utilization of various resources. The current implementation only
accounts for load and memory utilization, but could easily take into
account any other resource you have in mind (the equations are there,
just nothing else is being *plugged* in).
byCost takes memory into consideration, where byLoad does not. So, it
doesn't suffer as severely from the stale information problem. The
memory utilization info is updated in realtime (because that info is
made available to mod_backhand by the OS). However, the resource
utilization is only shared between the machines every second. This
means that for a full second (at least) they all see *almost* the same
thing. So byCost and byLoad suffer from stale information, because no
matter how hard you try, the information will always be at least
partially stale.
There are several methods to take stale information into account when
attempting to select the *best* server (you see now why you DO NOT want
to select the least loaded server :). Here are a few:
(1) addPrediction
The addPrediction function adds incremental values to a machines
*perceived* load after assigning requests to it (a little less if you
assign requests locally). These increments are wiped out when you get
the next resource broadcast for that machine, but then it adds up
again. It tries to calculate it *smartly* by determining how long
requests have been taking to that machine and guessing at the load a
request *would* incur. Sounds really cool! Does it work? Truthfully,
our simulation environment is not complete, so I can't tell you for
sure. (It can't hurt though).
(2) randomized subset (byLogWindow)
This is discussed in detail in a paper by Mitzenmacher and Dahlin, and
the math is out of the scope of this mailing list :) But it, obviously,
tackles the problem in a VERY different way than the first method works.
(3) randomized equalization
This is not implemented yet in mod_backhand, but when I get time, it
will be. The idea is that you assign the requests randomly, but the
randomness is not uniformly distributed. Instead, the distribution is
based inversly upon the normalized cost of the machines -- the lower the
(relative) cost, the higher the probability. Perhaps I will implement
this for the 1.1.0 release :) It should work very well (gut feeling).
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
_______________________________________________
backhand-users mailing list
backhand-users@lists.backhand.org
http://lists.backhand.org/mailman/listinfo/backhand-users
said, I've included the config that we use (works very well right now!), and
am curious to know if there is some mix/match ideal that you
personally/academically/professionally prefer?
<Location />
Backhand byAge 2
BackhandFromSO libexec/byHostname.so byHostname (app)
Backhand byRandom
Backhand byLogWindow
Backhand byCost
Backhand addPrediction
</Location>
Does anyone know of a way to improve this? Here's the quickie
drawing:
---
| High availability
---
|
V
---
|Proxy w/ mod_backhand (w/ backhand config above)
---
|
V
---
|App w/ mod_backhand (but no proxying/relaying of requests in config)
---
-sc
-----Original Message-----
From: Theo E. Schlossnagle [mailto:theos@cnds.jhu.edu]
Sent: Tuesday, August 01, 2000 12:29 PM
To: Sean Chittenden
Cc: backhand-users@lists.backhand.org; Stephen Nickels
Subject: Re: FW: [mod_backhand-users] Another New Candidacy Function:
byChooseMeOverLocal
Sean Chittenden wrote:
> Quickie, but wasn't the point of byCost to prevent overloading a
> single machine?
Quickie question... Not quickie answer :) Here we go:
Not exactly. Actually, not at all. byCost suffers from problems
similar to byLoad. byCost is a reproach of the problem based on the
idea that "load isn't all that matters". Memory utilization is
important to. byCost is an algorithm designed to take into account the
utilization of various resources. The current implementation only
accounts for load and memory utilization, but could easily take into
account any other resource you have in mind (the equations are there,
just nothing else is being *plugged* in).
byCost takes memory into consideration, where byLoad does not. So, it
doesn't suffer as severely from the stale information problem. The
memory utilization info is updated in realtime (because that info is
made available to mod_backhand by the OS). However, the resource
utilization is only shared between the machines every second. This
means that for a full second (at least) they all see *almost* the same
thing. So byCost and byLoad suffer from stale information, because no
matter how hard you try, the information will always be at least
partially stale.
There are several methods to take stale information into account when
attempting to select the *best* server (you see now why you DO NOT want
to select the least loaded server :). Here are a few:
(1) addPrediction
The addPrediction function adds incremental values to a machines
*perceived* load after assigning requests to it (a little less if you
assign requests locally). These increments are wiped out when you get
the next resource broadcast for that machine, but then it adds up
again. It tries to calculate it *smartly* by determining how long
requests have been taking to that machine and guessing at the load a
request *would* incur. Sounds really cool! Does it work? Truthfully,
our simulation environment is not complete, so I can't tell you for
sure. (It can't hurt though).
(2) randomized subset (byLogWindow)
This is discussed in detail in a paper by Mitzenmacher and Dahlin, and
the math is out of the scope of this mailing list :) But it, obviously,
tackles the problem in a VERY different way than the first method works.
(3) randomized equalization
This is not implemented yet in mod_backhand, but when I get time, it
will be. The idea is that you assign the requests randomly, but the
randomness is not uniformly distributed. Instead, the distribution is
based inversly upon the normalized cost of the machines -- the lower the
(relative) cost, the higher the probability. Perhaps I will implement
this for the 1.1.0 release :) It should work very well (gut feeling).
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
_______________________________________________
backhand-users mailing list
backhand-users@lists.backhand.org
http://lists.backhand.org/mailman/listinfo/backhand-users