On Sun, Nov 27, 2011 at 10:58 AM, Arjen van der Meijden
<a...@tweakers.net> wrote:
>>
>> 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.
But which client? Usually if you need memcache to scale you will be
running many clients in parallel - and if they are doing single-key
operations in many cases adding more servers will make them completely
separate. It is only multi-gets with many small keys that don't
scale forever.
> 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.
Yes, it is more a matter of using smart clients. But still, you are
likely to have a problem with your backend persistent storage before
you get to that point - especially if you expect to recover from any
major failure that dumps most of your cache at once.
--
Les Mikesell
lesmikes...@gmail.com
