Willy Tarreau a écrit :
>> I'm trying to come up with a configuration for HAProxy to balance by the
>> 'Host' header in a generic fashion (i.e. one that does not require me to
>> hard code host header values to backends). We're using wildcard DNS and
>> basically have clients registered to their own host/domain: e.g. -
>> client1.mydomain.com, client2.mydomain.com, etc.
>> All requests for a particular host would stick to the same server. I
>> think it's pretty similar to the URI hashing scheme. If I understand
>> that scheme requests are balanced round-robin, but stick to backends
>> based on a hash of the uri.
>> Any ideas? BTW, I'm using HAProxy-126.96.36.199 on Gentoo Linux.
> The header hash is in the todo list, with many other things, but is just
> not implemented right now. There are multiple things to consider for this,
> among which check/ignore case, specify which occurrence of the header to
> match, etc... so it will not be implemented tomorrow morning...
> Right now, I do not see any easy method to ensure that all clients for a
> given host will get to the same server.
> May I ask for what specific purpose you need the feature (I'm not trying
> to escape it's implementation, just trying to find a temporary workaround) ?
> Is it more for performance, for persistence, etc...
Hi, back on this subject.
I think Jeff and I share the same type of plateforme (load-balancing of multiple (thousand for myself) small to medium web sites)
And this feature, of which we already discussed ("Haproxy & un-usual session tracking", late 2007) is needed for performance. Our Application Server can't cache every site on one back-end, and so 'normal' round-robin lead to an high performance impact:
previously we had average number like that:
dns query: 2ms connection time: 26ms reception of first octet: 139ms total load time: 140ms now we have number like that: dns query: 2ms connection time: 26ms reception of first octet: 623ms total load time: 676ms and up to that: dns query: 2ms connection time: 26ms reception of first octet: 1771,33ms total load time: 1828,33msReceived on 2008/09/04 18:19
This archive was generated by hypermail 2.2.0 : 2008/09/04 18:31 CEST