Re: Question regarding url_param hashing

On Sat, Apr 10, 2010 at 11:08 AM, Dirk Taggesell <dirk.taggesell#googlemail.com> wrote:
> On Thu, Apr 8, 2010 at 10:57 PM, Willy Tarreau <w#1wt.eu> wrote:
>
>> In 1.4 you should probably use "hash-type consistent" to avoid redispatching
>> everyone when one server falls down.
>
> Thanks for eyplaining, Willy,
>
> we tested everything so far (with version 1.4.4) and we discovered a
> strange behaviour:
> We have seven back-end servers and without "hash-type consistent", all
> are being used equally by haproxy. But as soon as we activate
> "hash-type consistent" only two of the back-ends are being used, the
> other five won't receive any requests anymore.
> Still used are back-end one and seven, none of the others.

It's expected that consistent hashing won't provide an even distribution to your backends. You'll need to adjust the weights of each server to even out the traffic if you want a smooth distribution of requests to backends.

If you don't need consistent hashing, just remove hash-type and haproxy will default to a more even distribution. Consistent hashing protects against an entire re-hash of your resources if backends go offline.
http://www.tomkleinpeter.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/

>
> This is how the part of the config looks (pretty much standard):
> global
>        log 127.0.0.1   local7 notice
>        maxconn 4096
>        daemon
>        user haproxy
>        group haproxy
>
> defaults
>        log     global
>        mode    http
>        option  httplog
>        option  dontlognull
>        retries 3
>        option redispatch
>        contimeout      5000
>        clitimeout      50000
>        srvtimeout      50000
>
>
> listen  context 0.0.0.0:80
>        mode      http
>        log       global
>        balance   url_param site
>        hash-type consistent
>        option    forwardfor
>        option    httpclose
>        server    context1 10.104.27.149:9100 check
>        server    context2 10.217.9.191:9100 check
>        server    context3 10.104.41.152:9100 check
>        server    context4 10.217.25.253:9100 check
>        server    context5 10.104.29.171:9100 check
>        server    context6 10.104.23.224:9100 check
>        server    context7 10.104.25.192:9100 check
>
>
Received on 2010/04/12 00:07