Development:Performance 2.x

This page lists potential performance improvements that could be implemented in Moodle 2.1 or later. In general we must lower the number of queries on each page, we have to decrease the memory use and we should load less javascript code. There is not much point in benchmarking of current code because the causes of slowness are already known.

PAGE level caching and improvements

The goal is to centralise all current page caching and simplify page setup steps.

There would be several new methods such as:

• $PAGE->init_course($course_or_id)
• $PAGE->init_activity_by_cmid($modulename, $cmid)
• $PAGE->init_activity_by_id($module, $id)
• $PAGE->require_login()
• $PAGE->is_enrolled($active)
• $PAGE->get_current_group()
• $PAGE->get_current_groupmode()

The benefit could be tens of DB operations per page and simplified API resulting in improved security. The backwards compatibility should not be a problem. Please note that $PAGE must not be abused in low level API and cron.

The only potential problem is the sloppy use of $PAGE in cron scripts, it has to be completely eliminated. We could create a fake page class that prints debug info when PAGE accessed from cron script, or it might return only some basic information.

Estimate: relatively easy, few BC problems, 1 week, pre-requirement for navigation cleanup

Navigation clenaup

The goal is fewer DB hits per page, fewer PHP includes resulting in reduced memory use.

We would used PAGE level caching instead of current navigation caches and DB access. The unnecessary includes are usually caused by incorrect coding style in plugins.

Admin user performance could be significantly improved if the admin tree was loaded via ajax because the admin tree is usually necessary only when admin is already in the admin section or on the frontpage. The admin tree was never intended to be constructed on each page in the first place.

The expected benefit is fewer page includes (less memory used) and fewer DB hits on each page.

Estimate: relatively easy, no BC problems, 1 week

Text caching redesign

Current text caching is not very efficient and may actually crate a bottleneck at the database level.

TODO...

Javascript performance

Our biggest problems are YUI2 and order of JS initialisation steps.

TODO...

Static dir caching

At present we are relying on browser level caching for all theme CSS and images, user images and javascript code. This works fine without any server configuration and it is very reliable during Moodle upgrades. If for some reason the browser caching does not work (mobil client, https, incorrect testing setup) the server may get overloaded because the serving of files via PHP is a more expensive than standard Apache file serving.

TODO...

General caching framework

Please note this general caching framework is not a silver bullet, we will need to spend a lot of time on each individual improvement that is going to use it.

TOD...

Smaller sessions

Large sessions cause performance problems, we have to find ways to minimise our session data.

TODO...

Load balancing support

Moodle is not optimised to be compatible with advanced load balancing set-ups.

TODO...

New logging framework

Current logging is insufficient and may be major bottleneck at the database level.

TODO...

Other topics

• Mobile device caching and performance
• statistics aggregation
• moodle_string class from Sam
• HTMLPurifier shortcuts

TODO: add links to MDLs

Compare performance of different databases

Some database might be significantly faster, it would be nice to know what database is best for each different server load type.

TODO...

General prerequisites

Core developers are not skilled at server configuration or production server optimisations. Large parts of Moodle 2.0 were developed on ageing computers using slow ADSL connections without any real test data. Some refactoring and API changes necessary for future performance improvements were already carried out, but in general the performance did not have high priority during the 2.0dev cycle.

Developers need:

• access to data sets similar to existing large production sites.
• to know how are production servers configured (load balancing, db configurations, apache configurations, reverse proxing, etc.)
• access to large hardware that can simulate complex server loads and both slow & fast client connection.
• access to all supported browsers, operating systems and especially mobile devices.
• to study available profiling tools and ways how to simulate real life workloads.

Current build-in tools:

• basic performance counters in page footers - we need more information and some external logging
• data generator script - unmaintained, we need to improve it significantly
• xhprof integration