Sono Kyle McCormick, al secondo anno in ascesa al Worcester Polytechnic Institute, e ho appena terminato uno stage estivo di 11 settimane nel team Mobile di edX. Durante il mio tempo nel team, mi sono concentrato principalmente sul lavoro di back-end relativo alle prestazioni. In questo post parlerò di uno dei due progetti su cui ho dedicato più tempo.
Memorizzazione nella cache dei metadati del corso
Uno dei primi problemi che ho affrontato è stato capire perché chiamava il nostro team API di iscrizione al corso per utenti endpoint, che viene utilizzato per visualizzare la schermata principale nella nostra app mobile, impiegava più di un secondo per rispondere. L'endpoint restituisce semplicemente un elenco di corsi a cui è iscritto un utente, insieme ad alcuni metadati di base del corso (nome, università, data di inizio, ecc.), quindi è stato sorprendente che ci volessero più di poche centinaia di millisecondi. Ho iniziato la mia indagine scorrendo il codice che ha calcolato l'elenco delle iscrizioni, utilizzando strumento musicale fare la profilazione.
Una delle prime cose che ho notato è che per ogni iscrizione al corso, i metadati del corso venivano caricati da MongoDB tre volte separate (due volte nelle chiamate a immatricolazione.corso e una volta durante la serializzazione) e non veniva memorizzato nella cache tra le chiamate all'endpoint. Avevo il sospetto che questa fosse la causa dei problemi di prestazioni dell'endpoint, che ho confermato utilizzando lo strumento "X-Ray Tracing" di NewRelic.
Come si può notare dalla traccia mostrata sopra, la funzione modulestore/mixed.py.get_course, che carica i corsi da MongoDB, consumava il 90% del tempo di risposta. Ciò implicava che esistevano due modi per ottimizzare l'endpoint: make get_corso più veloce o ridurre al minimo il numero di chiamate memorizzando nella cache i dati restituiti da get_corso. Mentre il primo è sicuramente qualcosa che deve essere fatto, è un'attività che richiede modifiche importanti al codice della piattaforma principale. Poiché una soluzione di memorizzazione nella cache è più semplice da implementare, è solo un livello sopra il get_corso call – ho scelto di perseguire quest'ultima soluzione. Inoltre, poiché la memorizzazione nella cache funziona tra le richieste, è un miglioramento che presenta vantaggi anche se get_corso è ottimizzato.
Per memorizzare nella cache i metadati di un corso, ho creato un modello Django chiamato Panoramica del corso. La prima volta che vengono richiesti i metadati per un corso, get_corso si chiama, un'istanza di Panoramica del corso viene creato dal suo valore restituito e l'istanza viene salvata in MySQL. La prossima richiesta per i metadati del corso caricherà semplicemente il file Panoramica del corso istanza, che richiede solo una singola query MySQL (al contrario delle 1-4 query MongoDB eseguite per ogni chiamata a get_course). Quando un corso viene aggiornato in edX Studio, il corrispondente Panoramica del corso l'istanza viene cancellata, il che forza la richiesta successiva a recuperare i metadati aggiornati chiamando get_corso nuovamente.
Ho aggiornato l'endpoint API di iscrizione al corso utente mobile per utilizzare questo sistema di memorizzazione nella cache (PR # 8484), ed eseguito test di carico utilizzando Locust.io per confermare che si è verificato un miglioramento delle prestazioni. Osservando i dati di produzione su NewRelic nel periodo in cui è stato rilasciato il codice aggiornato, l'impatto sulle prestazioni è sorprendentemente evidente.
Il grafico sopra mostra il tempo di risposta medio per le API mobili Elenco iscrizioni al corso utente punto finale in millisecondi. L'endpoint è stato aggiornato per utilizzare la memorizzazione nella cache dei metadati il 1° luglio. Il tempo di risposta medio è sceso da ~1100 ms a ~110 ms.
Ulteriori applicazioni della memorizzazione nella cache
Poiché richiede un insieme simile di metadati, ho anche aggiornato la dashboard degli studenti Web per utilizzare il sistema di memorizzazione nella cache dei metadati (PR # 8642), che ha comportato una riduzione dei tempi di risposta meno drammatica ma comunque significativa.
Il grafico sopra mostra l'atempo di risposta medio per la dashboard degli studenti edX basata sul Web in millisecondi. Il dashboard è stato aggiornato per utilizzare la memorizzazione nella cache dei metadati il 17 luglio. Il tempo di risposta medio è sceso da 600-800 ms a ~250 ms.
Oltre a questi due casi d'uso, il sistema di memorizzazione nella cache può essere sfruttato in qualsiasi scenario in cui sono richiesti metadati del corso di base indipendenti dall'utente. Ad esempio, un altro dipendente edX ha recentemente aggiornato la nostra API di registrazione generale da utilizzare Panoramica del corsos invece di chiamare get_corso (PR # 8927), determinando una riduzione di 10 volte del tempo di risposta del 95° percentile per il Visualizzazione elenco iscrizioni punto finale.
Conclusione
Come ha menzionato il mio collega stagista Ben il suo post sul blog, il programma di tirocinio edX brilla davvero per il modo in cui inserisce i suoi stagisti in veri team di ingegneria del software, trattandoli come dipendenti a tempo pieno e dando loro progetti di grande impatto su cui lavorare. Non avendo mai lavorato prima su un progetto di questa portata e con un numero di collaboratori di questo tipo, ho imparato una quantità incredibile. Anche se il mio mandato qui è giunto al termine, spero di rimanere coinvolto nella fantastica comunità di Open edX. Infine, vorrei ringraziare Nimisha, Chris, Kishore, Adam, Dave e il resto del team edX per un'esperienza di stage incomparabile!
