> We are planning to deploy a memcached cluster of 40 odd machines and > were wondering about mgets and the size of the cluster. > > We could either: > - have all the machines in one cluster, which would mean that an mget > on a set of keys could potentially span the entire cluster > - partition our cluster into smaller sizes and assign cache lines to > certain cluster, thereby reducing the mget fan-out for that cache line > > Does anyone have any recommendation/benchmarks regarding such a > network latency/available bandwidth trade-off?
How much traffic are you intending to send? how many mgets in one go? Unless you do tons of traffic it doesn't tend to matter much either way. It's good to spread out a little since clients can send requests to each server in parallel, but then you lose out a bit by contacting too many machines per page view. If you're planning to deploy, this sounds like a perfect opportunity to go test it. Run your cluster with the traffic you expect to hit and try it both ways with a simple bench script. Keep the one you're happiest with, or pick the simplest if it doesn't make a difference. -Dormando
