On Mon, Apr 19, 2010 at 12:49:13PM +0200, Dirk Taggesell wrote: > On Mon, Apr 12, 2010 at 8:50 PM, Dirk Taggesell > <dirk.tagges...@googlemail.com> wrote: > > Hank A. Paulson wrote: > > > >> How varied is your "site" param? are there many variations or just a few > >> similar strings? > > > > There's a large amount of distinctive urls, maybe some are requested > > several times, but still al large amount of different site urls. There > > is also another GET parameter, which is some key (one customer, one > > key) that is largely constant. but as the url hash should be based on > > the site param the key shouldn't matter. > > > > Only thing is that every site url starts with "http://"; and most also > > followed by "www". But that doesn't matter with hashing over the > > entire url? > > I still do not know why five of seven back-ends don't receive any > requests once I activate "hash-type consistent". Without consistent > hashing the distribution of requests are almost perfectly even among > the back-ends. And I tested with lots of different URLs (an url is > given as GET parameter and this parameter is used for hashing).
Well, I don't know what to say. The normal hashing *is* smooth while the consistent hashing *tries* its best to be smooth but will never be by design. Imagine a circle with many dots on its perimeter line. Each dot represents one server. When you hash a URL, it gives you a position on the circle. The closest dot defines what server handles the traffic. From my memories, there are 256*weight dots per server. That means that if your servers are running with weight 10, they appear 2560 times each on the circle in an almost random fashion. It would be extremely unfortunate that the URLs you hash always end up on the same server, but this can happen, especially with small numbers of values. But in my opinion, when you start playing with 10 to 100 times more URLs than you have servers, I really don't see how you could be "lucky" enough to always reach the same servers. Still it can happen. > Is there definitely a need for manually weighing the individual > back-ends with consistent hashing? That would be quite difficult as I > now do only have test urls and not the real ones that will be used in > production. At least try to increase all weights (eg: 100). There should not be any need for that but it can help. I agree with you that you should not have to manually tweak your weight afterwards, otherwise it's pointless to do hashing. And anyway that would change with the number of servers. It may only be helpful if your data set is too small. > And once in production I cannot simply activate consistent > hashing only to discover that two back-ends are overloaded while the > other ones are doing nothing and me frantically trying to manually > distributing the requests by adding weigths to individual back-ends. No, really don't do that. Please, try to get an extract of your prod servers' logs and try to replay them through your test machine. Ideally, you should have at least 256*(sum of weights) different URLs to test. If you still see very bad results, please send me some examples. It is possible that we need to change the hashing algorithm because you've found a pattern that always generates very close keys. > Sounds quite counter-intuitive to me. You're perfectly right and that's why I'd like you not to do that. > So as far as I understood consistent hashing prevents a complete > redistribution of hashes among the back-ends but will only > redistribute requests that would have gone to a now off-line back-end. > So that not all the back-ends caches are being completely invalidated. No that's really not the goal. It should work as expected and it does for some users. > But needing to manually adjust the back-end distribution will cause > problems when the general character of urls our customers send us will > change, not? It should not if you have enough URLs for the hash to be smooth enough. Once again, if you have to tweak anything, either the hashing method is unsuited to your dataset (and we need to improve it), or you have too few different data to test. Regards, Willy
