Confused on scaling memcached & persistant connections (w/ thePECL client)

[Adrian Ziemkowski]

I agree, proxy isn't the right answer; pooling is.  

The problem we face with the PHP clients is that each server thread has
its own set of persistent connections, when really they should be pooled
on the physical server.

Personally, I think pooling is in the domain of a good client package,
along the lines of hashing keys to servers... Like how the Java client
has the SockIOPool class. 

- Adrian Ziemkowski

-----Original Message-----
From: memcached-bounces at lists.danga.com
[mailto:memcached-bounces at lists.danga.com] On Behalf Of Jehiah Czebotar
Sent: Friday, March 10, 2006 10:10 PM
To: Brad Fitzpatrick
Cc: memcached at lists.danga.com
Subject: Re: Confused on scaling memcached & persistant connections (w/
thePECL client)

I use the python memcache client, and i'm not sure if i mentioned it on
the list before or not, but I found it pretty easy to write a pooling
memcache class. While I agree with the comments about linux being able
to handle the connections, a smart use of resources is always nice, and
a pooling class addresses that in a much easier/cleaner way than a proxy
would. For me it dropped my connections to a tenth of their previous
number.

http://jehiah.com/download/MemcachePool.py.txt
--
Jehiah

On 3/10/06, Brad Fitzpatrick <brad at danga.com> wrote:
>
> "What's all this talk about reducing connections?  With epoll/kqueue 
> you can get a ridiculous number of connections.  How's a proxy daemon 
> going to help at all?  Then your proxy daemon is going to have a 
> ridiculous number of connections (which is no problem, if you use 
> epoll/kqueue in the proxy daemon), but now you have latency
increases."
>
>
> - Brad
>