我是 Kyle McCormick，Worcester Polytechnic Institute 的大二新生，我刚刚在 edX 的移动团队完成了为期 11 周的暑期实习。 在团队工作期间，我主要专注于与性能相关的后端工作。 在这篇文章中，我将讨论我花费最多时间的两个项目之一。
课程元数据缓存
我处理的第一个问题是弄清楚为什么打电话给我们团队的 用户课程注册 API 用于在我们的移动应用程序中显示主屏幕的端点需要一秒钟的时间来响应。 端点只返回用户注册的课程列表，以及一些基本的课程元数据（名称、大学、开始日期等），因此它花费了超过几百毫秒，这令人惊讶。 我通过遍历计算注册列表的代码开始我的调查，使用 py仪器 进行分析。
我注意到的第一件事是，对于每个课程注册，课程的元数据都从 MongoDB 加载了三次（两次 在调用enrollment.course 和 一旦 在序列化期间）并且它没有在对端点的调用之间被缓存。 我怀疑这是端点性能问题的原因，我使用 NewRelic 的“X-Ray Tracing”工具确认了这一点。
从上面显示的跟踪中可以看出，函数 模块存储区/mixed.py.get_course，从 MongoDB 加载课件，消耗了 90% 的响应时间。 这意味着有两种方法可以优化端点： 获取课程 更快，或者通过缓存返回的数据来最小化对它的调用次数 获取课程. 虽然前者肯定是需要完成的事情，但这是一项需要对核心平台代码进行重大更改的任务。 由于缓存解决方案更易于实现——它只是在 获取课程 打电话——我选择了后一种解决方案。 此外，由于缓存在请求之间起作用，因此它是一种有益的改进，即使 获取课程 被优化。
为了缓存课程的元数据，我创建了一个名为 课程大纲. 首次请求课程的元数据时， 获取课程 被称为，一个实例 课程大纲 从其返回值创建，并将实例保存到 MySQL。 对课程元数据的下一个请求将只加载 课程大纲 例如，它只需要一个 MySQL 查询（而不是为每次调用 get_course 执行的 1-4 个 MongoDB 查询）。 当课程在 edX Studio 中更新时，相应的 课程大纲 实例被清除，这会强制下一个请求通过调用来获取更新的元数据 获取课程 一次。
我更新了移动用户课程注册 API 端点以使用这个缓存系统（PR＃8484)，并使用 Locust.io 执行负载测试，以确认性能有所提高。 通过查看更新代码发布时 NewRelic 上的生产数据，性能影响非常明显。
上图显示了移动 API 的平均响应时间 用户课程注册列表 以毫秒为单位的端点。 端点已于 1 月 1100 日更新为使用元数据缓存。 平均响应时间从 ~110 ms 下降到 ~XNUMX ms。
缓存的其他应用
因为它需要一组类似的元数据，所以我还更新了网络学生仪表板以使用元数据缓存系统（PR＃8642)，这导致响应时间减少了，但仍然显着减少。
上图显示了一个基于 Web 的 edX 学生仪表板的平均响应时间（以毫秒为单位）。 仪表板已于 17 月 600 日更新为使用元数据缓存。 平均响应时间从 800-250 毫秒降至约 XNUMX 毫秒。
除了这两个用例之外，缓存系统还可以在需要基本的、与用户无关的课程元数据的任何场景中使用。 例如，另一位 edX 员工最近更新了我们的通用注册 API 以使用 课程大纲s 而不是调用 获取课程 (PR＃8927)，导致 10% 响应时间减少 95 倍 注册列表视图 端点。
结语
正如我的实习生 Ben 在 他的博客文章, edX 实习计划真正的亮点在于它如何将实习生嵌入到真正的软件工程团队中，像对待全职员工一样对待他们，并为他们提供有影响力的项目。 我以前从未参与过如此规模和如此众多的贡献者的项目，我学到了很多东西。 虽然我在这里的任期已经结束，但我希望继续参与令人敬畏的 Open edX 社区。 最后，我要感谢 Nimisha、Chris、Kishore、Adam、Dave 和 edX 团队的其他成员，感谢他们提供了无与伦比的实习经历！
