Sou Kyle McCormick, um estudante de segundo ano em ascensão no Worcester Polytechnic Institute, e acabei de terminar um estágio de verão de 11 semanas na equipe Mobile da edX. Durante meu tempo na equipe, concentrei-me principalmente no trabalho de back-end relacionado ao desempenho. Neste post, vou falar sobre um dos dois projetos em que passei mais tempo.
Cache de metadados do curso
Uma das primeiras questões que enfrentei foi descobrir por que as chamadas para o API de inscrição no curso do usuário endpoint, que é usado para exibir a tela principal em nosso aplicativo móvel, estava demorando mais de um segundo para responder. O endpoint simplesmente retorna uma lista de cursos nos quais um usuário está matriculado, juntamente com alguns metadados básicos do curso (nome, universidade, data de início etc.), então foi surpreendente que estivesse demorando mais do que algumas centenas de milissegundos. Comecei minha investigação percorrendo o código que calculou a lista de matrículas, usando instrumento para fazer o perfil.
Uma das primeiras coisas que notei foi que, para cada inscrição no curso, os metadados do curso estavam sendo carregados do MongoDB três vezes separadas (duas vezes em chamadas para matrícula.curso e uma vez durante a serialização) e não estava sendo armazenado em cache entre as chamadas para o endpoint. Eu suspeitava que essa era a causa dos problemas de desempenho do endpoint, que confirmei usando a ferramenta “X-Ray Tracing” do NewRelic.
Como você pode ver no rastreamento mostrado acima, a função modulestore/mixed.py.get_course, que carrega o material didático do MongoDB, estava consumindo 90% do tempo de resposta. Isso implicava que havia duas maneiras de otimizar o endpoint: fazer obter_curso mais rápido ou minimize o número de chamadas para ele armazenando em cache os dados retornados por obter_curso. Embora o primeiro seja certamente algo que precisa ser feito, é uma tarefa que requer grandes mudanças no código da plataforma principal. Como uma solução de cache é mais simples de implementar - é apenas uma camada sobre o obter_curso call – optei por seguir esta última solução. Além disso, como o cache funciona entre solicitações, é uma melhoria que traz benefícios mesmo se obter_curso é otimizado.
Para armazenar em cache os metadados de um curso, criei um modelo Django chamado Visão geral do curso. A primeira vez que os metadados de um curso são solicitados, obter_curso é chamado, uma instância de Visão geral do curso é criado a partir de seu valor de retorno e a instância é salva no MySQL. A próxima solicitação de metadados do curso apenas carregará o Visão geral do curso instância, que requer apenas uma única consulta MySQL (em oposição às 1-4 consultas MongoDB que são executadas para cada chamada para get_course). Quando um curso é atualizado no edX Studio, o Visão geral do curso instância é limpa, o que força a próxima solicitação a buscar os metadados atualizados chamando obter_curso novamente.
Atualizei o endpoint da API de inscrição no curso de usuário móvel para usar este sistema de cache (PR # 8484) e realizou testes de carga usando o Locust.io para confirmar que houve uma melhoria de desempenho. Ao observar os dados de produção no NewRelic na época em que o código atualizado foi lançado, o impacto no desempenho é notavelmente aparente.
O gráfico acima mostra o tempo médio de resposta para as APIs para dispositivos móveis Lista de Matrículas do Curso de Usuário ponto final em milissegundos. O endpoint foi atualizado para usar o cache de metadados em 1º de julho. O tempo médio de resposta caiu de ~1100 ms para ~110 ms.
Aplicações adicionais de cache
Como requer um conjunto semelhante de metadados, também atualizei o painel do aluno da Web para usar o sistema de cache de metadados (PR # 8642), o que resultou em uma redução menos dramática, mas ainda significativa, do tempo de resposta.
O gráfico acima mostra atempo de resposta médio para o painel do aluno edX baseado na web em milissegundos. O painel foi atualizado para usar o cache de metadados em 17 de julho. O tempo médio de resposta caiu de 600 a 800 ms para ~ 250 ms.
Além desses dois casos de uso, o sistema de armazenamento em cache pode ser aproveitado em qualquer cenário em que sejam necessários metadados de curso básicos e independentes do usuário. Por exemplo, outro funcionário da edX atualizou recentemente nossa API de inscrição geral para usar Visão geral do cursos em vez de chamar obter_curso (PR # 8927), resultando em uma diminuição de 10x no tempo de resposta do percentil 95 para o Visualização de lista de inscrições ponto final.
Conclusão
Como meu colega estagiário Ben mencionou em sua postagem no blog, o programa de estágio edX realmente brilha na forma como incorpora seus estagiários em equipes reais de engenharia de software, tratando-os como funcionários em tempo integral e dando-lhes projetos impactantes para trabalhar. Nunca tendo trabalhado em um projeto dessa escala e número de colaboradores, aprendi uma quantidade incrível. Embora meu mandato aqui tenha chegado ao fim, espero continuar envolvido na incrível comunidade Open edX. Por fim, gostaria de agradecer a Nimisha, Chris, Kishore, Adam, Dave e o restante da equipe edX por uma experiência de estágio incomparável!
