On Feb 7, 1:06 am, 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.
I was referring to "we are hesitant to do so because of the time lag that would be caused by a client having to get data from another server" You are concerned about something you haven't measured, but you think will negatively affect you. This is a completely standard deployment of memcached. This is why we wrote this page: http://memcached.org/about -- having 4x more memory is going to make a big difference to you. You should use it. If it actually doesn't work for you, then you should consider what you might need to change. It may very well not be memcached. > 2) Can you please tell me what is "spread"? Spread is what you'd be reinventing when trying to build a reliable distributed cache invalidation mechanism to avoid a typical deployment of memcached. http://www.spread.org/ > 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? This is also not a normal practice. I don't know exactly what you'd be trying to accomplish by doing this, but I think the behavior would hard to reason about.
