The only limits are when you've saturated your internal network or hit the max number of TCP connections that your underlying OS can handle. The amount of nodes make absolutely no difference.
Yes, part of the server selection algorithm gets slower the more nodes you have, but that part is insignificant compared to the part where you actually compute the hash for each key, and that in turn is insignificant compared to the time it takes to talk to a server over the network, so in effect there is no maximum amount of nodes. The memcached server itself consumes very little CPU, don't worry about that. In the typical case you don't build a separate cluster for that, you just use whatever servers you already have that have some spare RAM. /Henrik On Sat, Nov 26, 2011 at 06:05, moses wejuli <[email protected]> wrote: > hi guys, > > not sure if this has been asked (and answered) before, but thought i might > ask away anyway... > > what would be the recommended maximum number of nodes in a memcached > server pool (cluster) ...? am thinking u cannot go on indefinitely adding > nodes without some sort of performance penalty -- a 100-node homogeneous > cluster will probably hash faster than a 2000-node homogeneous cluster??! > with additional network issues for good measure?? > > any pointers would be very helpful!! > > oh, and what wud be the optimal node specs in such a case (particularly > CPU cores)? > > thanks, > > -m. > > >
