Outlook

Load test for many concurrent users

in progressForOperator

Measurements of how many concurrent users the installation can handle — measured up to 150 reading users, the large stages are pending.

Why#

An exam week is a load peak. Only what has been measured is reliable — and only what has been measured repeatably may go into a service description.

1The tool runs: it walks a student's route (home page, sign-in form, course list, course page, an image), does not sign in and creates no render jobs.
2Before the start it states how many requests the run will make; above 50,000 and against production it requires explicit confirmation.
3The large stages need a preview environment with a copy of the database and load from several lines.

No switch of its own in the feature catalogue — the feature belongs to its surroundings.

Up to 100 concurrent readers the installation answers all requests: 0 errors in 4,050 requests over six runs, 95 % of answers under 400 ms.
At 150 the first timeouts occur (0.13 %), and the slowest 5 % take over one second — no server error, no throttling.
Measured from one computer against production, reading routes only; the line was not the limit.

Figures above 150 concurrent users cannot be guaranteed as long as the load comes from only one computer.

Stages with 100, 1,000 and 5,000 enrolled students — designed according to the timetable, not only the statistics: at 9 am the whole lecture wants to get in at the same time.
Response times per surface (course player, voice-over, subtitles, avatar, achievement archive, verification chain)
behind that database, cache hit rate, queue of the avatar machines, errors of external services and costs per run
a load profile like a university day instead of even load

a preview environment with a copy of the database and test persons recognisable as fictitious — never against real records and exams
load from several lines
a fixed cost cap that aborts a run with real services instead of letting it get expensive