If I use local socket I do not get distributed cache. Local socket is good solution for end user, but it&#39;s not good<br>for multiple hosting servers with distributed platform data stored in cache.<br><br><br>&gt; If you add some auth layer inbetween in my opinion the whole idea of
<br>&gt; ultra-fast data reading probably will be lost..<br><br>That&#39;s a good question , it&#39;s certain that authentication will take some time, but only while initializing <br>memcached session. Keeping connection to memcached is suggested way of using in order to
<br>get best performance. Once authenticated connection later will work as fast as there were no authentication.<br>Authentication can be added as configurable option during startup.<br>
<br><br>Let&#39;s make an approximation. Let&#39;s suppose that getting connection authenticated data is done with password.<br>Time spent in matching passwords will be around 2 times cpu usage of getting&nbsp; data from memcached (fetch auth data + memcmp), and data transfer of authentication will take time as simple get or version request. I&#39;ll make assumtion that in worst case authentication would last as two get or two version requests.
<br><br>That would say that after 100 get requests while keeping connection open you will have performance equal<br>100 get actions + (auth=2get actoins), =&gt;102 get times, and performance will be degraded 2%.<br>on 1000 get actions you get 
0.2% , on 10k get requests ...<br><br>What are experineces of users on this list ?<br>
How do you use memcached ? Do you keep open connection ?<br> What is common average of get requests per connection in your use case ?<br><br><br><div><span class="gmail_quote">On 2/8/07, <b class="gmail_sendername">Reinis Rozitis
</b> &lt;<a href="mailto:roze@roze.lv">roze@roze.lv</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Use sockets (only limitation is that memcache must reside on the same
<br>host/box as the php).<br>Launch multiple memcaches processes and give each user read/write acces to<br>only one particular socket, that way they can&#39;t connect to another MC<br>instance. By doing this you can also limit how much memory each user can
<br>use.<br><br>If you add some auth layer inbetween in my opinion the whole idea of<br>ultra-fast data reading probably will be lost..<br><br>rr<br><br><br>----- Original Message -----<br>From: Milos Prodanovic<br>To: <a href="mailto:memcached@lists.danga.com">
memcached@lists.danga.com</a><br>Sent: Thursday, February 08, 2007 12:37 PM<br>Subject: memcached in not so friendly environment<br><br><br>Hello,<br><br><br>I&#39;m planning to use memcached in mass hosting environment. In general that
<br>would say that any php user can access data<br>that is stored in memcached, even if this memcached data is only for hosting<br>platform use. Common usage of memcached is in friendly<br>environment, where you hold strings, application, network and other
<br>resources, and there is no user application allowed.<br>I need to protect access to memcached. Firewall is not an option, hidden<br>interfaces and private networks can be scanned, and other obscurity ways are<br>not option.
<br><br>I&#39;ve read memcached list discussion on authentication. There are few<br>possibilities that I can think of:<br>a) Restrict memcached to accept conections from TCP port that is less than<br>1024, that would be quite fast solution, and it&#39;s based on fact that you are
<br>the only one with root account on client side.<br>b) crypt and sign data (content) stored on memcache, so even if users get<br>access to memcached they can&#39;t poison data but they can exhaust memory :(<br>c) implement authenticaiton (exact way should be discussed)
<br>d) secure transport (includes authentication - already suggeste on list and<br>done)<br>e) put some kind of tcp wrapper in front of memcached,and let tcp wrapper<br>handle authentication<br><br>Maybe someone has already nice working solution ?
<br><br>I&#39;ve understood that authentication was proposed more than once, and it was<br>rejected protecting memcached performance.<br>One sent url with encrypted memcached (TLS). It&#39;s easy to implement<br>authentication as private patch, but there is no sense
<br>if it&#39;s not accepted as patch in main memcached code.<br><br>If using memcached in not so friendly environment&nbsp;&nbsp;is not so frequent,&nbsp;&nbsp;then<br>private patch is the best scenario.<br>If this is not so rare case of memcached usage, let&#39;s discuss authentication
<br>once again.<br><br>What do you think ?<br><br><br>Kind Regards<br><br>Milos<br><br><br></blockquote></div><br>