Nick Kew wrote: > On Fri, 02 Feb 2007 09:11:16 -0500 > Brian Akins <[EMAIL PROTECTED]> wrote: > >> Basically, mod_memcache could have this config: >> >> MemCacheServer memcache1.turner.com:9020 min=8 smax=16 max=64 ttl=5 >> MemCacheServer memcache4.turner.com:9020 min=8 smax=16 max=64 ttl=5 >> MemCacheServer memcache10.turner.com:9020 min=8 smax=16 max=64 ttl=5 >> >> or whatever. This would end the config duplication between various >> modules. This module could also add memcache stats to /server-status >> >> Comments? > > Sounds slightly analagous to mod_dbd: what I describe as a service > module in the book. Ending config duplication sounds like a Good > Thing, for the same reasons as DBD. > > Couple of thoughts: > > * What's the system overhead of memcache? Is it similar to DBM?
Not sure what you mean... it mostly means lots of extra TCP sockets open all the time. > * I'm not really familiar with memcache, but the semantics look > somewhat like DBM. Would there be any mileage in supporting > a DBM store in a unified functional API? It supports more things; Like timeouts and some other things like increment/decrement counters; It could be done on top of DBM, but I'm not really interested in it. > * Is it inherently thread-safe, or will you be needing a reslist > or similar solution? > apr_memcache internally uses a reslist, and itself is 'thread' safe once configured. -Paul
