Who's in the mood for a new memcached release?
ag at ag-projects.com
Mon Aug 21 08:06:16 UTC 2006
Using encryption there is always a price to pay in CPU cycles. Also
the TLS handshake needs a few extra round trips to exchange the
certificates and encryption keys so the initial connection takes more
time than plain TCP.
For all practical means the performance is not much affected though.
The end-user may decide if he needs encryption/authentication and if
the trade-off in performance is relevant for the application that
uses it. The code is clean, if TLS support is disabled the behavior
is 100% the same as the original memcached.
The scenario we use it with is a distributed database architecture
where applications can fetch data from remote, not on the same LAN,
memcached in a secure way.
On Aug 21, 2006, at 5:53 AM, Brad Fitzpatrick wrote:
> How's that affect CPU usage and latency? Seems heavy.
> If it can be #ifdef'd out without getting in anybody's way and the
> clean, I suppose it could be included, though I can't see myself ever
> using it.
> On Fri, 18 Aug 2006, Adrian Georgescu wrote:
>> We have built a patch to allow memcached to use encryption and
>> authentication. This version of memcached allows client
>> authentication based on X509 certificates and data encryption using
>> SSL/TLS protocols. It's purpose is to allow secure usage of memcached
>> in untrusted environments like the Internet.
>> The code will be release some time after the holidays, maybe this
>> could be subject of inclusion in a future memcached release.
>> Adrian Georgescu
More information about the memcached