Perform stress testing on a gRPC microservice - Performance Testing

The microservice stress testing feature is used to perform stress testing on microservices that are deployed in a virtual private cloud (VPC). You can quickly perform stress testing on microservices after you make simple configurations in the Performance Testing (PTS) console. This topic describes how to perform stress testing on a gRPC microservice.

Background information

In the typical microservice architecture, each service is exposed by using a gateway, and the security of each service is ensured by implementing network isolation. In most cases, microservices in the cloud are deployed in VPCs, which is more secure. Network isolation poses a high difficulty in stress testing on microservices in a VPC. The traditional solution is to build a stress testing tool based on a VPC and use the tool to perform stress testing on the microservices. For example, you can use the Apache JMeter tool to perform stress testing. Building the Apache JMeter tool is time-consuming and requires coding, and the Apache JMeter tool can provide only limited support for stress testing on microservices. The microservice stress testing feature that is developed by PTS can help resolve these issues. This feature allows you to quickly perform stress testing on microservices after you make simple configurations in the PTS console.

Procedure

Log on to the PTS console, choose Performance Test > Create Scenario, and then click gRPC.
On the Create gRPC Scenario page, configure the Scenario Name parameter and click Upload Proto File to upload the required proto file.
Note
If the proto file to upload has the same name as an existing proto file, the existing proto file is overwritten. If you want to compare the proto file that you upload and the related local proto file, you can obtain the MD5 value of the uploaded proto file in the Actions column and compare the MD5 value with the MD5 value of the local proto file to check whether the files are different.
On the Scenario Settings tab, click Add gRPC Request Node to add a test node that is required by the desired session.

Configure a scenario

Click the ryi icon on the right of a business session to expand the business session and configure the basic information, output parameters, and check points.

Parameter	Description	Example
Service URL	The IP address of the gRPC microservice.	127.0.0.1
Service Port	The port number of the gRPC microservice.	50051
Request Timeout Duration	The maximum duration that the testing end waits for a response from the tested end. Unit: milliseconds.	5000
SSL/TLS	Specifies whether to establish a secure connection.	Turned off
Function Name	The full name of the gRPC method. Note Configure this parameter in the `Package name.API operation name/Method name` format.	package.service/method
Metadata	The value of this parameter is similar to an HTTP request header. Configure this parameter in the `key:value` format.	a:1,b:2 Note Separate multiple key-value pairs with commas (,).
JSON-formatted Request	The messages that are described in the JSON format in the proto file.	`{ "shelf": { "id": 1, "theme": "hello" } }`

Configure output parameters

On the Output Parameter Definition tab of a session, configure output parameters for the session. For more information, see Output parameters.

Configure check points

On the Check Point (Assertion) tab of a session, configure check points for the session. For more information, see Check point (assertion).

(Optional) Controllers and timers

You can add controllers and timers based on the requirements of different stress testing scenarios.

On the Scenario Settings tab, click Add Controller to select the required controller.
- Loop controller: controls the number of times that a test node is executed in a loop.
  Select a loop controller and click the icon next to the controller. Then, select the node to be executed in a loop and specify the number of loops. During stress testing, the specified test node in the loop controller is sequentially executed for the specified number of times.
- Transaction controller: All test nodes in the transaction controller are counted as one transaction. The Generate parent sample and Include duration of timer and pre-post processors in the sample switches are displayed.
  - Generate parent sample:
    - If this switch is turned on, the stress testing results of each node in the transaction controller are not independently recorded in a stress testing report, but are aggregated as the results of the transaction controller.
    - If this switch is turned off, the transaction controller and the stress testing results of test nodes in the controller are displayed in the report.
  - Include duration of timer and pre-post processors in the sample: If this switch is turn on, the average response time of the transaction controller in the stress test report is the sum of the average response times of all test nodes, timers, and pre- and post- processors. If this switch is turn off, the average response time of the transaction controller is only the sum of the average response times of all test nodes.
- Only once controller: The nodes that are added to the controller are executed only once.
On the Scenario Settings tab, click Add Timer to select the required timer.
- Constant timer: specifies the pause duration, which indicates the pause duration during stress testing. Unit: milliseconds.
- Synchronous timer: specifies the values of Timeout and Number of Simulated Users, which indicates that the stress testing is triggered after a specific number of users is reached within a specified time range. However, if the specific number of users is not reached within the specified time range, the testing is triggered without continuous waiting.
- Unified random timer: specifies the pause duration. You can configure Constant Delay Offset and Random Delay. The Constant Delay Offset indicates a fixed pause time, and the Random Delay indicates the maximum random pause time. The pause duration of the unified random timer is the sum of the fixed pause time specified by Constant Delay Offset and the random value within the time range specified by Random Delay. Each random value has equal occurrence probability.
- Gaussian timer: specifies the pause duration. The Gaussian timer is similar to the unified random timer. You can configure Constant Delay Offset and Random Delay. If the random pause time is required to conform to the normal distribution, the Gaussian timer can be used.
- Fixed throughput timer: specifies the throughput so that test nodes are executed based on the throughput. You can configure conditions and specify the corresponding throughput. The conditions that you can configure include Only the current thread, All active threads, Active threads in the current link, Globally active thread, and Globally active threads in the current link.

