| name | ramp-up-load-test |
| description | Run a concurrent load test against a 3270 host and report what it did, from a first smoke run through to a result worth quoting. |
| invocation | ["load-test","run-load","volume-test"] |
| tools | ["validate_workflow","run_workflow_once","start_load_test","get_load_test_metrics","get_live_workflow_status","stop_load_test"] |
| instructions | ["load-test-safety","reading-latency"] |
Running a load test
When to use
The user asks for a load test, a volume test, a soak, or wants to know how
many concurrent users a host will take.
Before you generate any load
- Confirm which host. A load test against the wrong LPAR is not something
you can undo, and a test host and a production host often differ by one
character. Say the hostname back and get agreement — see
load-test-safety.instructions.md.
validate_workflow on the workflow you are about to run. A malformed step
fails on every virtual user at once and tells you nothing about the host.run_workflow_once. One user, once. If a single pass does not complete,
a hundred concurrent ones will only produce a hundred copies of the same
failure. Read the captured screens and confirm the workflow does what the
user thinks it does.
Sizing the run
Start smaller than the target and work up. A run that saturates the host on
its first ramp tells you it broke but not where.
concurrent — virtual users. Begin at 5–10 even when the goal is hundreds.runtime_sec — how long to hold that load. Under about 60 seconds, ramp-up
is most of the run and the numbers describe the ramp rather than the load.- The workflow's own
RampUpBatchSize and RampUpDelay control how quickly
users arrive. Arriving all at once measures the host's ability to accept
connections, which is rarely the question.
While it runs
get_load_test_metrics for the counters and the duration percentiles.
get_live_workflow_status for where each virtual user currently is.
The second is what to reach for when throughput drops: if every worker is
sitting on the same step, the host is slow at one transaction rather than
slow in general, and that is a different problem with a different fix.
Reporting
Read reading-latency.instructions.md before quoting a percentile. The
short version: Durations is a rolling window of recent workflows, not the
whole run, so say what the sample was.
Report, in this order:
- What was run — host, workflow, concurrency, duration.
- Completed, failed, and connect failures separately. A connect failure is
the host refusing to talk, not a transaction failing, and mixing them
hides a capacity limit behind an apparent error rate.
- p50, p95 and p99 workflow duration, with the sample size.
- What the numbers mean for the question asked.
Anti-patterns
- Starting at the target concurrency because that is what was asked for.
- Quoting a mean. One slow tail is what everybody notices and a mean hides it.
- Reporting a run that had failures as though the timings are still valid —
workflows that failed early are fast, and they drag every percentile down.
- Leaving a run going after answering. Call
stop_load_test.
