What happened?

At 10am, the sign-up process for some teaching groups opened to a large number of students. These students naturally all descended upon Tabula at the same time, loading pages that can take over 10 seconds to load depending on the user, how many modules they are on etc.

We’ve previously added some mitigation to handle users repeatedly refreshing the page to alleviate some load, but there is definitely more work to be done.

What will we do now?

We have already started a phase of performance improvement across Tabula, using data to identify the slowest pages and prioritise improvements there. Every slow page that becomes fast increases the amount of load that Tabula can handle overall, making a total slowdown less likely. On top of that, faster page loads simply improve the experience for everyone - it’s never ideal to have to wait several second for a page to load. Sometimes this is hard to avoid as Tabula loads a lot of interrelated data about courses, modules, groups, all to display useful information to you. However there are plenty of ways we can be smarter about loading data to keep overall page loads fast.

We’ll also be investigating higher-level methods of keeping Tabula running in the event that some parts become slow:

• Segregating database connections. Currently, Tabula has a finite shared pool of database connections it can use to read and write data, meaning it’s possible for enough slow requests to use up all these connections and starve other pages that might otherwise be fast to load. By giving potentially slow pages their own dedicated pool, they can’t starve the rest of Tabula.
• Limits/queueing. For certain operations where we expect spikes of traffic, we can look at ways to implement limits on how many slow operations can be happening at a time, and either returning a “try in a minute” message to other users, or possibly place them in a virtual queue where first-come-first-served behaviour is important.