Performance 2.x
| Performance 2.x | |
|---|---|
| Project state | Planning |
| Tracker issue | MDL-23754 |
| Discussion | N/A |
| Assignee | unassigned |
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.
TODO...
The goal is fewer DB hits per page, fewer PHP includes resulting in reduced memory use.
TODO...
Text caching redesign
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
More load balancing support
New logging framework
Other topics
- Mobile device caching and performance
- statistics aggregation
- moodle_string class from Sam
- HTMLPurifier shortcuts
TODO: add links to MDLs
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
