Some operations now based on roles are core functions in Moodle. For Moodle to scale, these need to be fast and efficient even in the face of large datasets – that means as close to O as possible.
Right now we are probably O(log(log(N)) which is pretty bad.
The core operations we care about are
- What are my courses? – mostly implemented in get_my_courses()
- Who are the participants in this course?
- Who can do X in this course?
So – general interest operations that will be called often and sitewide or coursewide should be fast (O) for the simple "moodlish" cases. If there are overrides, then the costs go up (but probably tied to locality of access controls). So more "special" settings, higher processing, DB and memory usage - but the default stuff should be cheap and simple.
Right now roles is designed for and optimised for any combination of contexts, roles and capabilities, instead of targetting the common "moodlish" usage patterns that constitute 99% of our users.
- MartinD says that
- 1.8 has a new cache table that may help - consider backport to 1.7
- 1.8 has a SYSTEM from SITE(COURSE?) context split that may help. consider backport
- MartinL has a site with 70 courses, and when logged in as admin or course creator, the homepage takes 3K queries (down from 8K with the fix for MDL-8385 )
- CFG->disableslowrolesfeatures which can disable
- enrolment to categories
- very granular overrides checking - sitewide functions
- MartinL thinks that if we can change the API to be optimised for the no-overrides case, and having the right hooks for checking for small-context-specific overrides only when we have locality
- MartinL thinks that a completely rewritten get_my_courses that pushes a lot of work to SQL would work faster