LMS Scalability: Can Your Platform Handle It?

If you sell courses in launches or run students through in cohorts, you need to consider what happens when a few hundred people sign in within the same hour and all start module one together. LMS scalability normally gets described as how many students a platform can support in total. This article shows you how to work out how many students will be using your site at the same moment, and what to do with that number once you have it.

If you sell evergreen courses, where people buy and start whenever they like, your enrollments arrive steadily and the load spreads across weeks. Most of what follows will not affect you.

Why an LMS puts more load on a server than a normal website

An LMS puts more load on a server than a normal website because its pages can’t be cached. Most sites are fast because the server builds a page once, saves the result, and hands that same copy to everyone who asks for it. Course pages can’t work like that, since each one shows a particular student their own progress, which is why LearnDash’s guidance is to exclude courses, lessons, topics, quizzes and groups from caching.

So every course page is built from scratch. Your server handles those requests using PHP workers, and one worker deals with one request until that request is finished. If your plan includes four workers and five students open a lesson at the same instant, the fifth waits for a worker to come free. That is why the number of students on your site at once matters more than the number enrolled.

Video is another load, and where it’s served from decides whether it touches your server at all. Video on YouTube or Vimeo is delivered by the platform. Video uploaded to your own site is served by your server, competing with every course page request, so moving it to YouTube or Vimeo is usually the single biggest improvement available to you.

How to work out how many students will be on your site at once

Working out how many students will be on your site at once uses records you already have, so there is no guesswork involved.

If you have launched before, open your analytics or your LMS reports for the first day of your last cohort and find how many people were active during your busiest hour. Then scale that up in proportion to how much bigger the new cohort is.

If this is your first launch, take the number of people enrolled and assume all of them arrive in the same hour. The real figure will be lower, and this gives you a ceiling to plan against.

The bugs to watch for

The bugs to watch for are the ones that appear while your site is still up, which is what makes them difficult to catch in advance.

Video stalls or buffers partway through a lesson.
Quiz answers fail to save, so a student finishes and sees nothing recorded.
Logins loop, sending someone back to the sign-in page after they’ve already signed in.
Certificates don’t generate for students who have passed.
Progress shows against the wrong student, or does not update at all, which points at course pages being cached when they should not be.

These reach you as support emails from students who believe the course itself is broken.

How to test it before you launch

Testing before you launch means reproducing the arrival pattern on a copy of your site instead of on the live one. Set up a staging copy, which most managed hosts offer as a one-click option, and put a copy of your course on it.

Then get as many people into it at once as you can find. Ten to twenty colleagues, friends or past students, all logging in within the same few minutes and working through the first lesson, will tell you more than any specification sheet, because it puts the load through in the shape a real launch does.

Watch three things while they do it. Does the video start promptly for the people who join last, or only for the ones who got there first? Do quiz answers save on the first attempt? Does anyone get returned to the login screen?

For a bigger test than you can staff, load testing tools such as k6 and Loader.io simulate large numbers of visitors arriving together. They take some setting up, and they will not test video playback, so run the human version as well.

Frequently asked questions

That depends on your hosting and not on the LMS. LearnDash has no student limit of its own. What limits you is how many requests your server can deal with at the same time, which comes down to your PHP worker count, your database, and where your video is served from.

It hands the problem to someone else and charges you for it, usually as a percentage of what you sell. You also give up control of your design, your student list and your records. Staying on WordPress keeps those and leaves the capacity question with you and your host.

On the public parts of your site, yes. On the course pages themselves, caching causes the progress-tracking problems listed above, so those pages get excluded and their speed comes from server capacity instead.

Hosting built for LMS scalability

Liquid Web’s managed WordPress hosting is built for sites where visitors are logged in and pages have to be generated for each one, which is the position every LearnDash site is in. That means staging environments to run your launch test on, capacity sized for the hour everybody arrives rather than the daily average, and caching configured to leave your course pages alone.