README.md Raw History Folder

Load tests

loadtest replays a traffic scenario against an ermite server. It reports throughput and latency per request while holding open the live updates streams (/-/events) that real visitors keep.

Quick start

scripts/loadtest/serve.sh                 # seeded server on :7418, pinned to 1 core
go run ./scripts/loadtest -scenario home  # closed-loop, 32 clients, 10 s
scripts/loadtest/serve.sh stop

serve.sh builds ermite from the current checkout and seeds five repositories (busy, bursty, steady, private, empty). It pins the server to the last CPUS cores (default 1) with GOMAXPROCS and taskset. A fast workstation would otherwise measure itself, not a small host. Keep the load generator off those cores: taskset -c 0-15 go run ./scripts/loadtest ….

Modes

Mode	Flags	Answers
Closed-loop	`-c 32`	Maximum throughput: clients send back to back.
Open-loop	`-rate 1000 -c 64`	Latency at a target load. Latency counts from when the request was due, so a slow server cannot hide its queue. Requests that find no free client are reported as missed.

Other flags: -d duration, -warmup, -streams (multiplier of the scenario stream counts, 0 for none), -token (signed-in pages), -var name=value, -json out.json (to compare runs), -url.

The run fails (exit 1) on any request error, refused or dropped stream, or missed request.

Against a loopback server, each stream dials from its own 127.1.x.y address. The server caps watches per client address (usecase.MaxWatchersPerClient) and in total (usecase.MaxWatchers).

Scenarios

Built-in scenarios live in scenarios/*.json. A file path also works: -scenario ./my.json.

{
  "name": "repo",
  "requests": [
    { "name": "summary", "path": "/{{repo}}", "weight": 4 },
    { "name": "commits", "path": "/{{repo}}/commits", "weight": 1 }
  ],
  "streams": [
    { "name": "events", "path": "/-/events?topic=repo:{{repo}}", "count": 50 }
  ]
}

weight is the share of the requests.
status is the expected status code (default 200).
{{name}} is replaced by -var name=value.
Every request is fetched once before the run; a wrong status stops it early.

Reading the figures

The figures depend on the host. Compare runs made on the same machine with the same CPUS, and note the CPU in the report. The report header shows the load generator; the server is whatever serve.sh pinned.

source

1# Load tests
2
3`loadtest` replays a traffic scenario against an ermite server. It reports throughput and latency per request while holding open the live updates streams (`/-/events`) that real visitors keep.
4
5## Quick start
6
7```sh
8scripts/loadtest/serve.sh                 # seeded server on :7418, pinned to 1 core
9go run ./scripts/loadtest -scenario home  # closed-loop, 32 clients, 10 s
10scripts/loadtest/serve.sh stop
11```
12
13`serve.sh` builds ermite from the current checkout and seeds five repositories (busy, bursty, steady, private, empty). It pins the server to the last `CPUS` cores (default 1) with `GOMAXPROCS` and `taskset`. A fast workstation would otherwise measure itself, not a small host. Keep the load generator off those cores: `taskset -c 0-15 go run ./scripts/loadtest …`.
14
15## Modes
16
17| Mode | Flags | Answers |
18|---|---|---|
19| Closed-loop | `-c 32` | Maximum throughput: clients send back to back. |
20| Open-loop | `-rate 1000 -c 64` | Latency at a target load. Latency counts from when the request was due, so a slow server cannot hide its queue. Requests that find no free client are reported as **missed**. |
21
22Other flags: `-d` duration, `-warmup`, `-streams` (multiplier of the scenario stream counts, `0` for none), `-token` (signed-in pages), `-var name=value`, `-json out.json` (to compare runs), `-url`.
23
24The run fails (exit 1) on any request error, refused or dropped stream, or missed request.
25
26Against a loopback server, each stream dials from its own `127.1.x.y` address. The server caps watches per client address (`usecase.MaxWatchersPerClient`) and in total (`usecase.MaxWatchers`).
27
28## Scenarios
29
30Built-in scenarios live in `scenarios/*.json`. A file path also works: `-scenario ./my.json`.
31
32```json
33{
34  "name": "repo",
35  "requests": [
36    { "name": "summary", "path": "/{{repo}}", "weight": 4 },
37    { "name": "commits", "path": "/{{repo}}/commits", "weight": 1 }
38  ],
39  "streams": [
40    { "name": "events", "path": "/-/events?topic=repo:{{repo}}", "count": 50 }
41  ]
42}
43```
44
45- `weight` is the share of the requests.
46- `status` is the expected status code (default 200).
47- `{{name}}` is replaced by `-var name=value`.
48- Every request is fetched once before the run; a wrong status stops it early.
49
50## Reading the figures
51
52The figures depend on the host. Compare runs made on the same machine with the same `CPUS`, and note the CPU in the report. The report header shows the load generator; the server is whatever `serve.sh` pinned.