This project has moved and is read-only. For the latest updates, please go here.

Slow in Grading pages and assignment pages (6000 learners)

Topics: Developer Forum, User Forum
Nov 11, 2008 at 5:03 PM
I find performance unbearable on the client browser when accesing Grading and Assigment change pages (takes up 5 minutes in current hardware, older computers could take up to 10 minutes) seem all the list is braought back in a single view (without paging) and because it is Jscript Enabled it takes another chunk of time in every edit (checking a learner or a learner group). Is there any way to optimize it?

How could I update the code to support such escenario? Should it be in GradingList.cs?  should it be the GradingList web control?


Nov 11, 2008 at 7:34 PM
Hi Alex,

Do you need to assign work to 6000 learners at a time? What is your current site hierarchy? If possible, it would be much better to split the learners over multiple sites so you don't have so many at once e.g. have a site per course or per department and only give the appropriate users permissions on those sites.

SalamanderSoft Limited
Active Directory & SharePoint provisioning. SharePoint web parts.
Nov 11, 2008 at 9:50 PM
It wont actually help as many domain users are learners (and when creating any assignment the complete 6000-8000 learners would appear) unless I create separate sites without copying parent site permissions. It would complicate management (how many sites, how to obtain reports, where does that user belongs?).

What changes in design or code should be necessary (if possible) to allow such an scenario? I was thinking not managing the data in postback for all records, but being able to define or configure paging? or maybe server side processing instead of client side (some older pcs at a customer will go to 100% CPU for 10 to 15 minutes just to show the grading).

Nov 26, 2008 at 11:39 AM
Edited Nov 26, 2008 at 11:40 AM
In my personal opinion you should not be assigning 6000 learners to a site. SLK is designed to show all learners assigned to a site, so with that many learners, even with optimization, it's going to be slow. Even if displaying all the users was lightning fast, from a user's point of view it's unusable. Hunting through 6000 learners for the ones you want to assign to is a pain, and would actually be worse and more time consuming if it was paged.

I think that you need more targeted sites for assigning work. Obviously I have no idea of your organisation or your SharePoint set up, but here are a few ideas.

  • In a school, have a site per class/teaching group with the appropriate pupils as learners.
  • In a company, have a site per deparment with the departmental members as learners.
  • If you regularly give set courses, have a site per course with the SLK Learner role assigned as appropriate
  • Have a site per instructor, which they have control over. They can then give permissions to the appropriate learners.
You will probably find if you create extra sites, they will expand to become collaboration sites as well as just sites for assigning work.
Don't forget, you don't have to create specific sites just to assign work. You can re-use your existing hierarchy by assigning SLK Learner and Instructor permissions on the existing sites.

Of course sometimes there are situations when you might need to assign work to a large number of users. In that case it might be useful to have an option to assign to a group without displaying the members. It would still be slow on assigning as it gets assigned to each user.

Active Directory & SharePoint provisioning
SharePoint web parts
Jan 19, 2009 at 8:30 PM
How do I find out about any changes in this area?

I've just started investigating SLK and have just spotted the list of learners when assigning tasks. Groups within, for example, the English site include about 1000 learners in total. I don't fancy a list of 1000. For my school, I would hope to set up sites for each department and if pushed for each year within a department. However, the maintenance involved in having a site for each class (that's 600 - 700 sites) seems way over the top. The classes would also change each year; do we tear down and recreate the school's classes each year?

It would be much easier if we just had the option to hide the learners.

Jan 19, 2009 at 8:39 PM
It is truly painful to adapt any customer or school to the site model, some training have to be consolidated for regulatory reasons, also reports, consolidation, management. (Imagine the training is updated and you have to cancel and assign an updated version of the training, doing it all over again 10 times...)

The solution is simple, give the option to the users to page the results or avoid using postback, let users choose how many students per page are shown, or a simple button to export results to csv or xlsx.

Please do plan to implement such a feature, I love SLK but having any amount of students over 1000 makes it really slow.


Feb 12, 2014 at 11:03 AM
We have a problem with loading list of learners when instructors want to assignment the course.
There are more then 5500 users in this group. Error timeout.
Is any another one solution besides this "If possible, it would be much better to split the learners over multiple sites so you don't have so many at once e.g. have a site per course or per department and only give the appropriate users permissions on those sites" ?
And will new SLK 1.7 Beta solve problems?
Feb 12, 2014 at 4:33 PM
Currently SLK isn't currently designed to handle that many learners, so it's a known limitation. The assignment properties page would need re-writing to handle large numbers of learners.

There is an open work item for this