What he means is memcache fault tolerance is acheived client side. If  
you are looking to increase capacity of memcache by scaling you have  
to write and read keys from-to different servers; a hash method is  
usually employed so that x number of app servers can all calculate  
which y (memcache) server to ask for a specific key. If you change the  
number of servers the hash values changes essentially orphaning all  
previously hashed and stored keys.  Think of it as  dynamic sharding.

You might employ a write-to-all and read-from-random strategy which  
would be tolerant of memcache role scales, obviously writes would be a  
bottleneck but the hope is you would have a lot more reads than writes.

Currently we just lock the role to one server and don't let it scale,  
when we need more we will lock it to two.

On Sep 3, 2009, at 6:37 AM, Martin Sweeney <[email protected]>  
wrote:

>
>> Why I can set minimum and maximum instances when a new instance goes
>> up all my cached keys are invalidated?
>
> I'm not quite sure what you mean by this, but I'm guessing it means
> something like "what's the point in having multiple instances if the
> new ones don't have the old keys?"
> If so, this is your answer:
>
> By having more servers, it follows that there is more memory or space
> available in which to store your data. If your cache servers are
> getting high traffic, more might start up to meet the demand; you need
> only write once (for example, from the database) for the new key to
> exist on the new server, and for all subsequent requests to be able to
> read it - increasing the speed of your app.
>
> In effect, this is more efficient... the new server will soon contain
> only the data which your application is actually requesting.
>
> Hope that helps,
>
> Martin
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"scalr-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/scalr-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to