On 26-11-2011 22:31 Les Mikesell wrote:
On Sat, Nov 26, 2011 at 3:19 PM, Arjen van der Meijden<[email protected]>
wrote:
On 26-11-2011 19:28 Les Mikesell wrote:
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.
That doesn't make sense. Why would you expect 16 servers acting in
parallel to be slower than a single server? And in many/most cases
the application will also be spread over multiple servers so the load
is distributed independently there as well.
Why not? Will it really be in parallel? Given that most application code is
fairly linear (i.e. all parallelism will have to come from the client
library). Even with true parallelism, you'll still have to connect to all
servers, be hindered by slow starts, etc (a connection pool may help here).
Are you only expecting to run one client that only makes one query at once?
Obviously not. But the performance is mostly interesting from the
client-perspective, that's the one your users are waiting on. If you can
manage to send every user's request to only a few memcached-instances,
regardless of how many there are, than the server side is basically just
resource planning.
So in that regard, there isn't really an upper limit to the amount of
servers. But for practicality, you'll likely be limited by the amount of
connections the clients will have to maintain, to actually effectively
use memcached. Although with current client libraries and smart use of
memcached, that may well be in the high thousands.
But from Dormando's response, I still gather that its actually a good
idea to not just add more servers. You'll have to do it in a smart way,
so your clients won't be connecting to a different server for every key
they look up (just maintaining the list of available servers will become
tricky at some point ;) ).
I'm just wondering whether the connection and other tcp/ip overheads will be
outweighed by any load-spreading gains. Especially since memcached's part of
the job is fairly quick.
If you are facebook-size, you might want to convert to udp, but I
thought that was more more of a number-of-client-connection issue for
them from a bazillion preforked apache processes all connecting
separately to the servers.
