Expand description
Placing many calls at once, and reporting honestly about what happened.
Generic over what “a call” means — it is a closure returning a future — so the same harness drives sipx against itself and sipx against a third-party server. That is not generality for its own sake: a limit found with sipx on both ends cannot be attributed to either half, and the whole point of a load test is to find out which side gives out first.
Two rules about the reporting, both of which exist because breaking them makes the numbers worse than useless:
Failures are counted by cause, never aggregated. A run that goes from 99% to 97% success looks like mild degradation and may be a new failure appearing while an old one recedes. Which failure is growing is the entire question.
Latency is reported as percentiles, never as a mean. Call setup latency is not normally distributed — it is a tight cluster with a tail of retransmission timeouts — and a mean sits in the empty space between the two, describing a call that never happened.
Structs§
- Bounded
Outcome - Outcome plus the lifecycle facts a bounded command must report.
- Bounded
Plan - Finite admission and cleanup limits for an externally controllable run.
- Outcome
- What a run produced.
- Plan
- How much load to apply.
- Stop
- A clonable stop signal shared by admission and every owned call.
Enums§
- Admission
End - Why the harness closed admission.
- Cause
- Why a call did not succeed.
Functions§
- run
- Run a plan, placing calls with
place. - run_
bounded - Run a finitely bounded plan, stopping admission and draining every owned call before return.