Right. It does sound like we'll have to conduct some experiments. Would've been nice to get some other inputs though.
We might make 2000-3000 mgets/sec. 100-500 keys each. On Oct 6, 1:38 pm, dormando <[email protected]> wrote: > > 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
