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?
> 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.
--
Les Mikesell
[email protected]
