I love, love talking performance (thank you for tagging me on this @pdpinch!), and I will come back here later this week when I have more time to look at some profiler output. A few high level things I’ll say in case it’s useful:
- The courseware does much of the work of rendering the entire sequence because there was metadata that needed to be grabbed w.r.t. the contents of each unit, and at the time, it was doing 90% of the work of rendering everything when showing a single unit anyway. The balance of this has shifted, both because we put less metadata in the sequence header row now, and because certain XBlocks are slower to execute.
- As pointed out in this thread, CodeJail is a known source of performance problems.
- CCX and particularly the intersection of CCX + inline discussions is another known source of courseware performance problems (the way inline discussions XBlock makes calls to the root course object breaks Modulestore-level caching).
- You’ll generally want to disable django-debug-toolbar when profiling, because it adds a significant amount of ORM-introspection overhead, which can distort your results.
- Even though it’s not visible, something like 10-20% of the load time of CoursewareIndex.get is spent on building up the table of contents that used to be visible in the left hand navigation, but is now only used to put in values for “previous” and “next” buttons when they need to go to the previous or next sequence.
- I’ve personally shifted to the view that the best long term thing we can do about XBlock runtime performance is to take the navigational responsibilities away from XBlock entirely in the LMS, and to only invoke the XBlock runtime one unit at a time–i.e. stuff it into the smallest box possible. This is what’s being done with the new Courseware MFE, and is part of the thinking behind the Arch Decision Record for the Role of XBlocks.
- Thank you, thank you, thank you for including precise course content for reproduction.
