Moodle

I would like to see the ability to filter the results not only by group, but also by first and lastname by using the alphabet across the top similar to how we have done when looking at quiz results, assignment submissions, and even a long list of participants. Of course, the easiest way to speed up the page is to not try to put so many students on it in the first place. This is where I think the alphabet listing might be helpful with managing large classes. A teacher could look at all the students with a lastname beginning with C, etc. To be honest, considering the amount of calculations being performed I would expect the page to be slow. Peace - Anthony

Including 64 files is pretty normal for any moodle page.
200 DB queries is pretty good for such a complex page
9 seconds is also quite good for a page with so much information

I don't think a call for optimisation is called for here, especially considering the fact that a lot of optimisation has already been done on this report.

Besides, there are ways to greatly speed up the display of the grader report, for example by hiding the user pics. For example, with my test data of 15 grade items and 1000 students on 1 page, it took 400s to load the page with user pics, but only 23s to load it without the user pics...

But if you have a strategy in mind for optimising, please share it! In the meantime I will close this issue.

Nicolas - What are you thoughts on adding the ability to sort by name (last and first)? I think this is a real issue that some of our users will face. For example, http://moodle.org/mod/forum/discuss.php?d=87688#p387797 has a memory error with 2100 students (granted this is in 1.8 but I would suspect the same in 1.9). In terms of UI, I think having the alphabet strip would be helpful for teachers. Paging is a good first step to prevent a huge page from loading (i.e. one with 2100 students). The ability to further narrow that down further based on student names or even username would be an added plus; however, I think this should be a separate feature request and agree on closing this issue. Peace -Anthony

We have several courses with over 500 students and 10+ grade items.

When entering the gradebook for any of his courses, the entire Moodle instance grinds to a halt and the MYSQL server pegs at 100% CPU usage.

Any ideas?

I'm assuming this is "first time load is very slow because of all the initial calculations" issue ....

Petr, can you update us with the current status on those initial calculations and if they are unavoidable then can we put in a message so the user knows what is happening at least?

oki, I will need to profile the whole gradebook first

Do you have images turned on? That could slow things down.

Anthony I assume you are talking about filtering by name, not sorting: sorting by first and last name is already implemented.

User picture patch in cvs, I hope it solves this issue, please reopen if it is not significantly better for you.
thanks for the report and cooperation

Nicolas - Yes, I may have been confused when I wrote the earlier comment but filtering by name may help to reduce things. The major task of being able to select the number of students to see per page has already been implemented in 1.9 which I would think would be the most significant resolution of this issue. A bit je-tlagged - Anthony

the slowness should be partially fixed now - sql rewritten + user picture loading fixed, the remaining problems is the excessive amount of form elements causing performance problems in the browsers, this can not be fixed easily unfortunately, we will have to use ajax to work around it

see the linked bugs for details, thanks for the report

i'm not sure where this query comes from yet but it can be improved:

SELECT DISTINCT go.userid
FROM mdl_19_grade_grades go
JOIN mdl_19_grade_items gi ON gi.id = go.itemid
LEFT OUTER JOIN mdl_19_grade_grades g
ON ( g.userid = go.userid AND g.itemid =1799 )
WHERE gi.id <>1799 AND g.id IS NULL ;

Five seconds for one user id item is way too expensive! If we can optimize this query then I think we would see lots of improvement.

The above query has an unnecessary table join to grade_items gi. I run and equivilent query removing the unnecessary grade_items join and replaced the gi.id <> 1799 with go.itemid <> 1799. The equivilent query is consistently 0.34 second instead of 5 sectonds. If we can replace this in the code as a patch I think will help.

SELECT DISTINCT go.userid
FROM mdl_19_grade_grades go
LEFT OUTER JOIN mdl_19_grade_grades g
ON ( g.userid = go.userid AND g.itemid =1799 )
WHERE go.itemid <>1799 AND g.id IS NULL;

My tests show significant improvements with this last SQL change. Closing.