Implementing Memcached on EC2

Erik Osterman e at osterman.com
Wed Jan 3 23:42:48 UTC 2007


The biggest latency is that associated with the connection/handshake.
Granted, if connections are persistent, it's not that big of a deal. If
using OpenVPN, the latency is doubled by the mere fact that the traffic
all passes through the concentrator (no full mesh routing). This gets
even worse if the concentrator is offsite from EC2 and you get doubly
charged for the bandwidth. Placing the concentrator on EC2 opens up a
slew of complicated scenarious to solve (no static IPs, what to do when
the concentrator instance dies and how to notify other instances,
etc...). We could use tinc, which provides fullmesh routing, but we'd
still have the single point of failure for authorization (I believe).
Also, just the fact that packets are encapsulated usually in userland
process space, naturally adds to the latency. This latency is usually
negligible to the average user, but for our application the more we can
minimize the lacency, the better.

I do realize that there are some generalizations/assumptions made above.
Certain IPSEC implementations, for example, would move the encryption
into kernel space. There are tons of other VPN solutions as well, most
much more complicated to setup. We really would like to avoid relying on
VPN solutions at this time, if we can.....


Erik Osterman


Artur Bergman wrote:
>
> On Jan 3, 2007, at 2:00 PM, Erik Osterman wrote:
>
>> Yes, almost our entire app runs on a cluster EC2 instances (not a 
>> singular instance). Any memcache access would be taking place across 
>> the Amazon network between EC2 instances. But speaking of latency, 
>> that's another reason why we don't want to introduce a VPN on our EC2 
>> instances for Memcache b/c of the inherent latency associated with them.
>>
>> Ciao,
>>
>> Erik Osterman
>
> What is the inherent latency associated with them?
>
> Artur




More information about the memcached mailing list