Memcache proxy

Timo Ewalds timo at
Tue Nov 1 20:57:37 PST 2005

Does php-mcache support connection pooling or similar? Having over 2000 
php children across 36 servers, each with persistent connections to 30 
memcache servers just seems rediculous when a proxy setup would reduce 
that to only one connection from each physical webserver. At least with 
pooling those 2000 children would share their connections. I know 
memcache can support huge amounts of connections, but can it support 
enough? can php support enough?

At the moment, I don't use memcache at the db abstraction layer, and 
don't plan to. There are many things that don't make sense to cache 
(write only stuff like logs, things that change virtually every page). 
Doing it intelligently without knowing knowing the actual use cases is 
somewhere between hard and impossible. If it was easy, the db would do 
it itself. Like you, I don't create the db connections until they are 
needed. Most pages don't touch most of the dbs.

Btw, for those that care, I am pushing over 1000 memcache backed pages 
per second, about 600/s of those being db backed.


mike wrote:

>That's what I was thinking, along those lines - the biggest drawback
>is the multiple server support.
>This PHP extension might fix that.
>It's modified to support multiple memcache servers. I suppose the rest
>of it is just figuring out how you'll create the keys for all the
>different types of get/set behaviors... (that's in the stage I'm at as
>well...) - if anyone has good examples of how they've added memcache
>in to their sites for ALL queries, I'd love to see them (why reinvent
>the wheel, and there might be some 'gotchas' I could learn from.)
>I expect that memcache would be put into your database abstraction
>layer somewhere (depending on what layer you use, etc) - or a data
>abstraction layer (where you're not aiming for vendor-inspecific
>functionality, but aimed more at adding additional functionality on
>top of a standard call - i.e. I have a db_query() call which checks to
>see if the database handle has already been established; if not, it
>will establish it for me. Makes for no unneccessary connections and a
>central connection point, no need to mysql_connect() every single
>script, etc.)
>I figured what I would do, especially for prepared statements, where
>the parameters will be fed separately into the function, is that I can
>use these differentiating data points to create the key (and I
>suppose, I'll have to figure out a way to dirty/unset the cache on any
>DELETE, UPDATE, etc. - that's where I could use the best pointers...
>perhaps someone has a BKM for that.)
>- mike
>On 11/1/05, Ask Bjørn Hansen <ask at> wrote:
>>Why not just fix the PHP client?

More information about the memcached mailing list