A validation applied to each individual RRPair captured in a report, used to confirm your application behavior during replay. Use a filter to narrow the scope of assertions. Assertions are defined in test configs. Assertions have no effect when running in low data mode.
A partial representation of a URI, endpoints often group similar requests together. View the endpoints requests were made to during a replay at the bottom of the report.
A set of rules which determines whether to include or exclude traffic.
See creating traffic filters and the filters reference for more information.
A Speedscale component that generates traffic from a snapshot, targeting the SUT. When running a load test the generator is the service responsible for generating the load.
See replaying traffic for more information.
Low Data Mode
A replay mode of operation which does not collect RRPairs. This mode is useful for high-throughput replays, like a load tests, which may make hundreds of thousands of requests. In this case it may not be feasible to capture and analyze each request individually. Low data mode can be applied to the generator or responder in the test config.
A Kubernetes operator that runs in your cluster to perform Speedscale actions on your behalf. Actions like adding a sidecar proxy to your workload, or starting a replay in your cluster.
See Kubernetes Operator for more information.
A process that accepts, stores, and forwards traffic. Speedscale uses goproxy, a purpose-built proxy written in Go, in various ways to capture traffic and route requests.
The act of replaying a snapshot which usually involves the generator making requests to the SUT. A traditional replay involves a Speedscale generator, which makes requests to the SUT (inbound), which makes requests to the Speedscale responder (outbound), which mocks external resources. A replay may not involve a generator though, as in responder-only replay mode.
See replaying traffic for more information.
The artifact of a replay, a report contains aggregate information about latency and throughput, as well as detailed information about the requests made.
Reports are listed on the snapshots page in the UI.
See reports for more information.
A Speedscale component that mocks other services using traffic from a snapshot. The responder looks like the Stripe API, or a Postgres server, or whatever else so that you can test your app in a controlled environment.
See service mocking and mocking backends for more information.
The RRPair, short for request / response pair, is the Speedscale internal representation in which all traffic is stored. The RRPair is segregated into a request and a response, but also may contain just part of a request or response like when representing part of a data stream.
Schedule Speedscale actions to run automatically on a regular basis.
See schedules for more information.
A collection of captured RRPairs that can be replayed in your cluster or from your local desktop.
Snapshots are listed on the snapshots page in the UI.
The Speedscale CLI which can be used to interact with Speedscale resources in all the same ways the Speedscale UI does.
See cli setup for more information.
System under test. Whenever Speedscale documentation mentions a SUT, we're talking about your application. Your app/service is the system Speedscale is testing and this is a generic way to refer to it.
Configuration for a traffic replay.
Test configs are listed on the test configs page in the UI.
See test configs for more information.
All of the bytes sent or received by your application.
Inbound traffic is the traffic that is being sent to, and received by, your application. This may also be called ingress. An example of inbound traffic is an HTTP request sent to your server's API.
Outbound traffic is the traffic that is sent by your application to external resources. This may also be called egress. An example of outbound traffic is a database query, or calling the API of another service.
Speedscale UI for visualizing traffic where each line contains an RRPair.
Traffic for each of your applications can be found on the traffic page in the UI.
A set of functions which can be used to modify traffic at various points during a replay.
Transforms are listed on the transforms page in the UI.
See transforms for more information.
Generic documents stored in the Speedscale cloud which can be referenced during a replay. Use speedctl to manage these documents.
A bucket of values which can be shared between requests during a replay. Servers are often stateful, or expose stateful behavior from networked storage. In order to simulate this behavior a cache can store a value on one request and retrieve it from another. Variables may also be populated statically in the transform editor.