System architecture best practices - memcached + webfarms

Dustin Sallings dustin at
Mon Jul 2 23:34:05 UTC 2007

On Jul 2, 2007, at 15:16 , Brad Fitzpatrick wrote:

> But even without that, your web nodes should already have all the TCP
> connections open to all the memcaches (or most of them), so then your
> get_multi implementation should just do a non-blocking write to all of
> them "at once" (actually in serial, but you're not waiting for a  
> reply, so
> network latency, so it's pretty much "immediate"), then you select/ 
> epoll
> on them all at once, reading from them in order.  If your  
> implementation
> does a serial get_multi to each one, then the network latency over 100
> requests will kill you, and you should fix the client API you're  
> using.

	What do you do if you get responses back for a single key from more  
than one server?

	I suppose the client would need to be able to rank responses by the  
likelihood that a given response is authoritative.

	Having the clients broadcast seems like a fairly good idea, though.   
It seems that any delete operation should be broadcast, perhaps  
always broadcasting a delete to all other nodes when a given node is  
sent an update.  That should be particularly cheap with udp.

Dustin Sallings

More information about the memcached mailing list