Executive Summary
Running an online exam looks like a solved problem from the outside: show the questions, collect the answers, publish the marks. The difficulty is not the exam. It is that a few hundred people do exactly the same thing at exactly the same second, four times in two hours. Over the past weeks we load-tested our assessment engine to a thousand simultaneous candidates on production infrastructure, found four separate failures that ordinary testing would never have surfaced, fixed them, and changed how we verify. This is what we found.
1. “The First Fifteen Minutes Are Always Slow”
This is the single most common thing institutes tell us about online exams, and it is worth taking seriously rather than explaining away. The complaint is precise: not that the platform is slow generally, but that the opening window is, and that it recovers once everyone is settled.
That pattern is diagnostic. It means the system is not short of capacity in general — it is being asked to do a quarter of the day's work in a tenth of the time. Two of the four heaviest operations an assessment platform performs are stacked into those opening minutes, and they are stacked for every candidate simultaneously.
Everyone signs in
A quarter hour of concentrated authentication, often on devices that have not been used for an exam before. Each device also loads its list of assessments.
Everyone presses Start
The full question paper is delivered to every candidate within the same few minutes, and an attempt is created for each. This is the heaviest read the system performs all day.
Everyone saves, continuously
Answers and time state stream to the server throughout, not at the end. Steady and predictable — and the reason a dropped connection costs a candidate nothing.
Everyone submits
Objective papers are scored as they arrive, and late finishers cluster into the final two minutes. This is where a platform either holds or visibly stalls.
2. We Stopped Estimating and Measured
Capacity claims are easy to make and hard to verify, so we built a test that plays the entire candidate journey — sign in, load the paper, start, autosave every sixty seconds through the exam, submit — and ran a thousand of them simultaneously against the same production servers that serve institutes every day, not a clean rig assembled for the occasion.
Two decisions made that test useful rather than reassuring. We ran it during working hours alongside real traffic, so the numbers describe a working platform rather than an idle one. And we treated the load-testing tool's own report as insufficient evidence.
In one round, every one of a thousand submissions returned success — and a fraction of those candidates had no stored submission. The request succeeded; the record did not survive. We only found it because we checked all thousand attempts individually in the database afterwards. That reconciliation is now a required step, and it is the question we would put to any vendor quoting a concurrency number.
3. Four Things We Found by Breaking Our Own System
None of these were capacity problems. At no point in any test was the constraint the network, the database or the login service — those sat idle while candidates waited. Every failure was the same shape: work that ran one item at a time where it should have run in bulk or in the background.
Work that quietly ran one at a time
Every submission triggered an analytics step — gather the answers, compute the candidate's rank against the class, send it onward. It was named and documented as a background task, but the annotation that actually makes it run in the background was missing. So it ran inside the candidate's submission request. With a thousand people submitting together it consumed the entire pool of request handlers, and ordinary autosaves queued behind it.
A background job that erased submissions
The retest looked perfect: a thousand submissions, no errors. Checking the database told a different story — a small share of candidates had their submission silently discarded, the attempt still marked in progress with no score. A background recalculation working from a stale snapshot finished last and overwrote the record. The candidate would have seen 'submitted' and walked away.
A single announcement breaking every autosave
A defect in how one database record was constructed meant that the moment a teacher posted an announcement during a live exam, every candidate's autosave began failing. It had never been noticed because the feature had never successfully been used — which is its own kind of warning.
A recalculation storm on a real paper
The most recent one appeared only under real conditions: a 42-question paper with genuine question content. A missing transaction boundary turned one efficient batch write into roughly 84 separate database round trips per candidate, per save. With 41 candidates that was enough to push background scoring to 29 seconds.
The last one is worth dwelling on, because it explains why testing alone is not enough. It did not appear at a thousand simulated candidates, and it did appear at forty-one real ones. The difference was the data: our test papers used simple placeholder questions, while a real paper carries genuine question content, options and formatting. The load was realistic; the data was not. We have changed how we build test papers as a result.
4. What Is Measured Now
With those fixes in place, a full exam journey at a thousand simultaneous candidates records the following — 95th percentile, meaning the experience of the unluckiest candidate in every twenty, not an average:
| Step | Response time | What it covers |
|---|---|---|
| Signing in | 146 ms | Authentication as the exam window opens |
| Loading the paper | 465 ms | Delivering the full question paper to each candidate |
| Starting the exam | 134 ms | Everyone pressing Start within the same few minutes |
| Autosaving answers | 140 ms | Continuous saving throughout the attempt |
| Submitting | 139 ms | Final submission and scoring, including the end rush |
Zero failed requests. All 1,000 papers verified individually afterwards as submitted and scored. Exam servers peaked at under a third of allocated capacity.
5. What We Are Still Working On
We would rather write this section than leave it out. One piece of the opening window is not finished: the screen that lists a candidate's available exams runs a heavier query than it needs to, and every candidate's device asks for it about once a minute. When a cohort arrives together, that screen can take several seconds — and it is felt precisely in the first few minutes, which is exactly the window institutes complain about.
It affects the landing screen rather than the exam itself: candidates already writing are unaffected, and nothing is at risk. But it is the remaining part of the problem as institutes actually experience it, we have measured it rather than assumed it away, and it is the next thing we are fixing.
6. Exam Day Also Needs a Control Room
Capacity is only half of a calm exam day. The other half is what an invigilator can do at 11:20 when a candidate reports a frozen laptop. Staff see candidates split into Attempted, Ongoing and Pending with live counters, and can act on one person or many at once.
Add extra time
Grant additional minutes to ongoing attempts individually or in bulk.
Close submissions
Force-submit attempts still running past the deadline.
Grant re-attempts
Give selected candidates another attempt after a genuine disruption.
Release results
Publish per candidate, in bulk, or for the whole assessment.
The paper is usually the real bottleneck
For most institutes, the constraint on running weekly mocks is not server capacity at all — it is the hours it takes to build each paper. Existing question banks sitting in documents and PDFs can be converted into structured, auto-gradable questions, which is what makes a weekly series realistic rather than aspirational.
7. What to Ask Before Your Next Big Exam
Whoever you run your exams with, these questions separate a tested platform from a hopeful one:
- Has the capacity number been measured, or estimated? Ask for the date, the cohort size and the time of each step.
- Was it measured on the servers we will actually use? A separate test environment proves little.
- Were the results reconciled against the database? Not just a green report from a load tool.
- What happens to a candidate who disconnects at minute forty? If the answer is not “they rejoin the same attempt”, plan for disputes.
- Can staff intervene mid-exam? Extra time, force-submit and re-attempts are exam-day essentials.
Cohort size is one variable among several — paper length, question content and answer-sheet size all change the arithmetic, as we learned the hard way. For an unusually large exam we will simulate your specific setup and hand you the measured numbers before your candidates sit down.