Thanks Henrik. Thanks Arjen. On 26 November 2011 13:15, Arjen van der Meijden <a...@tweakers.net> wrote:
> Wouldn't more servers become increasingly (seen from the application) > slower as you force your clients to connect to more servers? > > Assuming all machines have enough processing power and network bandwidth, > I'd expect performance of the last of these variants to be best: > 16x 1GB machines > 8x 2GB machines > 4x 4GB machines > 2x 8GB machines > 1x 16GB machines > > In the first one you may end up with 16 different tcp/ip-connections per > client. Obviously, connection pooling and proxies can alleviate some of > that overhead. Still, a multi-get might actually hit all 16 servers. > > Obviously, the last variant offers much lower availability. > > Best regards, > > Arjen > > > On 26-11-2011 12:47 Henrik Schröder wrote: > >> 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 <m.wej...@gmail.com >> <mailto:m.wej...@gmail.com>> 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. >> >> >> >>