Enable large course enrolment

[moziliar]

Description of feature/enhancement

Allow course instructor to create course with > 100 students.

Justification

Currently, TEAMMATES course creation only accepts 100 students per enrolment. This causes inconvenience to course instructor with > 100 students as it will require subsequent enrolments. Inconsistency in student data might even be introduced.

Considerations

Direction

• The current bottleneck is updateStudentCascade, which is run at per-student granularity.
• Due to the above, the two possible directions would be
  • Batch DB save
  • Improve the cascading update logic efficiency

Correctness

• In this change, we want to at least maintain the correctness level of the enrollment action workflow; that is, we improve the enrollment performance without compromising the correctness
  • If an erroneous state could occur, it still could; otherwise, it should not happen after the change, e.g. a student updated from team A to team B still has dangling responses in the old team
  • From the current look of the cascading logic, there's no such protection on referential integrity as the backend code maintaining it could fail, whereby a student could enter an intermediate state where some of his/her related entities are updated but not the rest; no rollback logic is present
• Batching DB calls per cascade level would likely retain such level of correctness, as what can happen before batching could still happen; need to investigate whether the likelihood is higher
• Need to investigate whether there are other invalid state batching DB call could incur

Update Aggregation

Dependency

• The student update seem to have interdependency in the following update options:
  1. Student email in response (as they can clash with other students)
  2. Section update (involving moving existing responses across sections)
  3. Team update (remove all responses as they are team-based)
• From the validateSectionsAndTeams check, we have the following guarantees should it pass:
  • Section overflow would not happen
  • Students from the same team will not end up in different section
• If we migrate the team check to the validation logic (which should be fast in view of the heavy IO-bound operations), we can reduce the dependency level between students with respect to team validity
• For student email change in responses, a case that has tight dependency would be that two students are swapping emails; however, this rarely occur (swapping email after the students have submitted at least one response using the email)
• Despite the dependency, it seems that should an update of a student fails at certain stage of the cascading logic, what has been changed about the students remain. This means that batching update to DB by cascade layer (e.g. update all the students in batch, then update all the responses from these students in batch and so on) would not lower the level of correctness.

Cost

• If we try to parallelize CPU-bound workload, it will cause resource (CPU, memory) surge and very likely new instance creation, leading to more instance hours and more cost.
• IO bound operations can be parallelized, e.g. blocking deletion (response deletion) with .now() as Datastore usage is not charged by its internal resource used, but # of entity R/W.
• Therefore, if we ever want to parallelize anything, we should aim at storage layer unless we can afford the extra cost.

Workflow Analysis

In updateStudentCascade:

1. getOriginalStudent
2. updateStudent with UpdateOptions
3. updateFeedbackResponsesForChangingEmail
   1. getFeedbackResponsesFromGiverForCourse
   2. for updateFeedbackResponseCascade
      1. getFeedbackResponse
      2. updateFeedbackResponse
      3. for updateFeedbackResponseComment
   3. updateFeedbackResponseCommentsEmails
   4. Repeat for getFeedbackResponsesForReceiverForCourse
4. updateFeedbackResponsesForChangingTeam
   1. getFeedbackResponsesFromGiverForCourse
   2. for getFeedbackQuestion
      1. deleteFeedbackResponseCascade
   3. Repeat for getFeedbackResponsesForReceiverForCourse
   4. getStudentsForTeam
   5. deleteFeedbackResponsesInvolvedEntityOfCourseCascade if empty course
5. updateFeedbackResponsesForChangingSection
   1. getFeedbackResponsesFromGiverForCourse
   2. for updateFeedbackResponse
   3. for updateFeedbackResponseCommentsForResponse
      1. getFeedbackResponse
      2. for updateFeedbackResponseComment
   4. Repeat for getFeedbackResponsesForReceiverForCourse

Among all the operations, for a single students:

• getFeedbackResponsesFromGiverForCourse x3
• getFeedbackResponsesForReceiverForCourse x3
• getFeedbackResponse x4
• updateFeedbackResponse x4
• updateFeedbackResponseComment x4

Consider reducing the unnecessary calls to the Datastore

[syrinemahmoud]

that sounds great !

[wkurniawan07]

"Allow course instructor to create course with > 100 students." is already achieved. Any other kind of performance improvement should warrant a different issue.