Your leaving? I did not know.

Thanks for the help with the themes...and for the new cache store! 

You'll be missed...

Cheers

Mary

Byeeeee - All the best...

Sam,

Thanks for taking the time to work on this.  Over the last few years I've used the XCACHE, and memcache stores in both my test and production environments.  (My production server is running MS Server 2008r2 and currently hosts a few Moodle instances ) Here are a few things I found:

In a single server environment running on MS windows the Xcache store worked generally worked well depending on the type of data stored in it.  If I remember the only issue I had with it was storing course group information, where it the data being cached was not always simple keys (CONTRIB-4318)

When I upgraded PHP to 5.5 I started using optcache in place of XCACHE since the Moodle environment check recommends it. Since optcache cannot work as a cache store, I am using memcache to as the cache store for the bulk of the high traffic data on my site.  (This is because I had issues getting memcached to work properly under windows)  If redis is a viable alternative to memcache for those of us on a single server install, then I would support moving it into core.  I currently have a couple instances of memcache running (one per install) and it seems to be working well.

All I ask is that you don't force those of us on Windows to have to use the file cache for everything since it is rather slow.  And before someone comments that we are free to install a different cache store from the plugin directory, While cache stores can be installed, they cannot be removed (MDL-45498)

So my vote would be:

+1 for xcache (assuming CONTRIB-4318 is addressed)
+1 for Redis
-1 for Memcache (It works well in a single server / application environment)

-Steve

Hi Sam,

Thanks for all the hard work and I look forward to continuing to work with you in your future endeavours.

I've just peer reviewed your Redis plugin, which I must say looks spot on. I've been looking at Redis for several years now and when I last looked at writing a plugin the php support was a little too immature so I'm really keen to see this now.

As I mentioned in my review, I'd give this a -1 for inclusion in core, and I do so for the following primary reason:

Redis requires both a server and a php extension which are non-standard in a typical installation. I don't think it's unreasonable to ask that an administrator installs the Redis plugin from the plugins database too.

I also agree that we should remove the memcache plugin for the reasons that you list (also because it just completely sucks because of the memcache extension itself), and we should remove the mongodb plugin. If nothing else, having some of these plugins in core legitimises their use and, as we've found, they are not really ideal for use in core for several of the reasons you mentioned.

With regards APC and XCache, I'm less convinced. OPCache is now standard in PHP 5.5, and I think we should be looking at prioritising caches which are standard and do not require a large amount of installation, and configuration. That said, they are useful caches, for older installations which you find with a lot of shared hosting providers. Similarly, Wincache is useful for those windows installations which people insist on running. Providing Wincache in core again legitimises use of Windows as a valid server environment. For anyone interested in running on a windows server, I don't think it's unreasonable to ask them to install the Wincache plugin.

So in summary, my votes:

• APC addition: +- 0
• XCache addition: +-0
• Wincache addition: -1
• Redis addition: -1
• memcache removal +1
• mongodb removal +1

Andrew

My thoughts are: 

• We should have a small set of backend choices with some helpful advice for what suits each Moodle deployment scenario. By sticking to a small set in core, we support each well.
• It looks like an opcode cache solution is a gap in our small set and it would be good to have one in core for single-server sites.

So:

1. I would like see only one 'winner' chosen between xcache/apc etc to go into core. Lets have one and focus our 'core' energy on that working well. 

2. It sounds sensible to remove mongo, I don't expect it to affect many of our users (based on issues reported).

3. I suspect memcache removal might affect more users (because we gave too much choice in the first place), but memcached is the alternative and it is justifiable to me to remove the confusing choice between the two.

4. Outside of core, the community can develop any promising alternatives, but lets make some simple choices. A problem we have with MUC is making it too flexible and so hard for people to choose their configuration. 

Good luck in your new position Sam.

Why is "everybody" leaving Moodle HQ?

First Petr Skoda. Now Sam... Who next? (Is Totara pinching all the Moodle HQ developers?)

-1 the memcache store removal.

Users that have RHEL for their servers will have some difficulty with getting the memcached php extension currently as I have not seen a new release software collection with it. 

I am nearly done building a LAMP cluster that is using memcache and it works just fine. Memcache was not my first choice but using a third party repo to get php memcached installed was out of the question.

It would be make upgrading to moodle 2.9 VERY difficult to do if memcache is no longer supported (depending how memcache acts being a add on instead of part of core moodle code). 

PS: How does this change impact memcache if it is a add on plugin when it comes to session handling?