Manual talk:Memcached

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

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 — 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 — 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 — Bingo. This is similar to (2).
4. Delete cache at a button press — 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.

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

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 $wgMainCacheType = CACHE_MEMCACHED; and then with $wgMainCacheType = CACHE_NONE; if you want confirmation. —Emufarmers^(T|C) 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|C) 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)

Is this still impossible??? I am using a hosting that does noe allow memcached with ports because of the security problems... this shouldn't be too hard to implement, right?? JEH 2013-08-11

Hi folks!

I've managed to get unix domain socket connections to work with MW Memcached:

$wgMemCachedServers = array("unix:///var/socket/memcached.sock:0");

and then configure your memcached.conf, making sure to deactivate -p and -l options and set -s and -a accordingly. Here's a sample memcached.conf:

# unix domain socket makes it faster, no TCP overhead
# be sure to disable -l 127.0.0.1 and -p 11211
-s /var/run/memcached/memcached.sock
-a 0766

I submitted a simple patch to get it working - https://gerrit.wikimedia.org/r/#/c/104663/

--Jnatividad (talk) 21:14, 30 December 2013 (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 — 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)

Thanks for the reply. I am using more than one web server. I think I found my problem, but not yet a solution. I think MediaWiki is trying to connect to the memcached server, but is timing-out after about 10-seconds. I do know that my unmodified memcached server is working, as I'm able to successfully run a php test script (outside of MediaWiki but on the same server as it). In my error logs on my MediaWiki server, I'm getting the following errors when MediaWiki is configured to use memcached:

[27-Mar-2011 17:35:43] PHP Warning:  Illegal offset type in isset or empty in [...]/w/includes/memcached-client.php on line 958
[27-Mar-2011 17:35:43] PHP Warning:  Illegal offset type in isset or empty in [...]/w/includes/memcached-client.php on line 965
[27-Mar-2011 17:35:43] PHP Warning:  Illegal offset type in isset or empty in [...]/w/includes/memcached-client.php on line 958
[27-Mar-2011 17:35:43] PHP Warning:  Illegal offset type in isset or empty in [...]/w/includes/memcached-client.php on line 965
[27-Mar-2011 17:35:43] PHP Warning:  Illegal offset type in isset or empty in [...]/w/includes/memcached-client.php on line 958
[27-Mar-2011 17:35:43] PHP Warning:  Illegal offset type in isset or empty in [...]/w/includes/memcached-client.php on line 965
...

--Jer Hughes 22:46, 27 March 2011 (UTC)

Perhaps the server you're trying to connect to isn't actually the one running memcached, or perhaps it's firewalled so that you can't reach it, or maybe you're not connecting to it properly. It's pretty hard to tell, since you haven't told us anything about your configuration. —Emufarmers^(T|C) 04:21, 28 March 2011 (UTC)

I'm pretty sure its not a firewall or memcached server issue, because I can connect to that server, and see things caching, when running simple memcached test scripts on the server MediaWiki is running on. I'm thinking that it is a connection issue, but I just don't know where. I did some profiling and came back with these results:

10.542311      1 - MediaWiki::performAction
10.542140      1 - Article::view
10.170179    193 - wfMsgReal
10.004816      1 - MessageCache::load
0.641324      1 - WebStart.php-conf
0.316287      1 - Parser::parse
0.316239      1 - Parser::parse-unknown
0.305995      1 - MediaWiki::finalCleanup
...

Further, the only settings I have for memcached on the wiki server is:

$wgMainCacheType = CACHE_MEMCACHED;
$wgMemCachedServers = array("XX.XX.XXX.XXX:XXXXX"); // Using my real IP address and port

--Jer Hughes 01:25, 26 April 2011 (UTC)

Move of wiki/memcached to Manual:Memcached

This should be moved to the Manual namespace...
-- Timmay911 (talk) 21:16, 15 January 2017 (UTC)

• Seems the same to me, seconded. —Mainframe98 _talk 13:06, 15 February 2017 (UTC)
• I agree too, article should be in the manual namespace GregRundlett (talk) 14:16, 25 July 2017 (UTC)
  •  Done by SamanthaNguyen. —Mainframe98 _talk 05:58, 8 October 2017 (UTC)

Use of Memcached for sessions not recommended by Memcached

Is it worth noting somewhere that Memcached docs recommend not using Memcached for sessions? and potentially recommending that anyone wanting to follow that advise use `CACHE_DB` instead?

Redis is a good alternative, since it allows to store data on disk, preventing (most) data loss on server restart. --Ciencia Al Poder (talk) 08:52, 16 August 2021 (UTC)