Manual talk:Memcached

Use the laziest method
Always use the laziest method. Let's take a quick peek at what you've got here for options.


 * 1) Expiration time &mdash; Bad idea.  Updates are now delayed, this is ugly.  On the plus side you might get to relieve some load at this price.
 * 2) Delete cached objects when they have to be updated &mdash; Creating or deleting page X modifies Y, Z, what links here for those, etc etc etc; not the greatest thing in the world to do all at once.
 * 3) Include timestamps and work by those &mdash; Bingo.  This is similar to (2).
 * 4) Delete cache at a button press &mdash; Unautomated.  Might as well bang rocks together to get sparks.

(1) is self-explanitory. We know it's a time-out thing, we know this introduces latency between changes and reflection. Ignore it.

(2) and (3) are actually the same deal; (3) is the lazy version. In (2) it appears that the philosophy is that if you change a page:


 * You must invalidate its cache entry
 * You must then find all "What Links Here" cache entries for newly linked or removed pages, and delete them
 * If the page was created or deleted, you now have to find the page that links to it, and delete that too
 * Categories pages must also be checked in the case of category changes
 * Template changes are a nightmare

Whereas (3) follows the following method if you change a page:


 * Update the timestamp on the cache entry
 * Whenever a "What Links Here" is hit, check related objects in memcache for their timestamps; regenerate if one is newer
 * "What Links Here" also needs to look for deleted pages
 * Deleted and moved pages need to invalidate related "What Links Here"
 * Created and deleted pages are just checked for existence (this could be memcached) and if that changes, the affected page is regenerated
 * Objects vanishing from memcache have their on-disk state verified (existence, modification timestamp, both of which are in the database anyway)
 * Template changes are timestamp-checked, if newer the page is regenerated

(3) turns out to be slightly more complex; but you don't have to megaspider on a change and start cleaning out the cache memory, which will lower the probability of an object being invalidated between any two selected changes. The object may be invalid and need regeneration; but if nobody's accessing it, we can wait. If we invalidate it AGAIN on top of that, we cost precisely 0 added effort to regenerate; we infact saved a wasted regeneration that would have happened with (2).

An interesting idea, when an invalidation actually happens, try using (1) for the unparsed source; that is, pull the database entry into memcached, set an expiration time a la (1), generate the new parsed XHTML output, and cache that in accordance with (3). If you actually need to do it again soon, you'll skip a database lookup; if not, it'll fall out of memcached.

Testing procedure for proper configuration?
Any ideas on how to test proper function? We can see it is running, but it seems silly to plan performance tests to figure out whether it is properly configured (and php correctly compiled with --enable-sockets -- is this the default or how to test that?). Thanks in advance! --Vigilius 20:27, 29 July 2008 (UTC)


 * If it's consuming memory, it's probably working. Use ab to benchmark performance with   and then with   if you want confirmation. —Emufarmers(T 08:28, 30 July 2008 (UTC)

Memcached via UNIX Socket
I'm using a single machine with memcached and Mediawiki 1.14.0. Is there a chance to setup a UNIX Socket like: $wgMemCachedServers = array(   "/var/socket/memcached.sock" ); Any help would be appreciated.

Thanks! crushmaster


 * I think you should be able to just leave $wgMemCachedServers on the default (localhost). —Emufarmers(T 04:59, 29 May 2009 (UTC)


 * Judging by “includes/memcached-client.php” code, MW doesn't support unix sockets for memcached addresses (not in 1.16 yet, at least). And no, leaving the default is unrelated. —HoverHell, 21:10, 23 September 2010 (UTC)

How is it possible to clear the cache?
When I want to change the template of my wiki, many user have because of memcached the old version, although there is a new version online. how can I clear the cache with a ssh command? --tada
 * Hu... Simply restart the memcached daemons ^^ --77.197.123.56 00:22, 27 June 2009 (UTC)
 * Sometimes we can not restart memcached for it is run by root. I use simple mainatenance script such as

<?php $fp = @fsockopen( '127.0.0.1', 11211, $errno, $fsockerr, 1.0 ); fwrite( $fp, "flush_all\r\n" ); --Roma7 13:09, 10 December 2009 (UTC)

Error with memcached
I get an error with memcached and mediawiki 1.15.1

Fatal error: Allowed memory size of 20971520 bytes exhausted (tried to allocate 122880 bytes) in /var/www/mediawiki-1.15.1/includes/db/LoadBalancer.php on line 315

Can anybody help?

Deciding whether to use memcached
What is more important in deciding whether to use memcached &mdash; size or load? E.g., if I have a wiki that's as large as Wikipedia but doesn't have much load, should I still use memcached? Thanks, Tisane 15:03, 8 May 2010 (UTC)

Memcached slows server
Before I had page generation time of about 0.5 seconds, but then I setup a separate server installed with memcached using all default settings. I changed my LocalSettings.php file to use memcached, and now my page load times are about 11.0 seconds. Is this normal for the first couple requests, or what might the problem be? Also, besides changing the settings in LocalSettings.php, and creating the server, is there anything else I need to do? On the page it talks about running "memcached -d -l 127.0.0.1 -p 11211 -m 64". On which server would I run that? --Jer Hughes 05:05, 27 March 2011 (UTC)
 * Use memcached only if you have more than one web server. Otherwise, local caching like APC should be used. Max Semenik 07:06, 27 March 2011 (UTC)