Glossary

Term

Description

3xx

Indicates that the client must take additional action to complete the request. These status codes are typically used for redirection. The subsequent request address, or the redirection target, is specified in the Location field of the response.

4xx

Indicates that a client-side error has occurred, which prevents the server from processing the request.

5xx

Indicates that the server failed to fulfill a valid request. This usually means an error or an abnormal state occurred while the server was processing the request. It can also mean the server cannot process the request with its current hardware and software resources.

Trace

An ordered collection of stress testing APIs that represents a business process, similar to a transaction. Input and output parameters can be associated between APIs only within the same trace for runtime data transfer. Different traces are independent of each other. Parameters are typically not passed between different traces, unless you use the data exporting instruction.

Upstream Trace

A Setup Trace is a special type of trace that executes pre-test operations. It functions in the same way as a normal trace, but is executed before all general traces. This is similar to the Setup Thread Group in JMeter stress testing.

You can use pre-request traces for data preprocessing, such as exporting logon cookies.

Teardown trace

A trace that runs at the end of a stress test. It performs necessary operations after all regular traces have finished. This is similar to a TearDown Thread Group in JMeter.

Stress testing API

A client-side request triggered by a user action. A stress testing API is a required element in a stress testing scenario. It defines the URL details for each step within a trace. For example, on an E-commerce website, actions such as logging on, querying product details, and submitting an order each correspond to multiple request APIs within a single user behavior.

VU

A Virtual User (VU) simulates a user to generate load. The number of VUs represents the stress testing capacity. For example, 100 VUs means 100 independent threads continuously send requests.

VUM

A unit of measurement. VUM = VU × Minute.

Concurrent users

The number of users that send stress testing requests at the same time. During a stress test, a user can be a process or a thread.

Concurrent mode

A virtual user mode. Use this mode to determine the number of concurrent online users that your business system can handle.

Stress testing scenario

A combination of multiple URLs or APIs based on HTTP or HTTPS. The URLs or APIs can be associated with data files to represent different users. Different URLs or APIs represent different business actions, such as logging on or adding items to a shopping cart. The combination of these elements creates a stress testing model that simulates real user behaviors at a specific volume.

Response parameter

Content that is extracted from the response of a stress testing API. This content is then used as an input parameter for subsequent stress testing APIs.

Checkpoint (assertion)

Used to verify if the response to a stress test request meets expectations. This helps determine whether a business transaction is successful. A 200 response code does not always indicate a successful business transaction. You may need to check the content of the response body. In a PTS trace, if an assertion fails, the current request is not passed to the next stress testing API. The real-time report and the final report show the success or failure status of business transactions.

Rendezvous point

A point that makes virtual users wait. When a condition is met, all waiting users are released at once to continue the business flow. This is useful for scenarios such as flash sales.

If controller

Changes the execution path of requests in a trace based on response parameters. It supports actions such as jumping to a different step, continuing, or ending the trace.

RPS mode

A throughput mode. In this mode, a fixed number of requests per second (RPS) is sent.

SLA

A Service-Level Agreement (SLA) is an important basis for determining if a stress test is performing abnormally. During a stress test, monitor the SLA metrics of core services to get a clear view of the status of your business or architecture.

SLA metric

The metrics used to monitor data during a stress test. Currently, SLA metrics mainly include business quality indicators such as response time (RT), requests per second (RPS), and success rate. PTS will gradually add more SLA metrics for performance, such as basic data from Cloud Monitor, queues, and SQL connections.

SLA rule

An SLA metric with added judgment conditions that can trigger an alert or stop a stress test.

SLA template

A collection of SLA rules. A template can contain one or more SLA rules and is bound to an industry type.

Think time

The simulated time a user spends thinking or reacting between two consecutive steps. Multiple modes are supported.

Data exporting

An instruction provided by PTS. It exports data from a trace, such as cookies, response parameters, or parameters defined by a logic controller of data. The exported data is shared globally and can be used by other traces.

Logic controller of data

An instruction provided by PTS. It processes the response parameters, strings, or functions from a preceding stress testing API to define new parameters. These new parameters can then be used by subsequent stress testing APIs in the trace.

File parameter

Related parameters that are placed in different columns of a single file. Upload the file to import its parameter values into PTS. These parameters are called file parameters and can be used in stress testing APIs.

TPS

Stands for Transactions Per Second. The number of transactions that a system processes per second.

Response time (RT)

The time elapsed from when a client sends a request to when it receives the response from the server. Response time consists of three parts: request sending time, network transmission time, and server processing time.

75% response time

During the entire stress test period, from start to finish, 75% of all sampled response times for a specific trace or stress testing API are less than or equal to this value. Response times are sampled at a fixed interval.

Instruction

This component modifies and controls the behavior and flow within a trace, enabling a more realistic simulation of traffic for business stress testing.

Request success rate

The success rate of requests for this API during a stress test.

Timing waterfall flow

Shows the time taken by a request during each phase of its core lifecycle.

SLB monitoring

The Server Load Balancer (SLB) monitoring details page displays data for each SLB instance throughout the stress test. This data includes New Connections, Dropped Connections, outbound bandwidth, inbound bandwidth, and queries per second (QPS) for each port.

ECS monitoring details

The Elastic Compute Service (ECS) monitoring details page displays data for each ECS instance throughout the stress test. This data includes CPU utilization, memory utilization, inbound network traffic rate for each network interface card, disk read and write speed, and the 5-minute load average.

RDS monitoring details

The ApsaraDB RDS (Relational Database Service) monitoring details page displays data for each RDS instance throughout the stress test. This data includes connection usage, CPU utilization, disk usage, input/output operations per second (IOPS), and memory usage.