Understanding caching

We often get enquiries from our users about why their data doesn’t appear on the web site immediately that they enter it into onCourse. There are a few things to understand here about why it works this way, but I’ll try to keep it fairly non-technical.

Firstly, when you make changes in onCourse, it will take 5-10 minutes for those changes to be sent (replicated) to the web database. This is a periodic process which makes connections from your onCourse Server to the onCourse Web application cluster. If your internet is down, then it will keep trying until the service comes back up again. If this is the very first time you’ve had the ish onCourse replication service enabled, you may need to restart onCourse Server to put it into a state where it starts to make regular connections.

Secondly, our application server cluster (it is actually a whole collection of applications running across multiple servers for redundancy and load balancing) does its own caching. This means that your web site can display the front page of your site for the 27th time in one second without going back to the database each time, to fetch courses, classes, sites, rooms, sessions, tags and so on which are all needed to draw pages, show places available and so on. In our new search engine which we plan to complete later this year, there is a separate search engine index (another cache) which is refreshed every 30 minutes. These caches are all needed to get a good balance between speed and freshness of data. Some pages (like the student portal or enrolment pages) are not cached at all since the load on these pages is much less. For other pages like course details and listing the cache can be up to an hour, but because of the multitude of different applications running on different physical servers, you can sometimes get one application instance with new data and then other times get another with older cached data.

Because course title and description information doesn’t change rapidly, these types of update delays are typically quite acceptable. For other data, such as class places available, we don’t cache the results at all.

Next, your ISP is probably performing some caching of the pages you view. This happens across all websites and ISPs do this because it helps reduce the load on their network and also give results back to their users more quickly. 3,000 users all visiting www.smh.com.au from the BigPond network might actually result in one page load and 3,000 results sent back from a Telstra cache.

Finally, there is a cache in your browser. This often kicks in when you press the back button in your browser for instance. You don’t get a refreshed page, just the results you saw last time.

So, the next time someone asks you “why hasn’t my course description changed immediately?”, you can explain why. Or just tell them to go make a cup of tea.