Soy Kyle McCormick, un estudiante de segundo año en ascenso en el Instituto Politécnico de Worcester, y acabo de terminar una pasantía de verano de 11 semanas en el equipo móvil de edX. Durante mi tiempo en el equipo, me concentré principalmente en el trabajo de back-end relacionado con el rendimiento. En esta publicación, voy a hablar sobre uno de los dos proyectos en los que dediqué más tiempo.
Almacenamiento en caché de metadatos del curso
Uno de los primeros problemas que asumí fue averiguar por qué las llamadas al teléfono de nuestro equipo API de inscripción de cursos de usuario endpoint, que se utiliza para mostrar la pantalla principal en nuestra aplicación móvil, tardó más de un segundo en responder. El punto final simplemente devuelve una lista de cursos en los que está inscrito un usuario, junto con algunos metadatos básicos del curso (nombre, universidad, fecha de inicio, etc.), por lo que fue sorprendente que tardara más de unos pocos cientos de milisegundos. Comencé mi investigación recorriendo el código que calculó la lista de inscripción, usando instrumento pirata para hacer perfiles.
Una de las primeras cosas que noté fue que para cada inscripción en el curso, los metadatos del curso se cargaban desde MongoDB tres veces por separado (dos veces en llamadas a matricula.curso y una vez durante la serialización) y no se almacenaba en caché entre llamadas al extremo. Tenía la sospecha de que esta era la causa de los problemas de rendimiento del endpoint, lo cual confirmé usando la herramienta "X-Ray Tracing" de NewRelic.
Como puede ver en la traza que se muestra arriba, la función modulestore/mixed.py.get_course, que carga material didáctico desde MongoDB, consumía el 90 % del tiempo de respuesta. Esto implicaba que había dos formas de optimizar el punto final: hacer obtener_curso más rápido, o minimizar el número de llamadas al almacenar en caché los datos devueltos por obtener_curso. Si bien lo primero es ciertamente algo que debe hacerse, es una tarea que requiere cambios importantes en el código de la plataforma central. Dado que una solución de almacenamiento en caché es más sencilla de implementar, es solo una capa sobre la obtener_curso llamada: opté por seguir la última solución. Además, debido a que el almacenamiento en caché funciona entre solicitudes, es una mejora que tiene beneficios incluso si obtener_curso está optimizado.
Para almacenar en caché los metadatos de un curso, creé un modelo de Django llamado Resumen del curso. La primera vez que se solicitan los metadatos de un curso, obtener_curso se llama, una instancia de Resumen del curso se crea a partir de su valor de retorno y la instancia se guarda en MySQL. La siguiente solicitud de metadatos del curso solo cargará el Resumen del curso instancia, que requiere solo una única consulta de MySQL (a diferencia de las 1 a 4 consultas de MongoDB que se ejecutan para cada llamada a get_course). Cuando se actualiza un curso en edX Studio, el correspondiente Resumen del curso se borra la instancia, lo que obliga a la siguiente solicitud a buscar los metadatos actualizados llamando obtener_curso de nuevo.
Actualicé el punto final de la API de inscripción de cursos de usuarios móviles para usar este sistema de almacenamiento en caché (PR # 8484) y realizó pruebas de carga con Locust.io para confirmar que hubo una mejora en el rendimiento. Al observar los datos de producción en NewRelic en el momento en que se lanzó el código actualizado, el impacto en el rendimiento es sorprendentemente evidente.
El gráfico anterior muestra el tiempo de respuesta promedio para las API móviles Lista de inscripciones de cursos de usuario punto final en milisegundos. El punto final se actualizó para usar el almacenamiento en caché de metadatos el 1 de julio. El tiempo de respuesta promedio se redujo de ~1100 ms a ~110 ms.
Aplicaciones adicionales de almacenamiento en caché
Debido a que requiere un conjunto similar de metadatos, también actualicé el panel web del estudiante para usar el sistema de almacenamiento en caché de metadatos (PR # 8642), lo que resultó en una reducción del tiempo de respuesta menos dramática pero aún significativa.
El gráfico anterior muestra latiempo de respuesta promedio para el panel de estudiantes de edX basado en la web en milisegundos. El tablero se actualizó para usar el almacenamiento en caché de metadatos el 17 de julio. El tiempo de respuesta promedio se redujo de entre 600 y 800 ms a ~250 ms.
Además de estos dos casos de uso, el sistema de almacenamiento en caché se puede aprovechar en cualquier escenario en el que se requieran metadatos básicos del curso independientes del usuario. Por ejemplo, otro empleado de edX actualizó recientemente nuestra API de inscripción general para usar Resumen del cursos en lugar de llamar obtener_curso (PR # 8927), lo que resultó en una disminución de 10 veces en el tiempo de respuesta del percentil 95 para el Vista de lista de inscripción punto final
Conclusión
Como mi compañero becario Ben mencionó en su entrada de blog, el programa de pasantías de edX realmente brilla en la forma en que integra a sus pasantes en equipos reales de ingeniería de software, tratándolos como empleados de tiempo completo y brindándoles proyectos impactantes en los que trabajar. Como nunca antes había trabajado en un proyecto de esta escala y cantidad de colaboradores, aprendí muchísimo. Aunque mi mandato aquí ha llegado a su fin, espero seguir participando en la increíble comunidad de Open edX. Finalmente, me gustaría agradecer a Nimisha, Chris, Kishore, Adam, Dave y al resto del equipo de edX por una experiencia de pasantía incomparable.
