Slow courseware get operation
Example trace: https://rpm.newrelic.com/accounts/88178/applications/3343327/transactions?tw%5Bend%5D=1501001893&tw%5Bstart%5D=1500998293#id=5b225765625472616e73616374696f6e2f46756e6374696f6e2f636f75727365776172652e76696577732e696e6465783a436f7572736577617265496e6465782e676574222c22225d&app_trace_id=b6fb8d88-7159-11e7-8968-0242ac11000f_89230_132432
This happened, and is way slower than it should be. Memory usage was spiking at the time, maybe that's related?
figure out why this view was so slow
prevent it from happening again
Looping back on this. As and I discussed on Thursday, we expect the number of UserPartitionTransformer objects to be on the O(number of blocks in the course).
We enabled the EnrollmentTrackUserPartition in production on June 9th. https://github.com/edx/edx-platform/pull/15037. At that time, all courses with more than one CourseMode (which means this wouldn't impact courses on Edge) would have the dynamic EnrollmentTrackUserParititon created. I don't think any changes we made since then would have caused this to be hit more often.
State of things this morning: LMS is still seeing production issues, memory usage is partially suspected and is the lead I'm following on this ticket. The best lead we have right now, given the dumps I've looked into, is that the UserPartitionTransformer is being collect()-ed more than it needs to be (see gist links above).
's team has been working with UserPartitions semi-recently, and resident BlockStructure expert may be able to help as well - do you two have any theories why this transformer is so active? Anything we can do to make it be less active?