Skip to content

Technology & Security

Load test for many concurrent users

ForOperator

A tool that measures how many concurrent users the installation can handle — with a request cap, abort under overload and a report as a file. Measured up to 150 reading users; the large stages run as a project service against a preview environment.

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.

How it works#

  1. 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.
  2. 2Before the start it states how many requests the run will make and sets a cap (the plan plus a fifth, or chosen by you): once it is reached, the run stops. Above 50,000 requests and against production it requires explicit confirmation.
  3. 3If the installation tips over — a quarter errors in the last 200 requests — the run aborts by itself instead of loading it further.
  4. 4At the end it writes a report as a file: response times (p50, p95, p99), errors by type, every route separately, cap and reason for aborting.
  5. 5The large stages (1,000 and 5,000 enrolled) are a project service: they need a preview environment with a copy of the database and load from several lines.

Settings and switches#

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

What has been measured#

  • 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.

Related features#