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 Speedscale component that collects logs and metric data from pods during a replay. This service runs beside replay components like the generator and responder during the replay and communicates with the Kubernetes API.
A set of rules which determines whether to include or exclude traffic.
See replaying traffic for more information.
A Speedscale component that captures traffic from a client to your service (inbound) and from your service to third parties like other APIs or databases (outbound). Go proxy is, as its name suggests, a proxy which captures traffic routed through it.
See proxy modes for more information.
A Speedscale component that executes actions on your behalf in your cluster. Actions like adding a sidecar proxy to your workload, or starting a replay.
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.
Note that replay run with low data mode will not be able to run assertions as the full RRPairs are not available, but the report will show when errors occur.
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.
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 single request and response, for HTTP. Like a ping which goes out to the target and back, a transaction consists of a single round trip, whatever that means for the protocol in use.
Transactions Per Second
The number of transactions completed in a single second of measurement. Transactions per second (TPS) are used to describe the throughput of one endpoint or a service as a whole.
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.
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.