Tim Hunt

Interstingly, Moodle HQ seem to have made a copy of the Totara code-base publicly available on Github at https://github.com/moodlehq/totara. Long overdue. Thanks to whoever made that happen.

We have been performance testing Moodle 2.5.2 at the OU, in preparation for deploying it in December. Here is a very brief summary of what we found.

Our test script tests the most common pages our students user, something like

• Visit course page
• Visit some resources
• Visit some forum threads
• Make a forum post

On the test hardware, Moodle 2.4.3 (the version we are currently running) was giving 0.33s average page-load times.

Our initial run with Moodle 2.5.2 gave 0.41s.

The basic issue there is that there are a lot of new caches, which default to being stored on disc in moodledata. In a clustered environmant, moodledata is on a networked file system, so quite slow.

So, as expected, we had to re-configure most of the new caches to use memcache. The singificant change came from moving the pluginlist cache to memcache. That brought the average times down to 0.36s. None of the other caching changes made a measureable difference.

That is about where we are at. We are going to have to live with our 2.5.x being 10% slower than 2.4.x.

Note that we are using Eric Merrill's clustered memcache implementation: MDL-42071 for some of the caches. (Thanks Eric.) However, it seems to be fractionally slower than the local memcache hack we were using before. We don't know why. If we can work out what is going on there, we will post in the tracker issue. It is still much faster than non-clustered memcache for read-heavy caches.

(As an aside, I think our results reinforce my point that in the testing that HQ do - e.g. http://docs.moodle.org/dev/Moodle_2.6_release_notes/Performance_tests - they really need a set-up with moodledata on a different box from their web server.)

Also, I should point out that I am just posting these results. I have not done any of the work to generate them.

I have broken this out of the other thread we were having. I said that there are serious underlying problems there, but there wasn't a summary anywhere of what those were.

In an attempt to be useful, I thought I would try to summarise the major problems that I know about.

When I say their are major problems, I do realise that the gradebook works for most people, most of the time. The problems only come in obscure corner cases, where different options in different places conflict. The problems arise in only those edge cases, but when they do they are almost impossible to fix because the conflicts are fairly fundamental.

Actually, this is getting quite long, so I will do a separate forum post for each issue.

Following the developer's hackfest last year, Amy Grosheck and other started working on http://docs.moodle.org/dev/HTML_Guidelines, which seemed like a good idea. People have often said here that we should have better guidelines to make the HTML in Moodle to be more consistent.

The problem is what happened next. The Moodle HQ frontend team decided to start trying to implement those guidelines, even though they are not really finished, and they have not been discussed much.

And the real problem is that what has actually been done in response to that spec (MDL-40685, MDL-41615) is that they have added lots of additional headings to all the different Modules in Moodle core. (But they have not yet documented what they have done, to explain to third-party module developers how to update their modules in a consistent way.) They have done this by adding lots of separate $OUTPUT->heading() calls in lots of separate *.php files.

I have several problems in this:

1. When you are studying a particular activity, e.g. reading a book or forum, or taking a quiz, you know what you are doing. Those headings waste space on every page that would be better taken up by the learning material.
2. The information about the current course and activity are already in the page header. (So, if it is desirable to have the current course and activity name marked up as headings in the HTML, for accessibility, just change the markup in the header. It is certainly undesirable for screen-reader uses to have the same text repeated redundantly after the skip to main content link target.)
3. The the goal is to be consistent on every page, why has this been implemented has separate calls to $OUTPUT->heading all over the codebase, why was this not just implemented once in a renderer method, guaranteeing that the way this is displayed on every page is consistent, and making it possible for themes to override how this is displayed?

Anyway, that is what going on and why I am concerned. However, you folks know much more about design and what theme developers need that me, so perhaps you tell me to stop worrying; or you can confirm my worries and help to propose a better solution before it is too late. Thanks.

Sometimes we get feature requests in the tracker that are good ideas in themselves, but which should not be done  in the standard Moodle release. (E.g. MDL-42312).

At the moment, the only option is to close these as Won't fix, which seems a bit harsh.

I am wondering if we add a new resolution: "Better as an add-on".

Thoughts?