Scalability of Canvas

430 views
Skip to first unread message

Johannes Barop

unread,
Feb 6, 2013, 8:07:08 AM2/6/13
to canvas-l...@googlegroups.com
Hello,

we're evaluating LM systems to setup one central instance for a bunch of universities and schools.

Does anyone have real-world experiences with the performance of Canvas under under high load? How does Canvas scale? Is it realistic or should we consider sharding the user by school/university?


Cheers,
Johannes

Trương Hoàng Dũng

unread,
Feb 7, 2013, 5:27:57 AM2/7/13
to canvas-l...@googlegroups.com
Firstly, Canvas need very much RAM and CPU. For example, when you migrate a course, the background processes eat nearly almost CPU capacity very fast. So i think, the way Canvas can scale very much depends on how you use it.

Steve Hillman

unread,
Feb 9, 2013, 2:10:35 AM2/9/13
to canvas-l...@googlegroups.com
We are slowly ramping up our own Canvas deployment. We've done load tests using JMeter that suggest that, under heavy student load (each user hitting the server every 3-6 seconds), we wouldn't be able to do much better than about 25 *concurrent* users per CPU. That means that a 4-CPU VM could handle about 100 concurrent users during peak periods (which might correspond to 1000-2000 total users - really depends on how active your students are). During our testing, "view" time and "db" time were not very significant -- most of the time was spent in the controllers. That means you *might* be able to get away with a single database server if you make it powerful enough. It's easy to add more app servers, but you can't run multiple db's without either creating separate stacks for each school or introducing a lot of complexity -- e.g. one master with multiple slaves, load balancing across the slaves, and a replication from the master db out to the slaves.

Right now this is mostly hypothetical for us. We don't actually know what "real" student load will look like -- we can only simulate it with JMeter. And while JMeter can simulate lots of clicks, it's a lot harder to simulate unique users which means that "100 concurrent users" is actually "100 of the same user" and doesn't truly exercise the caching mechanisms and database usage.

Another poster mentioned slow background processing. When scaling up with Canvas, you should devote some number of app nodes to just doing "delayed jobs" processing. These are asynchronous processes that could affect response time for real-time requests. These asynchronous processes could be anything from rethreading a discussion topic and generating the json for the browser (milliseconds), to doing a bulk-import from your SIS system (hours)

Hope that helps.


--
 
---
You received this message because you are subscribed to the Google Groups "Canvas LMS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to canvas-lms-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Steve Hillman        IT Architect
hil...@sfu.ca       Institutional, Collaborative, & Academic Technologies (ICAT)
778-782-3960         Simon Fraser University

Reply all
Reply to author
Forward
0 new messages