System architecture best practices - memcached + webfarms
Dustin Sallings
dustin at spy.net
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