Measuring the speed of Moodle

Measuring the speed of Moodle

by Derek Chirnside -
Number of replies: 9

Whats your advice for a simple speed test for Moodle?  I have no server access, although if necesary I could get the hoster to install a small gizmo.

I'm not even exactly sure what feature I want to measure, just to compare Decaf theme (Probably page load times?) with and without the Nav menu and the Settings menu switched on.  ie using the Awesome bar but not the other regular menus.

-Derek

Average of ratings: -
In reply to Derek Chirnside

Re: Measuring the speed of Moodle

by Gordon Bateson -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Derek,

have you tried enabling Site administration -> Development -> Debugging -> Performance info ?

regards
Gordon

In reply to Derek Chirnside

Re: Measuring the speed of Moodle

by Leonard Houx -

Hi Derek

Google Analytics will track page load speeds for your site generally and for specific pages. It's a great resource and you can install it with just admin access. Xiaoying's blog post nicely explains how to set up an account and where to paste the code.

In reply to Derek Chirnside

Re: Measuring the speed of Moodle

by Frankie Kam -
Picture of Plugin developers

Hi Derek

For speed measurement of Moodle servers, may I recommend Frederic Nevers...erm, I mean, Nevers' work. You can read about it from:

Comparing speed gains by using Moodle 2.4 instead of Moodle 2.3 - very interesting
 
Monitoring Moodle load
 
Moodle 1.9 speed (zoom!) compared to Moodle 2.3 (splutter)


Glad to chip in any which way for a few extra gains in speed.
Frankie Kam

Average of ratings: Useful (1)
In reply to Frankie Kam

Re: Measuring the speed of Moodle

by Frankie Kam -
Picture of Plugin developers

One more for good measure from the prolific Frederic Nevers:
http://www.iteachwithmoodle.com/2012/12/05/make-your-moodle-courses-faster-without-fiddling-with-the-server/

He's on a roll.
Frankie Kam

In reply to Frankie Kam

Re: Measuring the speed of Moodle

by Sam Mudle -

From the article:

Q: If I add a lot of images on my course pages, will it affect performance?

A: Yes, it will. The number of reads/writes to the database skyrockets when you add images in labels. A page with 100 images requires over 3 times the amount of calls to the database compared with a page with no images in labels. Looking at iMacros loading pages during the tests, I also noticed that images inserted as URL’s (i.e. not uploaded to Moodle) show up much faster in Moodle pages than the images uploaded to Moodle.

That's really interesting.  Seems that 2.x moodle's approach to dumping images into the database as blobs is really hard on servers compared to 1.9.x's simply storing them in the moodledata directory.

Again the big problem i think for most people is how much CPU/SQL is used per call.  It limits how many students can put in requests AT THE EXACT same time.  Moodle can handle a million students as long as they don't all push a button or login within 2 seconds of each other.

I really wish that Moodle had a queueing architecture where requests could be queued rather than requsting everything processing

In reply to Sam Mudle

Re: Measuring the speed of Moodle

by Rex Lorenzo -

Where are you seeing that Moodle stores binary data (e.g. images) as blobs? I haven't seen that in practice.

What is the possible bottleneck is that every image on Moodle is served by the /pluginfile.php. It does a lot of processing to find out what part of Moodle is serving the file, calls that part's lib.php's "*_pluginfile" function to do access control.

This happens for every module icons and editing icons as well. A nice performance optimization might be to use CSS sprites (http://friendlybit.com/css/spriteme-combine-images-and-get-fewer-http-requests/) to reduce HTTP calls. However, I believe that Moodle tries to set the appropiate cache headers so that a browser should only really request an icon once during a session.

Average of ratings: Useful (1)
In reply to Sam Mudle

Re: Measuring the speed of Moodle

by Andrew Lyons -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Rex is correct - Moodle does not store any binary data in the database, what it does do though is to hash (SHA1) the content of the file. The file is then stored in an appropriate location on disk (in moodledata) based on this hash.

This is actually pretty good for performance as it theoretically reduces the number of files per directory as data is sharded over the entire filesystem - many file systems can get pretty slow to complete a stat of a directory when large numbers of files are in that directory.

I don't believe that there are that many more SQL queries for an image in a label. There will be more of course than for a label without any image, but that was also the case in Moodle 1.9. Every file fetched from Moodle has permissions checked as appropriate. This will include a range of checks from requiring login, to checking whether the section that the file is in is actually visible, and whether that user has access to it.

As Rex suggests, pluginfile.php tries to include as many cacheable headers as possible but many requests to display a file in Moodle does still necessite the permissions checks even if the actual file content is not delivered every time.

One thing which we've found massively helps our performance is to use X-Accel-Redirect to inform the web server of the file's location and get the webserver to serve the actual content (web servers are really good at this). For us this improved performance noticably. I did post in the Hardware and Perfomance forum recently about this.

Best wishes,

Andrew

In reply to Derek Chirnside

Re: Measuring the speed of Moodle

by David Scotson -
I would suggest that there is no simple speed test for Moodle, or any other web application.

The subject is so complex that almost everything you read is voodoo and superstition.

To give just one example of the complexity, for years people obsessed about the speed of their servers and databases etc. in generating the HTML document, then Steve Souders measured it and showed that for most sites that accounted for only 20% of the time that the actual user spends waiting.

http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_performanc/

Which is a great, a better understanding of how things work is always good, but now you don't have to just understand Linux and MySQL and PHP, you also have to understand HTTP and Proxy behaviour and Browser Caching and the different javascript behaviour of different versions of IE to understand whether a change is actually an improvement or not. Oh, and have a better grasp of statistics than 90% of software developers, scientists and doctors have been shown to have. (There's a rant by an internet-famous ranty software guy, with lots of rude words in it, with the title of "Programmers Need To Learn Statistics Or I Will Kill Them All", which you can google for if you're interested)

So, if you follow the standard performance advice in setting up your server (i.e. use a PHP Cache, use gzip) and Moodle (i.e. don't leave theme designer mode on) and measure your server to ensure you're not hitting any bottlenecks then from that point on I'd just use whatever features appeal to you. It's a massive task to prove (in all but extreme cases) that one Moodle setting is better or worse than another to a noticeable degree, so I'd spend my time elsewhere.