We did try consistent hashing, but I found better distribution without it. We don¹t add or remove servers often so we should be ok. Our total pool is sized correctly and we are able to serve 100% requests when we use roundrobin, however sticky on host is what causes some nodes to hit maxconn. My goal is to never send a 503 as long as we have other nodes available which is always the case in our pool.
Thanks Sachin On 8/31/13 1:17 PM, "Willy Tarreau" <w...@1wt.eu> wrote: >On Sat, Aug 31, 2013 at 01:03:34PM +0530, Sachin Shetty wrote: >> Thanks Willy. >> >> I am precisely using it for caching. I need requests to go to the same >> nodes for cache hits, but when the node is already swamped I would >>prefer >> a cache miss over a 503. > >Then you should already be using "hash-type consistent", otherwise when >you lose or add a server, you redistribute everything and will end up >with only about 1/#cache at the same place and all the rest with misses. >Not many cache architectures resist to this, really. > >Interestingly, a long time ago I wanted to have some outgoing rules >(they're >on the diagram in the doc directory). The idea was to be able to apply >some >processing *after* the LB algorithm was called. Such processing could >include >detecting the selected server's queue size or any such thing and decide to >force to use another server. But in practice it doesn't play well with the >current sequencing so it was never done. It could have been useful in such >a situation I think. > >I'll wait a bit for others to step up about the idea of redistributing >connections only for consistent hashing. I really don't want to break >existing setups (eventhough I think in this case it should be OK). > >Willy >
