Ich bin Kyle McCormick, ein aufstrebender Student im zweiten Jahr am Worcester Polytechnic Institute, und ich habe gerade ein 11-wöchiges Sommerpraktikum im Mobile-Team von edX abgeschlossen. Während meiner Zeit im Team habe ich mich vor allem auf die leistungsbezogene Backend-Arbeit konzentriert. In diesem Beitrag werde ich über eines der beiden Projekte sprechen, mit denen ich die meiste Zeit verbracht habe.
Kurs-Metadaten-Caching
Eines der ersten Probleme, die ich annahm, war herauszufinden, warum wir unser Team anrufen Benutzer-Kursanmeldungs-API endpoint, der zur Anzeige des Hauptbildschirms in unserer mobilen App verwendet wird, brauchte über eine Sekunde, um zu antworten. Der Endpunkt gibt einfach eine Liste von Kursen zurück, in denen ein Benutzer eingeschrieben ist, zusammen mit einigen grundlegenden Kursmetadaten (Name, Universität, Startdatum usw.). Daher war es überraschend, dass dies mehr als ein paar hundert Millisekunden dauerte. Ich begann meine Untersuchung, indem ich den Code durchging, der die Registrierungsliste berechnete, indem ich verwendete Pyinstrument Profiling zu machen.
Eines der ersten Dinge, die mir aufgefallen sind, war, dass für jede Kursanmeldung Metadaten für den Kurs dreimal aus MongoDB geladen wurden (zweimal in Aufrufen zur Einschreibung.Kurs und einmal während der Serialisierung) und es wurde nicht zwischen Aufrufen an den Endpunkt zwischengespeichert. Ich hatte den Verdacht, dass dies die Ursache für die Leistungsprobleme des Endpunkts war, was ich mit dem „X-Ray Tracing“-Tool von NewRelic bestätigte.
Wie Sie dem oben gezeigten Trace entnehmen können, ist die Funktion modulestore/mixed.py.get_course, das Kurssoftware aus MongoDB lädt, verbrauchte 90 % der Antwortzeit. Dies implizierte, dass es zwei Möglichkeiten gab, den Endpunkt zu optimieren: make get_course schneller, oder minimieren Sie die Anzahl der Aufrufe, indem Sie die zurückgegebenen Daten zwischenspeichern get_course. Während Ersteres sicherlich etwas ist, das getan werden muss, ist es eine Aufgabe, die größere Änderungen am Code der Kernplattform erfordert. Da eine Caching-Lösung einfacher zu implementieren ist – es ist nur eine Schicht über der get_course anrufen – ich habe mich für letztere Lösung entschieden. Da das Caching zwischen Anforderungen funktioniert, ist es außerdem eine Verbesserung, die Vorteile hat, selbst wenn get_course ist optimiert.
Um die Metadaten eines Kurses zwischenzuspeichern, habe ich ein Django-Modell namens erstellt Kursüberblick. Wenn zum ersten Mal Metadaten für einen Kurs angefordert werden, get_course heißt, eine Instanz von Kursüberblick wird aus seinem Rückgabewert erstellt und die Instanz wird in MySQL gespeichert. Die nächste Anfrage für die Metadaten des Kurses lädt einfach die Kursüberblick Instanz, die nur eine einzige MySQL-Abfrage erfordert (im Gegensatz zu den 1-4 MongoDB-Abfragen, die für jeden Aufruf von get_course ausgeführt werden). Wenn ein Kurs in edX Studio aktualisiert wird, wird die entsprechende Kursüberblick -Instanz gelöscht, wodurch die nächste Anforderung gezwungen wird, die aktualisierten Metadaten durch einen Aufruf abzurufen get_course erneut.
Ich habe den API-Endpunkt für die mobile Benutzerkursanmeldung aktualisiert, um dieses Caching-System zu verwenden (PR # 8484) und führte Lasttests mit Locust.io durch, um zu bestätigen, dass es eine Leistungsverbesserung gab. Betrachtet man die Produktionsdaten auf NewRelic etwa zum Zeitpunkt der Veröffentlichung des aktualisierten Codes, wird die Auswirkung auf die Leistung auffallend deutlich.
Das obige Diagramm zeigt die durchschnittliche Antwortzeit für die Mobile APIs UserCourseEnrollmentsList Endpunkt in Millisekunden. Der Endpunkt wurde aktualisiert, um das Metadaten-Caching am 1. Juli zu verwenden. Die durchschnittliche Reaktionszeit sank von ~1100 ms auf ~110 ms.
Zusätzliche Caching-Anwendungen
Da ein ähnlicher Metadatensatz erforderlich ist, habe ich auch das Web-Studenten-Dashboard aktualisiert, um das Metadaten-Caching-System zu verwenden (PR # 8642), was zu einer weniger dramatischen, aber immer noch signifikanten Verkürzung der Reaktionszeit führte.
Die obige Grafik zeigt die adurchschnittliche Antwortzeit für das webbasierte edX-Schüler-Dashboard in Millisekunden. Das Dashboard wurde am 17. Juli aktualisiert, um Metadaten-Caching zu verwenden. Die durchschnittliche Reaktionszeit sank von 600 bis 800 ms auf ~250 ms.
Zusätzlich zu diesen beiden Anwendungsfällen kann das Caching-System in jedem Szenario genutzt werden, in dem grundlegende, benutzerunabhängige Kursmetadaten erforderlich sind. Beispielsweise hat ein anderer edX-Mitarbeiter kürzlich unsere allgemeine Registrierungs-API für die Verwendung aktualisiert Kursüberblicks statt anzurufen get_course (PR # 8927), was zu einer 10-fachen Verringerung der Reaktionszeit des 95. Perzentils für die führt EnrollmentListView Endpunkt.
Fazit
Wie mein Kollege Ben in erwähnte sein Blogbeitrag, glänzt das edX-Praktikumsprogramm wirklich darin, wie es seine Praktikanten in echte Softwareentwicklungsteams einbettet, sie wie Vollzeitmitarbeiter behandelt und ihnen wirkungsvolle Projekte zur Verfügung stellt, an denen sie arbeiten können. Da ich noch nie zuvor an einem Projekt dieser Größenordnung und Anzahl von Mitwirkenden gearbeitet habe, habe ich unglaublich viel gelernt. Obwohl meine Amtszeit hier zu Ende gegangen ist, hoffe ich, in der großartigen Open edX-Community involviert zu bleiben. Abschließend möchte ich Nimisha, Chris, Kishore, Adam, Dave und dem Rest des edX-Teams für ein unvergleichliches Praktikum danken!
