Cloud-based microservices typically run inside a Virtual Private Cloud (VPC), isolated behind network boundaries. Testing service performance in these environments is difficult -- traditional tools like JMeter must be deployed inside the VPC, which demands complex setup and significant expertise.
Performance Testing Service (PTS) provides a microservices performance testing feature that lets you conduct performance testing on microservices deployed in a VPC. From the PTS console, you configure and run performance tests against Spring Cloud microservices with simple configurations, eliminating the need to set up traditional testing tools like JMeter inside your VPC.
Key concepts
A PTS test scenario consists of several components that work together:
| Concept | Description |
|---|---|
| Scenario | A complete test configuration that includes target services, stress parameters, and traffic patterns |
| Spring Cloud node | A single microservice endpoint under test, defined by its application name, service name, and registry |
| Controller | Logic that controls execution flow: loops, transactions, or one-time setup |
| Timer | Pacing logic between requests that simulates realistic traffic patterns |
How these fit together: define a scenario, add one or more Spring Cloud nodes as test targets, optionally attach controllers and timers to shape traffic, configure stress parameters, and run the test.
Prerequisites
Before you begin, make sure you have:
Spring Cloud microservices deployed in a VPC
Microservices registered with a supported registry (Nacos, Eureka, or Direct-Connect)
The registry address and port for your microservices
Step 1: Create a test scenario
Log on to the PTS console.
Choose Performance Test > Create Scenario, then click Spring Cloud.
On the Microservice Scenario page, specify:
A scenario name
The source of the tested applications
The region where your microservices are deployed
The microservices namespace
On the Scenario Settings tab, click + Add Spring Cloud Node to add a test node.
Step 2: Configure the test node
Click the expand icon on the right side of the node to expand it, then configure the following settings:
| Parameter | Description | Example |
|---|---|---|
| Application Name | The spring.application.name value of your SpringBoot application | demo-pts-service-provider |
| Service name | The Spring Cloud service name | demo-service |
| Registry type | The service registry type: Eureka, Direct-Connect, or Nacos | Direct-Connect |
| Node | The registry address in http://[ip]:[port] or [ip]:[port] format | http://172.16.0.0:8080 |
| Access Path | The request URL path | /demo |
| Request Method | GET, POST, PUT, or DELETE. You must also define headers on the Header Definition tab. | GET |
| Timeout (ms) | Maximum wait time for a response. Default: 1000 (1 second). Keep this below 5000 ms for production services. | 1000 |
Registry address for Microservices Engine (MSE) users
The registry address format depends on whether you configured a namespace:
No namespace configured: Enter the registry address directly. The default namespace
DEFAULT_GROUPis used.XXX.nacos-ans.mse.aliyuncs.com:8848Namespace configured: Append the namespace ID as a query parameter.
XXX.nacos-ans.mse.aliyuncs.com:8848?namespaceId=abc
Headers and body
Configure request headers on the Header Definition tab. For details, see Header definition.
Configure the request body on the Body Definition tab. For details, see Body definition.
POST and PUT requests require a request body. Configure it on the Body Definition tab before running the test.
Output parameters
Configure output parameters on the Output Parameter Definition tab of a session. For details, see Output parameters.
Check points
Define pass/fail assertions on the Check Point (Assertion) tab. For details, see Check point (assertion).
Step 3: Add controllers and timers (optional)
Controllers and timers let you simulate realistic traffic patterns. Add them from the Scenario Settings tab.
Controllers
Click Add Controller and select a controller type:
| Controller | What it does | Configuration |
|---|---|---|
| Loop controller | Repeats a test node a specified number of times. Click the settings icon next to the controller, select the node, and set the loop count. | Node to loop, loop count |
| Transaction controller | Groups multiple test nodes into a single transaction. See configuration options below. | Generate parent sample, include timer duration |
| Only once controller | Runs nodes inside it exactly once. | Nodes to include |
Transaction controller options:
Generate parent sample: When enabled, individual node results are aggregated under the transaction. When disabled, both the transaction summary and individual node results appear in the report.
Include duration of timer and pre-post processors in the sample: When enabled, the transaction's average response time includes timers and pre/post-processors. When disabled, only test node response times are counted.
Timers
Click Add Timer and select a timer type:
| Timer | What it does | Key parameters |
|---|---|---|
| Constant timer | Adds a fixed pause between requests | Pause duration (ms) |
| Synchronous timer | Holds requests until a target number of virtual users accumulates, then releases them simultaneously | Timeout, Number of Simulated Users |
| Unified random timer | Adds a random pause with equal probability across the range | Constant Delay Offset (fixed pause) + Random Delay (max random pause) |
| Gaussian timer | Adds a random pause following a normal distribution | Constant Delay Offset + Random Delay |
| Fixed throughput timer | Controls request rate to match a target throughput | Throughput value and scope: Only the current thread, All active threads, Active threads in the current link, Globally active thread, or Globally active threads in the current link |
Step 4: Configure stress parameters
Configure how PTS generates load against your microservices:
| Parameter | Description |
|---|---|
| Source of Stress | Internet: Stress nodes are distributed globally; IP addresses are allocated based on load volume. Alibaba Cloud virtual private clouds (VPCs): Stress traffic stays within the VPC in the same region as your services. See Stress testing in Alibaba Cloud VPCs. |
| Stress Mode | Virtual user mode: Simulates concurrent users to determine how many your system supports (client-side perspective). Requests per second (RPS) mode: Sets a target throughput to measure server-side capacity directly. |
| Auto Incremental Mode | Manual Adjustment: Maintains a fixed number of virtual users throughout the test. The corresponding stress prediction chart is a flat line. Tiered Increment: Ramps virtual users in steps -- each step adds a percentage of the total, holds for a set duration, then increases again until the maximum is reached. The corresponding stress prediction chart is a graph in the step form. |
| Max VUs | The maximum number of virtual users for the entire scenario (virtual user mode only). |
| Increment Percentage | The percentage of Max VUs added at each step (tiered increment mode only). |
| Single Load Level Duration | How long each step lasts. Minimum: 1 minute. Set this long enough to detect issues at each load level. |
| Total Test Duration | Calculated as: Single Load Level Duration / Incremental magnitude x 1.1 (rounded up). Maximum: 24 hours. |
| Number of Specified IP Addresses | The number of IP addresses used to generate stress traffic. See Specify the number of IP addresses applying stress. |
| Region-specific Traffic | Enable this to distribute stress traffic across specific regions, simulating geographically distributed users. See Custom traffic. |
Choose the right stress mode
| Mode | Best for | Perspective |
|---|---|---|
| Virtual user mode | Determining how many concurrent users your system handles | Client-side |
| RPS mode | Measuring maximum throughput without estimating user-to-request ratios | Server-side |
When to use each mode:
Use Virtual user mode when you need to validate capacity for a known number of concurrent users, such as preparing for a product launch or traffic spike.
Use RPS mode when you want to directly measure your service's throughput ceiling, without converting between concurrent users and requests per second.
Step 5: Run the test
Click Save and Start. On the Note page, select Execute Now and The test is permitted and complies with the applicable laws and regulations., then click Start.
To validate your configuration before a full run, click Debug. For details, see Debug scenarios.
Step 6: Analyze test results
After the test completes, PTS generates a report with the following sections:
| Report section | What it shows |
|---|---|
| Scenario metrics | Overall throughput, error rates, and response times |
| Business details | Per-node performance breakdown |
| Monitoring details | Resource utilization during the test |
| API sampling logs | Individual request and response samples |
Use these results to identify bottlenecks: high error rates may indicate capacity limits, while rising response times under increasing load reveal performance degradation points.
For a walkthrough of the report, see View PTS stress testing reports.