NOTE: The graphs within this post have been updated based on the automated testing I created. The new work is explained in my new post, Moodle performance analysis revisted (now with MariaDB).

As of this writing, the team at Moodle HQ (along with lots of volunteers from around the world) is currently hard at work on Moodle 2.6 and 2.5 has already seen it’s first maintenance release (2.5.1). At Remote-Learner we are just about to roll out Moodle 2.5.1 for our clients and we wanted to do some performance testing. Given how much more of Moodle is using the Moodle Universal Cache (MUC) we also wanted to test what kind of performance benefits using Sam Hemelryk’s moodle-cachestore_apc plugin might afford us.

In this case, performance is specifically limited to the server / hosting environment load. We were less interested in the effects of Javascript and end user browser page load speeds at this time.

Testing environment

Hardware

Moodle was being run via a LAMP stack on a mid-2010 MacBook Pro with 8GB of RAM and a 512GB Seagate Momentus XT hybrid HDD. The web browser was being run from a separate machine on the local network.

Software

Web stack (all versions were installed via MacPorts):

• Apache 2.2.25_0
• PHP 5.4.18_0 w/ APC 3.1.13_0
• Percona MySQL 5.5.32-31.0_0
• Mozilla Firefox 23.0 (with browser caching disabled – network.http.use-cache set to false)

Configuration

The Moodle site was setup using a copy of a large production database (2000 courses, 90,000+ course module instances and nearly 28,000 users) running Moodle 2.4.4. For the purposes of this test that database was upgraded to Moodle 2.4.5 and, for the second and third round of testing, upgraded to 2.5.1. DB Sessions were disabled (so that session data was being written to the filesystem) and the MUC configuration was all default settings (except when switching to the APC store for the third round of testing).

PHP APC was using default settings aside from allowing the use of 256MB of memory for the cache store.

Moodle had the MDL_PERFTOLOG constant set to true in the config.php file to that performance data was written out to the web server error log for each PHP script that was executed.

Testing methodology

The idea was to identify some common pages should help give a good indication of performance across the three setups we are testing. I identified six specific pages / actions in Moodle to use as comparison points:

1. Viewing the site index page as an unathenticated user
2. Logging into the system as a site administrator (from submitting the login form data to the site index page finishin rendering)
3. Viewing the site index page as a site administrator
4. Viewing the site index page as a student that is enrolled in 32 courses
5. Viewing a very large course page (2696 course module instances) as a site administrator
6. Viewing the first page of the Moodle gradebook in a course with a very large number of enrolled users (over 131,000 enrolled users)

Each page was loaded four times for for each site configuration. Those site configurations:

1. Moodle 2.4.5 with the default MUC configuration
2. Moodle 2.5.1 with the default MUC configuration
3. Moodle 2.5.1 with the default applicaiton store set to use apc as the plugin in the /moodledata/muc/config.php file

Before the first page load all of the Moodle caches were purged by running the Moodle CLI script /admin/cli/purge_caches.php. The three subsequent page loads were performed with the caches warmed up. The idea here was to simulate a worst-case performance scenario and then more of a real world scenario where the caches are warmed up.

NOTE: the web server was never restarted so the APC opcode caches were never purged during testing.

After each test the Apache error_log file was copied into a named file and them emptied for the next page request to be made. This allowed us to capture all of the requests that were generated by a single page load within Moodle (i.e. images, CSS, JS, etc.) and then total the performance numbers across all of the PHP scripts executed on the web server for a given page load. The numbers below reflect those totals for each configuration.

In each case there were four key metrics I was interested in:

1. Execution time
2. Memory usage (peak memory)
3. DB reads
4. DB writes

Testing results

1. Unauthenticated user site index page

2. Login process for a site administrator

3. Authenticated site administrator site/p;index page

NOTE: the numbers for this test might be slightly deceiving. The settings used for the display on the site index page when logged in produce different results in 2.4.5 and 2.5.1. In Moodle 2.4, a count of the number of courses was displayed along with a search box. In 2.5.1 a large number of the courses are listed on that page which produces much more database access. This is why the numbers for 2.5.1 are much worse than 2.4.

4. Authenticated student site index page

5. Authenticated site administrator course view

6. Authenticated site administrator gradebook view

Analysis

Aside from from a few small instances of strange numbers, in general Moodle 2.5 seems to run slightly slower and use more system resources than Moodle 2.4. One notable exception is that the gradebook actually seems to load a little faster and hit the database less in 2.5 when compared to 2.4.

Enabling the cachestore_apc plugin in Moodle /p;allows Moodle 2.5.1 to run faster and use less system resources. In most cases this improvement is near or better than 2.4.5.

Some extra notes:

• Strain on the database was not measured in these tests. In the cases where Moodle 2.5 performs fewer operations on the DB it could be a case where those operations are actually more intensive and strain the DB more than the case where fewer / simpler operations were made.
• The cache that APC uses can become highly fragmented (and thus ineffective) or it can also run out of memory if not configured properly. There are a lot of settings for this PHP extension and if you are going to employ this plugin on your Moodle site with MUC, you should pay attention to those settings, especially things like TTL and size of cache.
• If trying to dig deep into why certain pages in Moodle are running slow you should look at using the XHProf PHP profiling tool that is built into Moodle. If you are unfamiliar with this tool, fortunately Tim Hunt has written a nice guide to how the Open University has used it to track down and fix Moodle 2.4 performance problems
  • Performance-testing Moodle
• As with all performance tuning / analysis, the only way to be sure of changes is repeated testing while making small changes. Testing at load with tools like JMeter or Selenium can be useful but should probably be reserved until you have a configuration that you are fairly certain is well tuned.