Multiple nodes vs multiple servers

Steve Grimm sgrimm at facebook.com
Thu May 10 17:52:17 UTC 2007


We tried to go the proxy route at one point and ended up not using it (at
least not as a generic ³send everything through it² proxy as originally
planned) because even without any batching of requests, the added response
latency of passing everything through another user process made our
application measurably slower. A big percentage of our page generation time
is spent waiting for memcached requests to come back, so anything that
systematically increases memcached round-trip times is generally a huge
no-no for us. We¹ve actually selected the operating systems on some of our
servers based largely on the latency variance in their network stacks, no
joke.

However, in an environment where you are not so latency-sensitive ‹ and I
guess yours qualifies, if I¹m correct in thinking your client is doing
Nagle-style ³wait a little while to see if another request happens so we can
batch them together² -- that may not matter so much and a proxy may be a
reasonable approach.

-Steve 


On 5/10/07 10:35 AM, "Dustin Sallings" <dustin at spy.net> wrote:

> 
> On May 10, 2007, at 10:19 , Les Mikesell wrote:
> 
>> 
>> How graceful is the system about making these changes while in production? 
>> If you add servers do you have to stop the clients to reconfigure to use
>> them, and is there any problem other than less than optimal caching while
>> some clients run with the old setup?
>>  
> 
> The memcached nodes don't care.  They don't know about each other.
> 
> The clients are where the issue is.  For example, where I'm using my java
> client, I initialize it at application startup time and inject it where it's
> needed.  This effectively leaves me with no reconfiguration facility.
> 
> Alternatively, I could more dynamically access my client and a means of
> pushing a new config into it and the users of the client wouldn't care at all.
> 
> I've mentioned a memcached proxy that I think would be an ideal solution this
> problem as well as providing a performance benefit from multi-process
> applications.  I haven't written any of it yet, though.
> 
>  
> -- 
> Dustin Sallings
> 
>  
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070510/6967cdd5/attachment.htm


More information about the memcached mailing list