Create a PTS scenario

Parameter	Description
Source of Stress	Internet: Nodes that initiate the stress testing are located around the world. The corresponding node resources (IP addresses) are allocated based on the magnitude of the stress testing. Alibaba Cloud virtual private clouds (VPCs): The stress testing in an Alibaba Cloud VPC is performed over the VPC. In the stress testing, the stress testers and the tested servers are located in the same region. For more information, see Stress testing in Alibaba Cloud VPCs.
Stress Mode	Virtual user mode: If you want to know the number of online users that can be hosted by each node in the business system from the client perspective, you can use this mode to configure the target virtual users. Requests per second (RPS) mode: The RPS mode is the throughput mode. This mode allows you to specify RPS to measure the throughput capabilities of your system from the server perspective, eliminates the cumbersome conversion from the virtual user mode to the RPS mode, and quickly implements the stress testing.
Auto Incremental Mode	Manual Adjustment: The number of virtual users is fixed. The corresponding stress prediction chart is a flat line that indicates the number of virtual users. The stress testing is always performed based on the specific number of virtual users. Tiered Increment: The number of virtual users is stepwise increased. This means that the number of virtual users that apply stress to a system has the tiered increment. The number of virtual users increases by a value within each period of time until an expected number of virtual users is reached. Then, the reached number of virtual users is maintained for a period of time. The corresponding stress prediction chart is a graph in the step form.
Max VUs	The Max VUs of the whole scenario in virtual user mode.
Increment Percentage	In tiered increment mode, you must specify the increment percentage.
Single Load Level Duration	In tiered increment mode, you must set the Single Load Level Duration to at least 1 minute to ensure that business issues can be found within the Single Load Level Duration.
Total Test Duration	If the stress testing duration is incremented, the duration is greater than or equal to the value that is calculated by using the following formula: Single Load Level Duration/Incremental magnitude × 1.1 (rounded up). However, the duration cannot exceed 24 hours.
Number of Specified IP Addresses	The number of IP addresses that apply stress. For more information, see Specify the number of IP addresses applying stress.
Region-specific Traffic	Specifies whether to set the regions in which stress testers are located. You can turn on this switch to simulate the local user traffic. After you turn on this switch, you can configure the region distribution of stress testers. This implements the customization of the region distribution of stress traffic. For more information, see Custom traffic.

Start a stress testing task

Click Save and Start. On the Note page, select Execute Now and The test is permitted and complies with the applicable laws and regulations. and then click Start.
To debug a scenario, click Debug. For more information, see Debug scenarios.

What to do next

Sample scenario

This section describes how to create a gRPC stress testing scenario based on a specific proto file.

Upload the proto file in which a gRPC microservice and a gRPC method are defined. Assume that CreateShelf is the gRPC method on which you want to perform stress testing. Sample code that defines the CreateShelf method in the proto file:

syntax = "proto3";

package bookstore;

service Bookstore {
  rpc ListShelves (google.protobuf.Empty) returns (ListShelvesResponse) {}
  rpc CreateShelf (CreateShelfRequest) returns (Shelf) {}
}

message ListShelvesResponse {
  repeated Shelf shelves = 1;
}

message CreateShelfRequest {
  Shelf shelf = 1;
}

On the Create gRPC Scenario page, click Upload Proto File to upload the preceding proto file.
After you configure the following parameters on the Scenario Settings tab, click Save and Start:
- Function Name: Set this parameter to bookstore.Bookstore/CreateShelf.
  Note
  In the preceding code for the proto file, the package name is bookstore, the API operation name is Bookstore, and the method name is CreateShelf. In this example, you must set the Function Name parameter to bookstore.Bookstore/CreateShelf.
- JSON-formatted Request: Enter the following code in the JSON-formatted Request field:
```
{
  "shelf": {
    "id": 1,
    "theme": "hello"
  }
}
```
  In the preceding code for the proto file, the input parameter for the CreateShelf method is CreateShelfRequest. The following code shows the custom value of the Shelf field:
```
syntax = "proto3";

package bookstore;

message Shelf {
  int64 id = 1;
  string theme = 2;
}
```