memcached in not so friendly environment

[Milos Prodanovic]

If I use local socket I do not get distributed cache. Local socket is good
solution for end user, but it's not good
for multiple hosting servers with distributed platform data stored in cache.


> If you add some auth layer inbetween in my opinion the whole idea of
> ultra-fast data reading probably will be lost..

That's a good question , it's certain that authentication will take some
time, but only while initializing
memcached session. Keeping connection to memcached is suggested way of using
in order to
get best performance. Once authenticated connection later will work as fast
as there were no authentication.
Authentication can be added as configurable option during startup.


Let's make an approximation. Let's suppose that getting connection
authenticated data is done with password.
Time spent in matching passwords will be around 2 times cpu usage of
getting  data from memcached (fetch auth data + memcmp), and data transfer
of authentication will take time as simple get or version request. I'll make
assumtion that in worst case authentication would last as two get or two
version requests.

That would say that after 100 get requests while keeping connection open you
will have performance equal
100 get actions + (auth=2get actoins), =>102 get times, and performance will
be degraded 2%.
on 1000 get actions you get 0.2% , on 10k get requests ...

What are experineces of users on this list ?
How do you use memcached ? Do you keep open connection ?
What is common average of get requests per connection in your use case ?


On 2/8/07, Reinis Rozitis <roze at roze.lv> wrote:
>
> Use sockets (only limitation is that memcache must reside on the same
> host/box as the php).
> Launch multiple memcaches processes and give each user read/write acces to
> only one particular socket, that way they can't connect to another MC
> instance. By doing this you can also limit how much memory each user can
> use.
>
> If you add some auth layer inbetween in my opinion the whole idea of
> ultra-fast data reading probably will be lost..
>
> rr
>
>
> ----- Original Message -----
> From: Milos Prodanovic
> To: memcached at lists.danga.com
> Sent: Thursday, February 08, 2007 12:37 PM
> Subject: memcached in not so friendly environment
>
>
> Hello,
>
>
> I'm planning to use memcached in mass hosting environment. In general that
> would say that any php user can access data
> that is stored in memcached, even if this memcached data is only for
> hosting
> platform use. Common usage of memcached is in friendly
> environment, where you hold strings, application, network and other
> resources, and there is no user application allowed.
> I need to protect access to memcached. Firewall is not an option, hidden
> interfaces and private networks can be scanned, and other obscurity ways
> are
> not option.
>
> I've read memcached list discussion on authentication. There are few
> possibilities that I can think of:
> a) Restrict memcached to accept conections from TCP port that is less than
> 1024, that would be quite fast solution, and it's based on fact that you
> are
> the only one with root account on client side.
> b) crypt and sign data (content) stored on memcache, so even if users get
> access to memcached they can't poison data but they can exhaust memory :(
> c) implement authenticaiton (exact way should be discussed)
> d) secure transport (includes authentication - already suggeste on list
> and
> done)
> e) put some kind of tcp wrapper in front of memcached,and let tcp wrapper
> handle authentication
>
> Maybe someone has already nice working solution ?
>
> I've understood that authentication was proposed more than once, and it
> was
> rejected protecting memcached performance.
> One sent url with encrypted memcached (TLS). It's easy to implement
> authentication as private patch, but there is no sense
> if it's not accepted as patch in main memcached code.
>
> If using memcached in not so friendly environment  is not so
> frequent,  then
> private patch is the best scenario.
> If this is not so rare case of memcached usage, let's discuss
> authentication
> once again.
>
> What do you think ?
>
>
> Kind Regards
>
> Milos
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070209/76ac538b/attachment.htm