Memcache proxy

[mike]

On 11/1/05, Timo Ewalds <timo at tzc.com> wrote:
> 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?

This I do not know. Perhaps it would be best to contact the guy who
made it... maybe he has something in development, or a reason to not
do things a specific way. Knowledge sharing is awesome++

I suppose you could use the pmemcache() function and set a timeout
that's appropriate, and just expect a lot of cross-network memcache
traffic. It might not be able to hit the cache 100% of the time, but I
think it would do it as much as resources allow.

In theory you could use something as simple as datapipe, or perhaps
LVS or some sort of load balancing mechanism to send all your requests
through some sort of proxy idea... but I think that's starting to ruin
the point of data being stored on only one memcache server - it HAS to
connect to that server that is storing that specific key'ed data or
it's pointless.

(Unless you're talking about a "smarter" proxy designed specifically
for memcache which has the awareness of key->memcache server
mappings...

- mike

> 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.

That's true. In my data abstraction layer, I can be guaranteed (in my
own apps) to use it properly. Perhaps an additional [optional] flag to
the wrapper function to attempt to get it from cache/set it in cache
if required (or the inverse, whatever makes most sense.)