On Sat, Nov 22, 2008 at 4:18 AM, Dieter Plaetinck <[EMAIL PROTECTED]> wrote: > Dusty Phillips wrote: >> >> there's a lot of view based caching going on already, so just changing >> from locmem to memcached for caching should see a significant >> improvement. >> >> Dusty >> > > I don't understand this.. at work we implemented memcached. The huge > benefit we have there is that a central cache which can be used by a pool of > webservers is much more efficient then each webserver needing to maintain > it's own cache. > But in this case, if python/django can cache on it's own, and you use only 1 > server, what's the use of moving the caching to another daemon? Isn't that > just adding more unnecessary context switching? (at least you can go > through unix sock files and not through udp/tcp, but still....) > Or is python/django cache just that bad? (I don't have any experience with > that) > > PS: for php sites that only run on one server I think Xcache is also better > then memcached, no context switching at all... > PPS: do we use an opcode cache already for the php site(s)? eaccelerator? > xcache etc? it can be a huge improvement
APC is used for a PHP opcode cache, so yes, we do have this in place. Django has a caching framework in place- we formerly used filesystem-based caching, but memcached blows this out of the water in every respect. We can now also turn on memcached for MediaWiki, which seems to be a performance improvement. Context switching, really? We already have ~60 MySQL threads, ~60 httpd threads. I *highly* doubt one additional thread for memcached is of concern. -Dan
