Memcache proxy
Timo Ewalds
timo at tzc.com
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.
Timo
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?
>>
>>
>
>
>
>
More information about the memcached
mailing list