Kannu is the Kadenze, Inc.’s flagship learning management system (LMS) that powers the digital learning experiences of schools, institutions, and companies all over the world. Kannu is also the core of kadenze.com, an online course platform focused on art, music, and creative technology courses from world-renowned schools like Stanford University, Princeton University, UCLA, Columbia, and many others. As the entire educational system was forced into the futuristic virtual reality overnight due to COVID-19, Kannu and kadenze.com experienced a dramatic influx of new users, exposing the need for immediate performance optimizations.
The performance challenge
Kadenze’s tech stack is based on a Ruby on Rails application deployed to the Amazon Web Services cloud. While the in-house engineering team was focusing on product development, the project needed a hand in managing the increased load—and here came Martians, with an exceptional background in Rails performance and the record of dozens of speed troubleshooting projects.
A small crew of Martians jumped in to help on the same day as Jordan Hochenbaum, the CTO of Kadenze, had contacted us.
Only a week after, the situation improved significantly: we reduced the average service web response time by 76%, bringing it from 500+ milliseconds to less than 200 milliseconds.
For users, it means popular scenarios like visiting a homepage to start a new course do not feel sluggish anymore; in fact, most of the application’s “golden paths” are now significantly faster. For Kadenze engineers, the quicker response from the servers means fewer resources to allocate even when the influx of visitors stresses the workloads.
Oil the Rails
Over the years, Martians mastered the art of speeding up Rails applications. So, like in the majority of our performance projects, we started with monitoring.
We carefully examined the existing monitoring metrics by setting up in-depth custom dashboards—in this case, with New Relic—to determine and separate the parts that needed to be “cured.” The problem of redundant database calls is a typical diagnosis for large Rails applications, and Kadenze wasn’t an exception. By adding caching and eliminating N+1 queries, we managed to cut the number of database calls per request by up to 95% in critical areas. The app could breathe normally again.