Seriously, this is not a problem you should be concerned about, and you should not spend time creating some weird over-engineered solution that solves a problem you didn't have in the first place. Use memcached the way it's supposed to be used. Try it out. Measure response times. I'm pretty sure you will find that the network I/O is insignificant.
Changing the server config during runtime may or may not invalidate the entire cache depending on which server selection algorithm you are using. Your client probably uses libketama, which means that if you have n servers, you invalidate 1/n of the cache by adding or removing a server. /Henrik Schröder On Mon, Feb 7, 2011 at 10:06, Margalit Silver <[email protected]>wrote: > 1) I'm guessing your comment "fear of potential bottleneck" was referring > to my comment ""not to have these servers bogged down in notifications". > That isn't really our main concern. Our main concern because of which we > are hesitant to go towards a full and proper implementation of memcache is > "the time lag that would be caused by a client having to get data from > another server". We only want to do a notification on a DB write which is > very infrequent (relatively), the vast majority of activity is DB reads. > > 2) Can you please tell me what is "spread"? > > 3) What are the implications of adding a server with addserver for a brief > moment and then removing the server, assuming there is some way to do that. > Does it invalidate the entire cache? > > Thanks again for your help. >
