This ‘Speed up Moodle’ series of 4 posts will teach you step-by-step how to optimise your Linux server for Moodle. It is aimed at beginner server administrators. If you find any mistakes or inconsistencies, please comment and I’ll rectify ASAP. This fourth post is about enabling APC, an opcode cache on your server, probably the easiest and most efficient step to increase server performance.
Tag: Moodle slow
This post is part of ‘Speed up Moodle’, a 4 post series showing ways to optimize a Moodle server. Moodle is a database driven application, and the faster the database, the faster your Moodle installation will be. In the second post, I show you a simple way to increase your Moodle database performance, focusing on MySQL. Do keep in mind that fine tuning a database is a vast topic, and entire books have been dedicated to it. In this post, I only focus on the part that will likely show the most improvement.
This ‘Speed up Moodle’ series of 4 posts will teach you step-by-step how to optimise your Linux server for Moodle. It is aimed at beginner server administrators. If you find any mistakes or inconsistencies, please comment and I’ll rectify ASAP. This first post is about optimising Apache for Moodle. Check out the other posts on optimising MySQL, installation of an opcode cache such as APC and other ways to optimise your Moodle server. Please see ‘Assumptions’ and ‘Technical notes’ at the bottom of this post.
[pulledquote]Last month I wrote a blog post comparing different versions of Moodle and the demands they each place on hardware. With Moodle 2.4 release just around the corner, I thought I would perform the same series of tests – here are the results.[/pulledquote]
Warning: these tests are not scientific by any standards but I am comparing apples with apples, please read my previous blog post to check my methodology – I did not change anything on my server/Moodle site since my last round of tests. All figures shown below are averages.
Warning 2: Moodle 2.4 is still in its beta stage, I will run the same test once the official Moodle 2.4 stable has been released.
RAM to generate a page -8.9%
On average, I found that Moodle 2.4 uses 8.9% less RAM to generate pages than Moodle 2.3. This is great news considering that, for a large amount of Moodle servers, is the first thing that needs upgraded when usage increases. Moodle is very ‘RAM hungry’.
Time to generate a page -9.1%
On average Moodle 2.4 is 9.1% faster at generating pages than Moodle 2.3. Might not matter much if you only have a few users, but it starts adding up if you have hundreds/thousands of simultaneous users. The less time your CPU/disk spend generating a page, the faster they can move on to their next task.
Number of files to generate a page -9.1%
On average, it takes 25 fewer files to generate a Moodle 2.4 page compared with Moodle 2.3. This equates to a 9.1% improvement over Moodle 2.3. Each file needs to be collected from the disk before it can be processed by the CPU to generate a page, so the less files to be collected, the better.
Average database reads -36.6%
This is the big winner and I believe is directly linked to the introduction of the Moodle Universal Cache (MUC from then on) in Moodle 2.4. On average, Moodle 2.4 makes almost 37% fewer calls to the database to generate Moodle pages compared with Moodle 2.3 (39 calls vs. 57). This is huge considering MySQL (if that’s what you use as your database) is often the bottleneck in large-ish Moodle servers. This will have a massive impact when you have a lot of simultaneous users on your Moodle site, less database calls = more simultaneous users who can use Moodle on your current hardware. This is quite impressive considering it is only the first iteration of the MUC.
Average CPU load -6.5%
Warning: this is to be taken with a grain of salt, see my previous blog post for reasons why.
On average, Moodle 2.4 uses 6.5% less CPU than Moodle 2.3. From experience, CPU is rarely the first thing that needs upgrading on a Moodle server but it’s nice to see an improvement in this area.
We’re still a far cry from the lean-mean Moodle 1.9 but it is great to see that Moodle HQ have managed to keep adding features whilst reducing Moodle’s footprint on hardware. One cannot compare Moodle 2.x with Moodle 1.9.x – there have been too many features added, improvements made for it to be a fair comparison. Moodle relies heavily on calls to the database so the less calls, the better. With a 37% improvement, this alone should prompt you to update to Moodle 2.4 when it comes out.
It is important to note that my server already uses caching techniques that the new Moodle Universal Cache cannot yet leverage (e.g. APC). I fully expect MUC to mature and reduce Moodle’s footprint even further. This is a step in the right direction. Gains brought by the MUC will be more obvious when multiple users are logged on, I will try and test it out soon.
I have another round of tests coming up where we’ll be able to see the difference on a server that does not yet have APC enabled. Stay tuned.
Have you run any Moodle performance tests lately? If you have, please don’t be shy and share in the comments section below.