Docs Automation & analysis
Load testing
Run JMeter load tests from the dashboard: shape the ramp, hold and ramp-down, watch latency and failures live, and find the concurrency where it breaks.
Launchpad → Automation → Load test sends many simulated users at a site. It shows what happened to the latency, the failures and the machines underneath. The load is generated by Apache JMeter on the server that runs your install.
The engine
If JMeter is already installed, it is used: JMETER_BIN, /opt/jmeter, or jmeter on the PATH. Otherwise, on Linux x64 or arm64, the install fetches JMeter 5.6.3 and an Eclipse Temurin 21 Java runtime into its own data directory. It checks both against published checksums, and proves they work with jmeter --version before offering them. That is about 310 MB. Nothing is installed system-wide, and it leaves with the data directory. Set LOADTEST_ENGINE_AUTO=0 to stop the download. While the engine is installing, the page says so. Everything works except pressing Run.
Shaping the load
A test is one shape, set with sliders:
- Opens with, Climbs to and Ends on: the number of users at the start, at the peak and at the end.
- Up, Hold and Down: how long the climb, the peak and the descent last.
- Wait between: each user's pause between requests.
A short climb is a spike. A long one is a busy morning, and a long hold is a soak. Optionally, load stylesheets, scripts and images too makes each user fetch a page's assets, six at a time, as a browser would. Requests are GETs with the user agent Obscenter-LoadTest/1.0, so they are easy to recognise in your logs.
What this machine can drive
Before a run, you are told whether the machine running the test can generate that much load. The ceiling is the smallest of three limits: free processor cores, available memory for the Java process, and open files. It is halved when the target resolves to the same machine, with a warning that latencies will then read high. After a run with at least 20 users, the costs actually measured replace the estimates. The verdict reads one of:
- "This machine can drive that."
- "It will run, but only just." (above 75% of capacity)
- "This machine is too small for that test."
When the machine is too small, Fit it to this machine scales the peak down to what it can do.
Watching it
While a run is going, the page updates every three seconds. It shows the phase, the users, the requests, the failures, p50, p95 and p99, and the rate over the last five seconds. Stop run ends it. One load test runs at a time on an install.
The result
The verdict says how many requests failed and finds the knee: the concurrency at which latency started to rise. Below it, the site absorbed more users. Above it, users waited for each other. Beside that is what the run did to your machines and services over the run, and a minute either side, from the data the agents were already sending. The load test and the server-side picture are read together.
Who may run one
Starting a load test is a person's decision. It needs a signed-in account with both the Automation and the Console capabilities. No API key can start one, or read the list of runs. Each organisation sees and stops only its own runs. Point it only at sites you are allowed to test. A load test against someone else's site is an attack.