Hello All,
Since upgrading to v 1.8.1 we have performance issues when viewing studnent details. This occurs where students are enrolled on a lot of courses (15 courses for example).
Moodle takes over a minute to display these records. By Comparison a student only enrolled on one or two courses will display almost instantaneously.
I was wondering if anyone else has observed this and whether anyone has looked at re-factoring the code used here?
Regards, Jeremy
There is a big code refactor I am finishing that will appear somewhere in the 1.9.x or 2.0 timeframe. It's taken well over a month of work on the branch (after about 3 of experimentation), and it's been incredibly complex, but I think it's sorted, and it's in the pipeline 
Hi Martin,
Thanks for your reply.
Do you know whether this could be applied as a patch to v 1.8.1?
I ask as it is very difficult to upgrade our system due to the number of instances we have and lack of available down time.
Thanks, Jeremy
Thanks for your reply.
Do you know whether this could be applied as a patch to v 1.8.1?
I ask as it is very difficult to upgrade our system due to the number of instances we have and lack of available down time.
Thanks, Jeremy
I've noticed some performance improvements in this area on 1.8.2+ over 1.8.1. So, if a minor upgrade is an option for you, try going for the latest 1.8.2+. The delay is still there, but less so. Also, I've seen the performance double according to the database settings, but haven't had the chance to figure out what is wrong with the slower box (or right with the faster)...
Hi Samuli,
Can you tell me what database settings you were adjusting?
I played with database caching / number of cached threads etc. but these settings made no difference.
From what Martin says about code re-factoring I am not sure there is much that can be done regarding DB optimisation.
The issue is specific to users enrolled on a lot of courses, generally performance is not an issue.
Jeremy
Can you tell me what database settings you were adjusting?
I played with database caching / number of cached threads etc. but these settings made no difference.
From what Martin says about code re-factoring I am not sure there is much that can be done regarding DB optimisation.
The issue is specific to users enrolled on a lot of courses, generally performance is not an issue.
Jeremy
Jez, with or without the patches, database tuning is probably the most important factor for Moodle performance. I'm all for it
Unfortunately I can't help you there: I didn't adjust any settings, just observed that one box was running twice as fast as another, looking at a profile of a user with 35 courses. The slower box took 20 seconds, the faster took 10. Didn't have the time to figure out what setting was responsible for the difference 
It could just be that the MySQL 5.0 versions differed and one was faster than the other. Both had similar PHP setups and query cache on. Maybe some JOIN limits, or not. Just guessing at this point
It could just be that the MySQL 5.0 versions differed and one was faster than the other. Both had similar PHP setups and query cache on. Maybe some JOIN limits, or not. Just guessing at this point
Hi Jez, this bug and fix may help, we found that the function update_course_icon() has a big problem when viewing the site as a student.
http://tracker.moodle.org/browse/MDL-10635
http://tracker.moodle.org/browse/MDL-10635
Yep, Petr and I found it almost simultaneously. But that bugfix makes a difference to the course page only.
The problem Jez refers to is deep in the heart of accesslib.
The problem Jez refers to is deep in the heart of accesslib.