Memcache proxy

[Andreas Vierengel]

Am Dienstag, den 01.11.2005, 21:57 -0700 schrieb Timo Ewalds:
> 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?

Why do you think that memcached can't cope with 2000 persistent
connections? It depends on libevent how scalable memcached is in terms
of connections. If it uses epoll() on linux it is O(1). That means it
doesen't matter if you have 100, 1.000, 10.000 or 100.000 connections to
each memcached. Each connection on the server needs a very low
memory-footprint structure. I would think of such a proxy only if I hit
a limit in libevent and it is no bug :)
Another piece of software in the middle only brings problems and costs
ressources and latency.
Also I don't see a problem in the php-children itself. Each children
holds 30 persistent conenctions and according to your numbers, each
webserver has about 60 children, so your OS has to manage 1800 sockets,
which is not a problem.

I run a site with about 3500 perl-children and 4x 2GB RAM, P4-3GHz
memcached-server. In peak times I do about 20k of get/sets per second
with < 20% cpu utilization. At present I have about 1.5 GB of data in
all servers, but data is highly fluctuable.
Im planning to use much more memcached-servers in future for purposes
which need much more memory.
Also I must admit that I wrote my own oo-perl-client (which is of course
slower as the standard one, because I don't use closures). I didn't like
the idea of invalidating key-distribution if one server crashes.

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

Andy

> 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.
> >http://www.klir.com/~johnm/php-mcache/
> >
> >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 develooper.com> wrote:
> >
> >  
> >
> >>Why not just fix the PHP client?
> >>    
> >>
> >
> >
> >  
> >
>