How to reduce load on Learning Management Systems

If you’re an Adobe Captivate e-learning developer, it is now most likely that you will be delivering your e-learning courses via some kind of Learning Management System (LMS for short).  If so, you may encounter an issue where course participants complain about the content “freezing up” or pausing repeatedly during playback.

This issue is usually caused by LMS server latency. In mild cases it can just be annoying. In serious cases it can completely cripple the effective delivery of your e-learning project.

If you haven’t already done so, I recommend you read this other blog post first to understand what server latency is all about and how it can impact e-learning. Once you understand the issue better, come back and finish this post to learn about the countermeasures you can use to address it in Adobe Captivate.

Minimize the number of file requests

As mentioned in the above-mentioned post explaining LMS server latency, the greater the number of separate files there are in your course, the more requests will be sent to your LMS server to download them.  An HTML5 course published from Adobe Captivate is actually made up of hundreds (potentially thousands) of smallish files, all of which need to be requested from the server. But since HTML5 is now more or less the only viable Adobe Captivate publishing option for web delivery you should at least reduce the number of file requests by minimizing the number of images, and other small objects in the course content.  For example, rather than having a large number of separate images on a slide to create a complex background, how about just assembling these images in a graphics editor as a single graphic file and use that as a slide background instead?

Minimize data requests by modifying Quiz Settings

If you’re suffering with serious LMS server latency issues, the number of files in your ourse is not likely to be the biggest culprit.  You should probably be looking at reducing the number of data requests.  Server latency issues often turn out to be related to the number of times your Captivate content is pinging the LMS server to tell it about the course participant’s interaction with the content.

So what can you do about that?  Fortunately quite a bit!

For the purpose of this discussion we’re assuming you’re using a SCORM-compliant LMS because this gives you the largest number of options for reducing server load. (Choosing any of the non-SCORM reporting solutions in Captivate cuts out most of the options we discuss below.)

All of the options that allow you to reduce LMS server load are found on the Quiz > Reporting dialog.  We’ll start at the top of the dialog and work our way down, discussing each option you can use.

Use the SendTrackingDataAtEnd Template

When you choose SCORM as your LMS standard, Captivate assigns a default template full of code designed to communicate with the LMS.  However, the default template uses Captivate’s normal ‘verbose’ communication method, which deluges the LMS with tons of information.

However, you can opt to use a different Template by selecting one from the dropdown list. The best one for reducing LMS load is called SendTrackingDataAtEnd.  

How is this template better? Well, instead of sending tracking data to the LMS all the time while the participant is interacting with your course, this template stores the information and only sends it to the LMS when the user exits the course module.  That means one request to the server instead of dozens.

This single change is likely to have the biggest positive impact on server latency issues. If you want to test whether or not changes to your content will fix your server latency issue, perform this one change and test the output on your server.  If this has little noticeable impact, I doubt whether any of the other changes below will make a difference either.  Your server is probably toast.

(By the way, if you have experienced SCORM programmers on your staff, you also have the option of creating a custom template and adding this to the relevant sub folder in the Templates folder of the Captivate install directory under Program Files.  But don’t attempt this unless you or your programmer really know what you’re doing.)

Report quiz results only, not slide views

Let’s be honest.  How often do you really need to track what percentage of the slides were viewed by the course participant?  In most courses the key result that everyone is interested in is whether or not the participant passed or failed the quiz.  

So, unless you have a compelling requirement to track slide views, I recommend you turn off this option by deselecting the relevant Slide Views boxes on the Quiz Preferences screen as shown in the example screenshot below.

Since the number of content slides in a module usually far outnumber the quiz slides, not tracking slide visits will further reduce the data sent to the LMS server.

Don’t report Interaction Data

Further down on the Quiz Reporting dialog you will find the section that determines Data to Report to the LMS.  This option is selected by default.  Deselect it, as shown below, to further reduce load on the server.

LMS Advanced Settings (a.k.a LMS Customization Settings)

This dialog is reached via buttons near the bottom of the Quiz > Reporting dialog.  Just look for the Advanced button (as shown in the screenshot above) and when clicked it opens a dialog like the one of those shown below.

This dialog is seen when you select SCORM 2004.
This dialog is seen when you select SCORM 1.2

As noted below each screenshot, there are slightly different options depending on whether you select SCORM 1.2 or SCORM 2004. However, regardless of that difference, the two important options here for reducing server load are:

  • Send Data On Every Slide – Ensure this option is deselected to prevent Captivate from pinging the LMS every time the user advances from one slide to another.
  • Never Send Resume Data – This option is deselected by default. So, you need to select it to prevent Captivate from sending data to the LMS about which slide the participant is currently on. (Resume Data allows the LMS to ‘bookmark’ the specific slide the course participant was viewing at the time they exited the module as well as grab any data about their quiz question answers and score. When the user later resumes their session this data is fed back to the module so that everything looks the same as when they left off. So, selecting this option to “never send resume data” effectively disables LMS bookmarking.  Bookmarking the user’s progress in a course module is usually regarded as a good thing. So, you would only choose to disable it if bookmarking was deemed far less important than reducing your server latency.)

Which countermeasures should you use?

Well that depends entirely on how bad your server latency issue happens to be. Only you and your IT department are really able to answer that question.  If you’re not currently suffering with noticeable server latency issues (as indicated by course participants complaining about the content freezing up for no apparent reason), you probably won’t need to enact any of the countermeasures outlined above.

Another factor to weigh up is that all configuration options in Captivate have advantages and disadvantages. Each thing you turn on or off will have an impact somewhere else in your content.  For example, if your e-learning modules are quite long and most users do not complete them in a single session, having Resume Data bookmarking might be deemed more essential than the small amount of extra server load it imposes.

So, you need to weigh the pros and cons before making a final decision. And the only way to evaluate the pros and cons is by making changes and then testing to verify the resulting differences in server load.

Last resort: Upgrade your server technology!

At the end of the day, if your server technology is outdated or inadequate, none of the measures suggested above may ever be enough to fix “the issue”.  You could end up just chasing your tail spending hours, days or weeks modifying your courses when the best solution might simply be to lobby your management for budget to buy the level of hardware infrastructure your organization really needs to cope with the amount of learning you need to deliver over the next 5-10 years.