Performance testing for framework cost only

Performance testing for framework cost only

by David Ackerman -
Number of replies: 3

I'm very new to Moodle and trying to get some good performance metrics on a Moodle installation. Ideally, I'd like to run some of those performance tests on a page that has little to no database querying going on so I can get an idea of how much the database is adding to any bottlenecks at various concurrencies.

Normally, I'd assume that the login page would be a good candidate, but there seemed to actually be quite a few (20-30 if memory serves me) queries running on just that.

A drastic measure would be to implement a dummy DB service that fakes the connection and returns results instantly for the purposes of the test, but if there are simpler options (like just finding a page with very few queries), I'd like to try those first.

Average of ratings: -
In reply to David Ackerman

Re: Performance testing for framework cost only

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Such a thing does not exist.

For example, a hello-world type Moodle (2.1) script (http://example.com/moodle/hello.php) looks like

require_once('config.php');
$PAGE->set_url(new moodle_url('/hello.php'));
require_login();
$PAGE->set_context(get_context_instance(CONTEXT_SYSTEM));
echo $OUTPUT->header();
echo $OUTPUT->box('Hello moodler!');
echo $OUTPUT->footer();

Ouch! that seems to be 42 DB queries. We really need to do something about that.

If you have not already found them, there are options on admin -> development -> debugging to display performance info in the footer of every page.

Average of ratings: -
In reply to Tim Hunt

Re: Performance testing for framework cost only

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

OK, I dig into this a bit, and acutally 42 DB queries is only if you are logged in as admin, because certain bits of building the admin navigation are horribly inefficient. (Hint to developers: admin_setting_configselect supports lazy-loading of the choices. Use it!)

Second mitigating fact, the Moodle 2.x DB layer needs to do SHOW COLUMNS FROM {tablename} a lot, which gets counted as a DB query. 10, out of the 42 queries were that.

Logged in as guest, there are only 23 queries, of which 6 are getting the column metadata, which leaves only 17 real queries. Looking at them all, the are mostly justified.

So, the biggest win would be to introduce persistent caching of the SHOW COLUMNS FROM {tablename} results, which will only ever change on install or upgrade, and I did a proof of concept here: 

https://github.com/timhunt/moodle/compare/master...cache

With that, and logged in a guest, I get 17 queries on my test script, which is more what I would expect following the performance optimisation done in 2.x.

(By the way, the automatic DB query counting that you can turn on in admin -> development -> debugging misses two DB queries: writing the updated session to the DB and releasing the lock.)

Average of ratings: -