Development:Performance 2.x: Difference between revisions
Line 18: | Line 18: | ||
==Navigation clenaup== | ==Navigation clenaup== | ||
The goal is fewer DB hits per page, fewer PHP includes resulting in reduced memory use. | |||
TODO... | |||
==Text caching redesign== | ==Text caching redesign== |
Revision as of 13:42, 23 April 2011
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
Static dir caching
General caching framework
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