On Sunday, September 11, 2016 7:57:41 PM EDT Willy Tarreau wrote: > Hi Andrew, > > On Sun, Sep 11, 2016 at 01:45:35PM -0400, Andrew Rodland wrote: > > On Sunday, September 11, 2016 9:11:50 AM EDT Willy Tarreau wrote: > > > Don't worry, that's the principle of a PoC. I looked at your code. I > > > think > > > we can significantly simplify it. The current server's relative capacity > > > should be computed on the fly when trying to pick the server in the > > > ring. > > > Right now you call this function chash_update_server_capacities() to > > > recompute all servers capacities before chosing your server but given > > > that > > > you already have the information on the number of total served > > > connections > > > in the backend, it's possible to modify the current lookup function to > > > void running this loop first. This is especially important as some > > > setups > > > have very large numbers of servers (eg: up to 1000). > > > > I agree that this would be better, but the algorithm is supposed to > > distribute the capacity among servers in a particular way. Concretely, > > say that the computed capacity is 14 and there are 10 servers. Then there > > should be 4 servers with a capacity of 2 and 6 servers with a capacity of > > 1, and which are which shouldn't depend on where the request hashed to > > ??? there needs to be some way of identifying the "first" 4 servers. > > Walking the hash ring seems like an inefficient way to do it, I agree, > > but I didn't have a better one. > Wait a minute, I think you're talking about the while() loop used to > find the next non-saturated server. I agree this one cannot be removed > otherwise we create a domino effect by overloading a specific server > with all requests initially made for another server. Here I'm talking > about the initial function which is used to compute all relative > capacities (sorry I don't have its name in mind and don't have access > to the sources right now). Since the servers' capacities do not change > during the loop, it's better to update the backend's average load as > servers take or release connections and be able to compute a server's > weight on the fly instead of pre-computing it.
No, I mean the first loop. If the average load times c factor is non-integer, the algorithm gives some servers an effective capacity of the next integer up, and some the next integer down. This is easily done, except that you have to have a way of knowing whether the server you're looking at is in the "first" n or not, according to some stable ordering of the servers. Everything else, i think I have figured out, including the math for the weights, and I will get to work as I have time. Andrew
