Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8
-
Component/s: Unknown
-
Labels:None
-
Environment:Tested on
Mac OS 10.4: MySQL 4.1.18, Apache 1.3, PHP 4.4.4
Linux RHE4: MySQL 4.1.20, Apache 2.0 PHP 4.3.9
same issues in both setups.
-
Affected Branches:MOODLE_18_STABLE
-
Fixed Branches:MOODLE_18_STABLE, MOODLE_19_STABLE
Description
Page load times at 16-120 (although hovering around 16-20) seconds for the admin, other users seem to hover around less than 1 up to 3 seconds.
Profiling for the front page (percentages are rough)
The left column content on the frontpage tends to take 66% of the load time for the admin user. Of this 66%, 14% is spent in blocks_have_content() mostly spent on one instance of site_main_menu, the remaining 86% (of the 66%) is spent in blocks_print_group().
Call to @session_start() in setup.php takes 33% of the load time. I have seen the admin session be over 32 megs, but these are typically 18MB!!!! I think the roles system for the admin needs to be cleaned up considerably.
The testing scenario I have is 12,850 courses, 15650 users, and 144687 role_assignments. This is 4 semesters of courses, students and the corresponding enrollments.
Not seeing any slow queries via MySQL other than this one:
SELECT c.* FROM mdl_course c ORDER BY visible DESC, sortorder ASC;
Which, as far as I can tell can't be optimized via db adjustments it uses a file sort, if not all of the columns are necessary then it should be restricted to just those needed so that an in memory sort could be performed. However, I really don't understand why the calendar block would need to perform such a query. This is called via calendar/lib.php in calendar_get_default_courses(). However, I don't believe this db query is causing the majority of the performance issues we are experiencing.
Attachments
Activity
After a little testing/reworking the last line should be the following;
<pre>
// find all course this student can view
if (isset($CFG->adminseesall)) {
return get_my_courses($USER->id, 'visible DESC', 'id, visible', $CFG->adminseesall);
}
else {
return get_my_courses($USER->id, 'visible DESC', 'id, visible', false);
}
</pre>
Not sure if the sort is truly necessary, but get_my_courses() bombs out on an empty sort field. Limiting the returned fields not only reduces the query time, but also reduces the session size which is now about 1MB for the admin user now.
This above patch results in all users load times being very snappy, at least by comparison. For the admin user the initial login is about 21 seconds or so, but subsequent page loads are under 1 second. Sorry about not posting a diff... anoncvs is still blocked 
so that makes things difficult.
so that makes things difficult. For info, i'm fairly sure that calendar/lib.php is only called within admin/settings/appearance.php for the constants CALENDAR_TF_12 and CALENDAR_TF_24 (cos it was my patch which did it 
). And it doesn't require any other calendar session variables (so could be removed so that it isn't setup for every admin logging in with an admin block..)
). And it doesn't require any other calendar session variables (so could be removed so that it isn't setup for every admin logging in with an admin block..) MartinD - I did put the bug numbers in the commits that were clearly related to this. For some reason Jira didn't catch them
I will not have access to this information after Monday so please get back to me ASAP if you need more information.