Hardware and performance

Paul is right... if you are swapping from one in-memory cache to another I wouldn't expect to see much difference. 

Unfortunately, I have no idea why the memcached store is incompatible with some of the caches. I have asked the question a number of times but (as yet) no response from the devs. 

1. I think Paul's explanation above implies 'no'. Memcached does not work in a suitable manner for this. If I read correctly he is saying that being unable to *guarantee* that memcached will have the record is the issue.

2. Not as such, but if you are using the same resource multiple times then it should be cached by the user's browser. Failing that you might consider some sort of reverse-proxy. 

3. Isn't Varnish a reverse proxy? I'm not familiar with it. If you do a search then there have been some discussions about it. 

I've tinkered with Varnish and Moodle and IMHO there is little point to it. The dynamic nature of moodle content, coupled with the need for permissions checks on almost everything served means that Varnish has very little it would be able to cache.

For example even with sites which work well with Varnish, such as wordpress, you still configure Varnish to not cache in areas where context and permissions are important, like the wp-admin pages. This is the case for almost all content on Moodle.

There are exceptions like content under themes, but you need to balance marginal gains against complexity of the deployment. Remember though, "premature optimization is the root of all evil". That said I have explored this before myself and you can read about that here (beware it is nginx specific).

What you DEFINITELY DO WANT to do is ensure you serving your static content using 'X-Sendfile' (or it's equivalent for you httpd) see Performance_recommendations for more on that.

Specifically regarding sessions the default session cache is defined in your config.php and NOT via the MUC (I know it's confusing having sessions stuff listed there). In the config.php you CAN specify Memcached as your session store and this is not a bad idea...  see config-dist.php there are 'gotchas' to consider though so read the docs.

Hello,

On point 1, yes you can map sessions to memcached. To do that, refere to the "config-dist.php" in your installation. You would find the information you need if you look for this: "Memcached session handler". I would be cautious though. If you reboot the memcached daemon while in production, you will loose all sessions along with all of the information they carry. Memcached does not persist its data to disk.

On point 2, Not easily, beyond what it already does, which is quite a lot. All content created in Moodle gets "Cache-Control" settings which are pretty good and things will get cached at browser level at the client. What I am assuming you are trying to do is accelerate the delivery of those at the server side with Varnish, which while a very good tool, is not something I would recommend for Moodle as I describe below.

On point 3, you are correct that it is possible to use Varnish to work with Moodle, but as mentioned in the forum, it would be in rather limited fashion based on the dynamic nature of Moodle content. In addition, Varnish will not handle SSL content at all, so you have to keep that in mind as well. You can get similar effect at far less "complexity" cost with just using your web server's caching capabilities. For vast majority of cases that would be more than enough, including what I would venture a wild guess is your use case. I have had success, in using Nginx to cache all static content as defined by Moodle itself. Usually this means, style sheets, java scripts images with proper "Cache-Control" headers. It is possible as well to specify exactly which type of content to cache and even set headers if not already specified. Same can be done with Apache as well.

Hope this helps.

Just another thing about sessions - people already answered this but to make it explicit, the 'Session cache' store simply uses the PHP session data mechanism. You can configure that PHP session data mechanism via Moodle settings in config.php but this is completely separate from MUC, as per the information others provided.

Our system is configured to store sessions in memcache, which is good with multiple front-end servers. We use a different memcache server for sessions than for MUC which may be a good idea as it means you can (manually) purge/restart those servers, or they can crash or whatever, without losing the other type of data.

In MUC, probably everything that uses session cache should be left there (?) - it's basically stuff that should be cached specific to an individual user for the duration of the session.

Incidentally, leaving aside the sessions and going back to MUC, the MUC memcache configuration that works for us with multiple web servers is to have a local memcache server that runs on each web server. We have then set the system up so that when it stores data to a cache, it stores it to all the different ones, while when it reads it, it reads from localhost. As the caches are read a lot more frequently than written, this can be more efficient - using memcache over a network means you essentially have to wait for a network ping (maybe 0.5ms) for each cache read, whereas localhost is close to zero. (I think basically all the caches that allow it are configured to use memcache in this way.)

--sam