Moodle

I suppose the problem lies in recalculation of hidden grades, this can not be improved much without db changes.

I will have to profile it a bit first to find other possible bottlenecks.

This patch saves a dbq per user in the gradebook grader report.

In this instance we are importing all the grades from our other eAssessment system. As such the close date has passed and there are no hidden grades.

(with user images turned on)

Any improvement relating to images while worthwhile in itself, will not solve this problem.

Our problem is the difference between having show averages on and off on this course with about 8 columns of data that was originally imported using XML import, and with about 320 students. It works fine when averages are hidden, and grinds to a halt (over 60 seconds per page load) when they are visible.

I think Petr's suggested approach of doing some profiling the find the bottlenecks is the right one.

Sorry, wasn't suggesting that was the fix, just noticed that causing lots of db traffic

I have committed improved sql queries for the average calculation on grader report, I hope it will be faster now.
Please reopen in case of any problems or if it does not fix this problem.

I recommend adding patch from MDL-11920 too.

thanks for the report

Reopening.

At a minimum, this is producing warnings at grade\report\grader\lib.php on line 956 as well as other notices.

Will study the changes and CVS and make recommendations.

Would suggest that code be checked with debug notices set to high for 1.9 stable as some of us are now using 1.9 in production environments

Petr, what do you mean "I hope it will be faster now"?

I just measured running the old and new queries against our live database.

Old query: 23s per column.
New query 0.5s for all columns at one.

That is stunningly faster!

I should add, it was only changing the second query that made a difference. There was no change in the first one, but it was fast anyway.

I think the warning is the one I spotted in MDL-13147

I will look at the warnings today, thanks

I have to go off and teach some classes now, but a couple notes on the warnings/notices:

• Some of these warnings may be related to MDL-13059 and not these changes. On a fresh install, only the notice at 956 is evident. It was only this change that caused me to look for these at debug issues.

• Calculations for my classes and a couple others at my school with and without this change seem to be the same. Errors do not happen in these classes. Speed is faster. That is good news on the change.

• The notice is evident in a freshly created Moodle site and course with a single user and single assignment with no changes to gradebook config.

Gary: Is the user assigned at course level? Does the user show up in the gradebook?

Dan:

Yes to both. They are a user at the course level and they are in the gradebook. Attached is a screen shot of the notice. This is from a new course from a single assignment on a newly created test site with the latest CVS.

The previous lib.php file in the CVS does not produce the notice but does give the same computation.

--Gary

This is now on our live servers, and now the page load times are essentially independent of whether averages are being shown. Unfortunately, it is still taking about 20 seconds to show the page.

did you backport the user picture patch from that linked bug too?

Tim:

At Seattle Academy, while none of our classes will ever get very large in terms of the number of students, we do have many more activities in a course (as a high school, tasks are often broken down to daily tasks).

Our Chemistry course is our largest with 83 students (in 5 sections), but with 45 activities already (so more than 3500 graded items). All summaries are turned on including column totals, and categories that are weighted and course and category totals are on. Grader report for with everything displayed is less than 3 seconds.

While it might be possible that number of students is more important than the product of students and graded items (which I doubt), we are not running into any speed issues with the grade book.

Grader report times don't seem to be as directly related to just graded items as I suggested above. For fun I put 4 graded assignments in our library course (just under 1000 students), and load time was close to 10 seconds.

So, while it does not affect our school, tuning and profiling for large numbers of students does seem to be important.

I have just committed improved sql for course/group averages;

the limiting factor now is the number of form elements (== performance of browsers) - unfortunately this can not be fixed easily, we could either:

• enable grading in individual columns
• use ajax

workaround for now is to limit the number of students per page, going to file a new issue for future improvements, I do not expect any major changes in 1.9.0

thanks for the report and testing

Just to note that things at the OU seem to have improved.

We've just loaded a course with 1250 students and the Gradebook displayed to Course Team staff (i.e. staff who can see all students) in ~14 secs.

I asked why things might have been improved and was told that it could be associated with some database maintenance work that was carried out.

Whatever it was, this note is to record that we now have a Gradebook that is working at an acceptable speed even when we have course populations > 1,000.

Thanks for info Phil,
expect more improvements in later 1,9.x - we need to implement that ajax version sooner or later.

Petr