If you’re an Adobe Captivate e-learning developer, and you’re not already using a Learning Management System (or LMS for short), then the chances are very good you WILL need to work with one in the near future. When you do, you’ll find the issue of LMS server latency is something you need to understand and solve when developing your content.
Why do you need to understand this somewhat technical issue? How bad can it be?
Well, simply put, it could severely restrict or even cripple your entire e-learning project. If that doesn’t sound good to you, read on. This post explains what server latency is all about, and what causes it. Once you’ve digested this information, I recommend you head on over to this other post that explains the countermeasures you can use with Adobe Captivate to address latency.
What is Server Latency?
Broadly-speaking, the term ‘latency’ refers to the time a host server (e.g your LMS) takes to respond to a request for a file or object. I’m keeping this explanation as simple as possible and more focused on how latency relates to e-learning content.)
In a web-based e-learning course, your learner is using a browser to access and interact with your e-learning content. While they do this, ‘under the hood’ the browser and your LMS are sending data back and forth to each other across the internet, telling each other things and asking for things in return. When your course asks for a file or for information, this is known as a ‘request’.
Server latency is usually measured in milliseconds, thousandths of a second. And, as the page linked above tells you, a latency of 20-30 milliseconds is considered minimum, with latency between 75-140 milliseconds quite normal.
There are two main types of requests involved. File requests and interaction data. Let’s talk about them one at a time.
Latency due to the number of file requests
In the case of a typical Flash-based e-learning course that is NOT being served from an LMS, the objects requested from a web server might consist of an HTM file, one or more SWFs, a JS file, and possibly some video files (if you’re using video at all). Just a handful of objects is really all that’s required to serve up Captivate content.
Additionally, one of the big advantages of the Flash SWF file format is that it’s actually a compressed ‘wrapper’ file that works in a similar way to a zip archive. It can contain almost any number of files in a convenient, highly-compressed format. And since all the other files are encapsulated within the SWF wrapper, it only requires a single request to the server to download to your browser, regardless of how many files are bundled up inside it.
If you turn on SCORM 1.2 reporting in Captivate, and publish for upload to your LMS, the innocent-looking zip archive you end up with contains at least 15 files. Conversely, if you change to SCORM 2004 reporting and publish, you end up with a total of 47 files for the same course module. Now, these extra files are of course required for SCORM communication with your LMS.
In real terms even this number of files is still quite a small number and would not normally cause issues with excessive latency. Since all of these files need to be downloaded before your course can begin communicating with the LMS server, the only time they might be responsible for a delay in playback is right at the beginning of playback for your course module, not from then on.
How publishing for HTML5 can further add to server latency issues
As mentioned above, an elearning module published to SWF/Flash format might have 50 or so files. But, if you’re publishing as HTML5-based e-learning targeted at mobile devices, then you can add a lot more files to this list. In fact, a module containing just a single blank Captivate slide published for HTML5 SCORM 2004 will result in about 200 files. And that’s BEFORE you start adding any content!
Unlike the SWF format, HTML5 isn’t using any encapsulation or compression. So, all of the files that went into your course will exist as separate objects. This includes all images, audio clips, videos, style sheets, JavaScripts and other files containing code required to make your course work.
Even a reasonably simple course module will contain hundreds of objects. A large complex module could contain thousands, every one of which will need to be separately requested from the server. Every request will result in at least some latency.
So it should be no surprise that one of the frequent complaints now being heard on the Captivate Forum about HTML5 output is that it takes too long to load, and the playback is very “jerky”, stopping and starting often while another piece of content loads.
Latency issues due to the volume of interaction data
And now we come to the other big wrinkle in this issue: Interaction data. In fact, this can often be the biggest issue of all.
A lot of communication that happens between your course content and your LMS relates to data about what your learner is doing at that moment in time; how they are interacting with your course content.
In this area, Captivate has a reputation for being very ‘verbose’. That is, it’s default settings are to tell the LMS about everything that the learner is doing, potentially deluging the poor server with information about every slide entered, every object that gets clicked, every question answered, etc, etc.
This wouldn’t be so bad if the server had the option of selectively ignoring some of these requests. But in fact the server is expected to reply with a short acknowledgement that the interaction data was received…after each and every request.
And here’s the real kicker…After sending a request to the server, Captivate will sit patiently waiting for the server to reply before moving on. If your server is already busy, that’s when latency really bites.
The fact that Captivate pauses while waiting for the reply from the server doesn’t cause a noticeable issue UNTIL your server starts to reach the limit of the number of requests it can handle. But if your server has become overloaded with requests, then the latency delay while Captivate stops to wait for the server’s reply can gradually build up slide by slide until your course participants are potentially waiting several minutes for Captivate to respond.
And that’s when LMS server latency bites your e-learning course bigtime. Because as soon as the course participants are being forced to wait for any longer than a minute or so, they will conclude the course as “stopped responding” and therefore must have crashed. They’ll probably close down the browser, and hopefully try again. But it’s also likely they will log a support call, or complain about the amount of time they’ve wasted without getting a result.
What happens to the LMS Server?
A single 10 minute Captivate module can potentially communicate scores of requests to the LMS server while the user is interacting with it. If you have scores of users accessing courses on the same LMS server, the number of requests increases exponentially.
At some point all LMS servers will reach their request limit, and at that point everything slows down, latency increases, and if the volume of requests does not diminish, the server may eventually crash.
A case history
Some years ago I was working on a number of e-learning courses for a multi-national company. At that time the company did not have their own LMS so they had outsourced delivery of the course content to a nationally recognised LMS provider who supposedly had huge capacity.
We loaded up some first draft course modules for load testing and had them accessed by a few dozen employees. One module had 25 quiz questions. When any more than a dozen or more employees accessed that module, they started experiencing significant latency that gradually increased to several minutes between slides.
I was able to dial in and personally watch the Task Manager CPU readout of the LMS server during one of these sessions and saw it gradually climb to 100% CPU usage until the server eventually crashed under the load.
There was no way we were going to be able to roll out those courses until we reconfigured Captivate to reduce the LMS server load. Fortunately, we WERE successfully able to do this, and if you want to know how, read the other post I mentioned above that explains the counter-measures for LMS server latency.
