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

Adrian Ziemkowski aziem at
Mon Mar 13 14:06:47 UTC 2006

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
[mailto:memcached-bounces at] On Behalf Of Jehiah Czebotar
Sent: Friday, March 10, 2006 10:10 PM
To: Brad Fitzpatrick
Cc: memcached at
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

On 3/10/06, Brad Fitzpatrick <brad at> 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
> - Brad

More information about the memcached mailing list