Affects Version/s: 1.8
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.
Fixed Branches:MOODLE_18_STABLE, MOODLE_19_STABLE
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.