System pressure measuring method and device

Abstract

The invention relates to the technical field of data processing, and particularly provides a system pressure measurement method and device, and the method comprises the steps: obtaining the capacity data and performance parameters of each service node in a pressure measurement process, and obtaining a pressure measurement result of each service node according to a comparison result of the performance parameters of each service node and a preset risk threshold value; and determining a capacity baseline parameter of each service node from the capacity data, determining a system baseline parameter according to the capacity baseline parameter of each service node and the capacity data of the target service node, and determining a pressure measurement result based on the system baseline parameter and preset flow data. In the embodiment of the invention, the system performance upper limit can be quantified more accurately, so that an accurate pressure measurement result is obtained, the risk of system capacity overload is greatly reduced, the potential risk of system performance reduction is sensed, and the system operation stability is improved.

Description

Technical Field

[0001] The present disclosure relates to the field of data processing technology, and in particular to a system stress testing method and device. Background Art

[0002] With the development of Internet technology, the server will receive a large number of data requests per second. In order to prevent system overload, a capacity baseline is usually pre-defined based on the system receiving traffic. When the receiving traffic exceeds the capacity baseline, the current CPU usage is calculated. If the CPU usage exceeds the threshold, it enters a "dangerous" state, and the system can take corresponding measures to expand the capacity.

[0003] However, this fixed capacity baseline stress testing method is neither accurate nor comprehensive, resulting in an inability to accurately reflect server performance and even causing great losses to the platform. Summary of the invention

[0004] In order to improve the accuracy of system stress testing, the embodiments of the present disclosure provide a system stress testing method, device, system and storage medium.

[0005] In a first aspect, an embodiment of the present disclosure provides a system stress testing method, wherein the system includes multiple service nodes, and the method includes:

[0006] Acquire capacity data and performance parameters of each service node during the stress test, where the performance parameters include two or more types of parameters;

[0007] Determining a capacity baseline parameter corresponding to each of the service nodes from the capacity data according to a comparison result between the performance parameter of each of the service nodes and a preset risk threshold of the performance parameter;

[0008] Determine the system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test;

[0009] The stress test result of the system is determined based on the system baseline parameters and preset flow data.

[0010] In some implementations, determining the capacity baseline parameter corresponding to the service node from the capacity data according to a comparison result between the performance parameter of each service node and a preset risk threshold of the performance parameter includes:

[0011] Compare each type of performance parameter of each of the service nodes with its corresponding risk threshold, and record the time point when each type of performance parameter reaches the risk threshold according to the comparison result;

[0012] A first target time point with the earliest time is determined from the time points corresponding to each type of performance parameter, and a capacity parameter corresponding to the first target time point in the capacity data is determined as a capacity baseline parameter of the service node.

[0013] In some implementations, determining the system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test includes:

[0014] Determine a target service node from the plurality of service nodes;

[0015] Determine the earliest second target time point based on the first target time point corresponding to the capacity baseline parameter of each service node;

[0016] The capacity parameter corresponding to the second target time point in the capacity data of the target service node is determined as the system baseline parameter.

[0017] In some implementations, the risk threshold of each performance parameter includes a warning threshold and an alarm threshold, and the alarm threshold is greater than the warning threshold; and determining the capacity baseline parameter corresponding to each service node from the capacity data according to a comparison result between the performance parameter of each service node and a preset risk threshold of the performance parameter includes:

[0018] For each type of performance parameter, in response to the performance parameter being greater than or equal to its corresponding warning threshold, record a first time point, determine a third time point with the earliest time from the first time points corresponding to each type of performance parameter, and determine the capacity parameter corresponding to the third time point in the capacity data as the security baseline parameter of the service node;

[0019] and / or,

[0020] In response to the performance parameter being greater than or equal to its corresponding alarm threshold, a second time point is recorded, a fourth time point with the earliest time is determined from the second time points corresponding to each type of performance parameter, and the capacity parameter corresponding to the fourth time point in the capacity data is determined as the warning baseline parameter of the service node, and the capacity baseline parameter includes the safety baseline parameter and the warning baseline parameter.

[0021] In some implementations, determining the system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test includes:

[0022] Determine the earliest third time point according to the third time points corresponding to the security baseline parameters of each service node, and determine the capacity parameter corresponding to the earliest third time point in the capacity data of the target service node as the system security baseline parameter;

[0023] The earliest fourth time point is determined according to the fourth time point corresponding to the alert baseline parameters of each service node, and the capacity parameter corresponding to the earliest fourth time point in the capacity data of the target service node is determined as the system alert baseline parameter, and the system baseline parameter includes the system safety baseline parameter and the system alert baseline parameter.

[0024] In some implementations, determining a target service node from the plurality of service nodes includes:

[0025] Determining the target service node from the plurality of service nodes based on a user operation instruction;

[0026] or,

[0027] Based on the capacity data of each service node, a service node with the highest capacity parameter peak is determined as the target service node.

[0028] In some implementations, the system baseline parameters include the system safety baseline parameters and the system alert baseline parameters; and determining the stress test results of the system based on the system baseline parameters and preset flow data includes:

[0029] In response to the preset flow data being less than the system safety baseline parameter, determining that the stress test result of the system is in a safe state;

[0030] In response to the preset flow data being greater than or equal to the system safety baseline parameter and less than the system warning baseline parameter, determining that the stress test result of the system is in a risk state;

[0031] In response to the preset flow data being greater than or equal to the system warning baseline parameter, it is determined that the stress test result of the system is in a state to be expanded.

[0032] In some implementations, the performance parameters include the CPU usage, the request response time, and the request error rate.

[0033] In some implementations, the capacity data of the service node includes the number of queries per second or the number of transactions per second of the service node during stress testing.

[0034] In a second aspect, an embodiment of the present disclosure provides a system stress testing device, including:

[0035] An acquisition module is configured to acquire capacity data and performance parameters of each service node during the stress test, wherein the performance parameters include two or more types of parameters;

[0036] A node baseline module is configured to determine a capacity baseline parameter corresponding to each of the service nodes from the capacity data according to a comparison result of a performance parameter of each of the service nodes with a preset risk threshold of the performance parameter;

[0037] A system baseline module is configured to determine system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test;

[0038] The result determination module is configured to determine the stress test result of the system based on the system baseline parameters and preset flow data.

[0039] In some implementations, the node baseline module is configured to:

[0040] Compare each type of performance parameter of each of the service nodes with its corresponding risk threshold, and record the time point when each type of performance parameter reaches the risk threshold according to the comparison result;

[0041] A first target time point with the earliest time is determined from the time points corresponding to each type of performance parameter, and a capacity parameter corresponding to the first target time point in the capacity data is determined as a capacity baseline parameter of the service node.

[0042] In some embodiments, the system baseline module is configured to:

[0043] Determine a target service node from the plurality of service nodes;

[0044] Determine the earliest second target time point based on the first target time point corresponding to the capacity baseline parameter of each service node;

[0045] The capacity parameter corresponding to the second target time point in the capacity data of the target service node is determined as the system baseline parameter.

[0046] In some implementations, the risk threshold of each performance parameter includes a warning threshold and an alarm threshold, and the alarm threshold is greater than the warning threshold; the node baseline module is configured as follows:

[0047] For each type of performance parameter, in response to the performance parameter being greater than or equal to its corresponding warning threshold, record a first time point, determine a third time point with the earliest time from the first time points corresponding to each type of performance parameter, and determine the capacity parameter corresponding to the third time point in the capacity data as the security baseline parameter of the service node;

[0048] and / or,

[0049] In response to the performance parameter being greater than or equal to its corresponding alarm threshold, a second time point is recorded, a fourth time point with the earliest time is determined from the second time points corresponding to each type of performance parameter, and the capacity parameter corresponding to the fourth time point in the capacity data is determined as the warning baseline parameter of the service node, and the capacity baseline parameter includes the safety baseline parameter and the warning baseline parameter.

[0050] In some embodiments, the system baseline module is configured to:

[0051] Determine the earliest third time point according to the third time points corresponding to the security baseline parameters of each service node, and determine the capacity parameter corresponding to the earliest third time point in the capacity data of the target service node as the system security baseline parameter;

[0052] The earliest fourth time point is determined according to the fourth time point corresponding to the alert baseline parameters of each service node, and the capacity parameter corresponding to the earliest fourth time point in the capacity data of the target service node is determined as the system alert baseline parameter, and the system baseline parameter includes the system safety baseline parameter and the system alert baseline parameter.

[0053] In some embodiments, the system baseline module is configured to:

[0054] Determining the target service node from the plurality of service nodes based on a user operation instruction;

[0055] In some embodiments, the system baseline module is configured to:

[0056] Based on the capacity data of each service node, a service node with the highest capacity parameter peak is determined as the target service node.

[0057] In some implementations, the system baseline parameters include the system safety baseline parameters and the system alert baseline parameters; and the result determination module is configured to:

[0058] In response to the preset flow data being less than the system safety baseline parameter, determining that the stress test result of the system is in a safe state;

[0059] In response to the preset flow data being greater than or equal to the system safety baseline parameter and less than the system warning baseline parameter, determining that the stress test result of the system is in a risk state;

[0060] In response to the preset flow data being greater than or equal to the system warning baseline parameter, it is determined that the stress test result of the system is in a state to be expanded.

[0061] In some implementations, the performance parameters include the CPU usage, the request response time, and the request error rate.

[0062] In some implementations, the capacity data of the service node includes the number of queries per second or the number of transactions per second of the service node during stress testing.

[0063] In a third aspect, an embodiment of the present disclosure provides a system, including:

[0064] Processor; and

[0065] A memory storing computer instructions, wherein the computer instructions are used to enable the processor to execute the method described in any embodiment of the first aspect.

[0066] In a fourth aspect, an embodiment of the present disclosure provides a storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the method according to any embodiment of the first aspect.

[0067] The system stress testing method of the disclosed embodiment can obtain more comprehensive and accurate capacity baseline parameters by integrating the performance parameters of multiple dimensions of the service nodes, and more accurately reflect the performance limits of the service nodes. In addition, the system baseline parameters of the entire system are determined by integrating the capacity baseline parameters of all service nodes on the entire link, and the system performance upper limit can be quantified more accurately, thereby obtaining accurate stress testing results, greatly reducing the risk of system capacity overload, perceiving the potential danger of system performance degradation, and improving system operation stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the prior art, the drawings required for use in the specific embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0069] Figure 1 It is a structural diagram of a system according to some embodiments of the present disclosure.

[0070] Figure 2 It is a flowchart of a system stress testing method according to some implementation modes of the present disclosure.

[0071] Figure 3 It is a schematic diagram of the principle of the system stress testing method in some implementation modes of the present disclosure.

[0072] Figure 4 It is a schematic diagram of the principle of the system stress testing method in some implementation modes of the present disclosure.

[0073] Figure 5 It is a flowchart of a system stress testing method according to some implementation modes of the present disclosure.

[0074] Figure 6 It is a flowchart of a system stress testing method according to some implementation modes of the present disclosure.

[0075] Figure 7 It is a flowchart of a system stress testing method according to some implementation modes of the present disclosure.

[0076] Figure 8 It is a flowchart of a system stress testing method according to some implementation modes of the present disclosure.

[0077] Fig. 9 It is a structural block diagram of a system stress testing device according to some implementations of the present disclosure.

[0078] Fig.10 It is a structural block diagram of a system according to some implementation modes of the present disclosure. DETAILED DESCRIPTION

[0079] The technical solution of the present disclosure will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described implementation is a part of the implementation of the present disclosure, rather than all the implementations. Based on the implementation in the present disclosure, all other implementations obtained by ordinary technicians in the field without creative work are within the scope of protection of the present disclosure. In addition, the technical features involved in the different implementations of the present disclosure described below can be combined with each other as long as they do not conflict with each other.

[0080] With the development of Internet technology, microservice systems are increasingly favored by large enterprises and development teams. The microservice system architecture can decompose a single application into multiple loosely coupled and independently deployed microservice nodes. Different microservice nodes can use different development languages, be deployed on different servers, or even span different data centers. It can be seen that microservice systems have the advantages of agile development, efficient operation, and strong scalability.

[0081] When large enterprises or large-scale activities go online, the server will receive a large number of data requests per second. If the server performance is not sufficient to support so many data requests, it will cause system capacity overload. At the very least, the application response speed will slow down, reducing the user experience. In severe cases, it may even cause the application to crash, resulting in huge losses to the platform.

[0082] To prevent system overload, it is usually necessary to stress test the system to evaluate whether the system's maximum processing capacity can meet future needs. In related technologies, a capacity baseline is generally set in advance for system capacity. The capacity baseline is strongly related to the system's CPU (Central Processing Unit) capacity. During the stress test, the CPU usage rate can be calculated in real time based on the current data request flow. For example, when the CPU usage rate exceeds 60%, it enters a "dangerous" state, so that developers can take corresponding measures to expand capacity to expand the system's maximum processing capacity.

[0083] However, this fixed capacity baseline stress testing method is neither accurate nor comprehensive, and cannot truly reflect the system's maximum processing capacity. It often happens that the CPU usage is good, but the system service is still overloaded, and online failures cannot be perceived.

[0084] Further research revealed that this is because in the microservice system architecture, not all service nodes have a strong correlation with the CPU. In fact, different service nodes have different external performances when reaching maximum performance. If a service node is a computing node, its external performance when reaching maximum performance is high CPU usage, because its main resource consumption is the CPU; if a service node is a traffic node, its external performance when reaching maximum performance is high response time (RT, Response Time), because a large number of data requests make its parallel processing capabilities reach a bottleneck, and the response time will increase; in addition, when some service nodes reach maximum performance, although the CPU usage and response time are at normal levels, the error rate of their data requests suddenly increases, which also indicates that the service node is already in a rather unstable state and has reached maximum performance.

[0085] It can be seen that the performance of different service nodes is not strongly correlated with the CPU. Therefore, in related technologies, the capacity baseline defined based on CPU capabilities often cannot fully reflect the performance of each service node in the system, so that faults cannot be perceived during the stress testing process. For example, in some scenarios, although the CPU usage of each service node is at a normal level during the stress testing process, the response time and request error rate may have reached the performance limit. The traditional stress testing method cannot perceive this fault, resulting in performance out of control when the actual platform is launched, and the probability of false alarms, missed alarms and errors is greatly increased. In severe cases, it may even cause system downtime and crash, causing huge losses to the platform.

[0086] Based on the defects of the above-mentioned related technologies, the embodiments of the present disclosure provide a system stress testing method, device, system and storage medium, which aim to comprehensively and accurately evaluate the maximum capacity of the system through multi-dimensional full-link stress testing, define a more accurate system capacity baseline, and thus obtain more comprehensive and accurate stress testing results.

[0087] Figure 1 The architecture diagram of the microservice system in some embodiments of the present disclosure is shown as follows Figure 1 As shown, the microservice system includes a front end and a back end. The front end may include a PC front end and a mobile front end. The PC front end refers to a web page deployed on a PC (Personal Computer) client, and the mobile front end refers to an application page deployed on a mobile terminal.

[0088] The backend includes multiple service nodes. Different service nodes can provide different microservices and are deployed on different servers. Figure 1 In this example, taking the online shopping program as an example, the microservices provided by the backend may include user services, product services, and order services. Each service node (SRV, Server) provides a microservice, so Figure 1 In the example, the system includes three service nodes, namely, service node SRV1, service node SRV2 and service node SRV3.

[0089] Of course, those skilled in the art will understand that Figure 1 This is only an example of the system architecture of the present disclosure. In other implementations, the system may also include a larger number of service nodes SRV, which will not be elaborated in the present disclosure.

[0090] As can be seen from the above, since different service nodes are deployed on different servers, the maximum performance of different service nodes is also different. Moreover, since the business types of different service nodes are different, the external performance when they reach the maximum performance is also different. Based on this, the system stress testing method of the embodiment of the present disclosure can comprehensively evaluate the maximum performance of each service node from multiple dimensions, and comprehensively define the system capacity baseline based on the capacity performance of all service nodes on the business line, so as to obtain a more comprehensive and accurate stress testing result. Figure 2 Provide explanation.

[0091] like Figure 2 As shown, in some embodiments, the system stress testing method of the present disclosure example includes:

[0092] S210. Obtain capacity data and performance parameters of each service node during the stress test.

[0093] Combination Figure 1As shown, during the stress test of the system, each service node SRV will receive and process a large amount of request data. For example, when the main capability of the system is to query data, the indicator corresponding to its processing capability is QPS (Queries Per Second); when the main capability of the system is to perform some complex operations, the indicator corresponding to its processing capability can be TPS (Transactions Per Second). In the embodiment of the present disclosure, the capacity data of the service node SRV during the stress test is the indicator parameter corresponding to the processing capability of the service node SRV, such as QPS, TPS, etc.

[0094] In the following implementation of the present disclosure, the processing capability index of the system and the service node SRV will be described by taking the number of queries per second (QPS) as an example.

[0095] For each service node SRV, during the stress test, as the received QPS changes, the capacity data of each service node SRV during the stress test can be obtained. The capacity data can be in the form of a QPS capacity graph. Figure 3 The figure shows the QPS capacity performance of a service node SRV during the stress test. The horizontal axis in the figure represents the stress test time period, and the vertical axis represents the QPS value. It can be seen that during the entire stress test process, the processing peak value of the service node SRV reaches 1000QPS.

[0096] In some implementations, the capacity data of each service node SRV during the stress test can be obtained through the stress test platform. The capacity data of each service node SRV can be obtained through Figure 3 The QPS capacity performance diagram shown is indicated, and this disclosure will not elaborate on this.

[0097] As can be seen from the foregoing, different service nodes SRV perform differently when reaching maximum performance. Therefore, in the embodiments of the present disclosure, the performance of the service node is not evaluated based solely on CPU performance, but rather multi-dimensional performance parameters of each service node SRV during the stress test are collected.

[0098] In some implementations, the performance parameters of the service node SRV include, but are not limited to, CPU usage, request response time, request error rate, and the like.

[0099] CPU usage refers to the CPU usage of the service node SRV, which can reflect the CPU performance of the service node SRV during the stress test. It can be understood that for some computing service nodes, when they reach maximum performance, their external performance is high CPU usage, because they mainly consume CPU resources, so the CPU usage parameter can well reflect the performance of the service node.

[0100] The request response time refers to the response time of the service node SRV processing the data request and returning the result, which can reflect the data response of the service node SRV during the stress test. It can be understood that for some traffic-type service nodes, when they reach maximum performance, the external manifestation is a high response time, because a large number of data requests make their parallel processing capabilities reach a bottleneck, and the response time increases.

[0101] In some implementations of the present disclosure, the request response time of the service node SRV can be represented by the TP99 response time, where TP99 is the 99-line response time. The 99-line response time means that if there is a group of 100 response time, after sorting from small to large, the value of the 99th response time is the TP99 value of this group of response time, indicating that at least 99% of the data requests have a response time less than or equal to this value.

[0102] The request error rate refers to the error rate of the service node SRV processing request data, which can reflect the accuracy of data processing by the service node SRV during the stress test. It can be understood that for some service nodes, when they reach maximum performance, although the CPU usage and request response time are at normal levels, the request error rate increases suddenly, which also indicates that the service node has reached maximum performance.

[0103] In some implementations of the present disclosure, the request error rate can be represented by a 5xx error rate. 5xx refers to an http protocol status code, and 5xx is also used to represent a request error. In the implementations of the present disclosure, the 5xx error rate can be counted to obtain the request error rate.

[0104] In the embodiment of the present disclosure, during the system stress test, the above performance parameters of each service node SRV can be obtained through the stress test platform. It is worth noting that in the embodiment of the present disclosure, the performance parameters of the service node SRV can include only any two of the above CPU usage, request response time, and request error rate, or can include all three categories, and the present disclosure does not limit this.

[0105] For example Figure 4 The following figure shows the performance parameters of a service node SRV during stress testing, including request error rate, request response time, and CPU usage. Figure 4 In the example, the CPU usage, request response time, and request error rate corresponding to each service node SRV can be obtained, and this disclosure will not go into details.

[0106] S220: Determine a capacity baseline parameter corresponding to the service node from the capacity data according to a comparison result of the performance parameter of each service node with a preset risk threshold of the performance parameter.

[0107] In the disclosed embodiments, it is necessary to pre-set a corresponding risk threshold for each type of performance parameter, and the risk threshold refers to the critical value at which the service node SRV reaches the maximum performance. Taking the CPU usage rate as an example of the performance parameter, a corresponding risk threshold of 50% can be pre-set for the CPU usage rate, which means that if the CPU usage rate of the service node SRV is greater than or equal to the risk threshold of 50%, it means that the CPU usage rate of the service node has reached the maximum performance. On the contrary, if the CPU usage rate of the service node SRV is always less than the risk threshold of 50%, it means that the CPU performance of the service node has been in a safe state and has not reached the maximum performance.

[0108] Based on this principle, a corresponding risk threshold can be set in advance for each type of performance parameter based on prior knowledge. In the embodiments of the present disclosure, there is no restriction on the specific value of the risk threshold, and those skilled in the art can select it according to specific scenario requirements.

[0109] In addition, it is worth noting that only one risk threshold corresponding to each type of performance parameter can be set, or two risk thresholds can be set, one of which is used as a warning threshold and the other is used as an alarm threshold, and the alarm threshold is greater than the warning threshold.

[0110] The warning threshold can only be used as a warning signal. If the performance parameter exceeds the warning threshold but does not reach the alarm threshold, it means that the service node SRV is about to have an overload risk, but has not yet reached the capacity overload situation, which plays a warning role. The alarm threshold refers to the alarm signal. If the performance parameter exceeds the alarm threshold, it means that the service node SRV has an overload problem and an alarm signal needs to be generated.

[0111] For example, in one example, the risk threshold pre-set for each type of performance parameter can be expressed as:

[0112] CPU usage, warning threshold 40%, alarm threshold 50%;

[0113] Request response time, warning threshold 300ms, alarm threshold 350ms;

[0114] Request error rate, warning threshold 0.5%, alarm threshold 1%.

[0115] Of course, those skilled in the art will understand that the above is only an example of an implementation of the present disclosure. In the specific implementation process, the specific value of the risk threshold of each type of performance parameter can be selected in combination with the scenario requirements and is not limited to the examples of the present disclosure.

[0116] In the disclosed embodiment, the performance parameters of the CPU usage, request response time and request error rate of each service node SRV during the stress test have been obtained through S210. Therefore, each type of performance parameter can be compared with the risk threshold to determine whether the service node SRV has reached the maximum performance.

[0117] For example, taking service node SRV1 as an example, the CPU usage of service node SRV1 during the stress test can be compared with the risk threshold. If the CPU usage of service node SRV1 at a certain moment is greater than or equal to the risk threshold, it means that service node SRV1 has reached maximum performance during the stress test. Similarly, the request response duration of service node SRV1 during the stress test is compared with the risk threshold. If the request response duration of service node SRV1 at a certain moment is greater than or equal to the risk threshold, it means that service node SRV1 has reached maximum performance during the stress test. Compare the request error rate of service node SRV1 during the stress test with the risk threshold. If the request error rate of service node SRV1 at a certain moment is greater than or equal to the risk threshold, it means that service node SRV1 has reached maximum performance during the stress test.

[0118] In the disclosed embodiment, among the multiple types of performance parameters corresponding to the service node SRV, as long as at least one type of performance parameter is greater than or equal to the risk threshold, it means that the service node SRV has reached the maximum performance. Conversely, if all types of performance parameters of the service node SRV are less than the risk threshold, it means that the service node SRV is in a stress test safety state.

[0119] It can be understood that for a service node SRV, if a certain type of performance parameter is greater than or equal to the risk threshold, it means that the QPS value at this moment has enabled the service node SRV to reach the maximum performance. If the QPS value continues to increase, it will exceed the maximum processing capacity of the service node SRV, causing the capacity of the service node SRV to be overloaded.

[0120] Therefore, when comparing each type of performance parameter with the risk threshold, the comparison results may show that multiple types of performance parameters have reached the risk threshold, or the same type of performance parameter may reach the risk threshold at multiple time points during the stress testing process.

[0121] In some implementations of the present disclosure, the earliest time point reaching the risk threshold may be selected from the comparison results, and then the capacity parameter corresponding to the time point in the capacity data may be determined as the capacity baseline parameter of the service node SRV.

[0122] For example, in an example, the capacity data of the service node SRV1 obtained in S210 is as follows: Figure 3 As shown, the performance parameters are as follows Figure 4As shown in the figure, it is assumed that at 11:22 the CPU usage of service node SRV1 reaches the risk threshold of 50%, and at 11:30 the request response time of service node SRV1 reaches the risk threshold of 350ms. During the entire stress test, the request error rate of service node SRV1 is lower than the risk threshold of 1%.

[0123] Therefore, in this example, it can be determined that the earliest time point at which the risk threshold is reached is 11:22, and then Figure 3 In the capacity data of the service node SRV1 shown in FIG. 1 , the capacity parameter 550QPS corresponding to 11:22 is determined as the capacity baseline parameter of the service node SRV1, that is, Figure 3 The baseline is shown in dashed line.

[0124] In the embodiments of the present disclosure, the capacity baseline parameter of the service node refers to the capacity parameter corresponding to the service node when it reaches the maximum performance, that is, the QPS value. For example, in the previous example, the capacity baseline parameter of the service node SRV1 is determined to be 550QPS, which means that when the capacity parameter received by the service node SRV1 reaches 550QPS, the service node SRV1 has reached the maximum performance. If the capacity parameter continues to increase, the service node SRV1 is likely to have a capacity overload problem. For example, when the capacity parameter of the service node SRV1 increases to 600QPS, the service node SRV1 has a capacity overload problem and is in a risky state.

[0125] In the above example, only the capacity baseline parameter determination process of the service node SRV1 is described. For other service nodes SRV in the system, the above process is repeated in sequence to obtain the capacity baseline parameters corresponding to each service node.

[0126] It can be understood that in the embodiments of the present disclosure, the capacity baseline parameters of each service node SRV are not only related to the CPU performance, but are the capacity baseline parameters obtained by integrating multiple types of performance parameters, which can reflect the actual performance of each service node and obtain more accurate and comprehensive capacity baseline parameters.

[0127] For example, in one example, during the stress test of a service node SRV, the CPU usage rate has always been at a normal level, but the request response time exceeds the risk threshold. If the traditional stress test method is used, since the CPU usage rate of the service node is always lower than the risk threshold, the service node can be misjudged as a safe state. However, in the embodiment of the present disclosure, the performance parameters of the request response time are combined, even if the CPU performance of the service node SRV is normal, it can still be detected that the request response time is in an overloaded state, thereby accurately identifying that the service node SRV is in a risky state.

[0128] For example, in another example, during the stress test of a service node SRV, the CPU usage rate has always been at a normal level, but the request error rate exceeds the risk threshold. If the traditional stress test method is used, since the CPU usage rate of the service node is always lower than the risk threshold, the service node can be misjudged as a safe state. However, in the embodiment of the present disclosure, the performance parameters of the comprehensive request error rate can still detect that the request error rate is in an overloaded state even if the CPU performance of the service node SRV is normal, thereby accurately identifying that the service node SRV is in a risky state.

[0129] It can be seen that in the embodiments of the present disclosure, the capacity baseline parameters of the service node are comprehensively quantified by multi-dimensional performance parameters, and the obtained capacity baseline parameters can more accurately reflect the maximum performance of the service node.

[0130] S230. Determine system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test.

[0131] The capacity baseline parameters corresponding to each service node SRV are obtained through the above process, which reflect the maximum performance of each service node SRV. For the entire system, in order to maintain the stable operation of the entire system, it is necessary to ensure that each service node SRV in the system cannot be overloaded, that is, each service node SRV is in a safe state.

[0132] Therefore, in the embodiment of the present disclosure, after obtaining the capacity baseline parameters of each service node SRV through the aforementioned process, it is necessary to determine the system baseline parameters of the entire system based on the capacity baseline parameters of each service node SRV. The system baseline parameters are the QPS values ​​that ensure that all service nodes SRV in the system are in a safe state.

[0133] From the foregoing, it can be seen that the capacity baseline parameter of the service node SRV represents the capacity parameter (i.e., the QPS value) corresponding to the time point at which the risk threshold is reached earliest. In the embodiment of the present disclosure, the earliest time point t can be selected from the time points corresponding to the capacity baseline parameters of each service node SRV. The earliest time point t is the time point at which the risk threshold is reached earliest among all service nodes.

[0134] In some implementations of the present disclosure, it is necessary to select a target service node from multiple service nodes included in the system in advance. The purpose of selecting the target service node is to select a service node with the highest overload risk from multiple service nodes in the system, and define the service node with the highest overload risk as the target service node. Since the target service node has the highest overload risk, the target service node is often the first to be overloaded when the system is running, which is equivalent to the node with the weakest performance in the system.

[0135] Therefore, in the embodiment of the present disclosure, after obtaining the time point t, the capacity parameter corresponding to the time point t can be determined from the capacity data of the target service node. As can be seen from the foregoing, the capacity data of the service node is Figure 3 As shown in the capacity performance graph, for the target service node, the QPS value corresponding to the time point t can be found on the capacity performance graph of the target service node, and the QPS value is determined as the system baseline parameter of the entire system.

[0136] For example, in an example, suppose the capacity data of the target service node is as follows Figure 3 As shown, the time point t is 11:22, so the corresponding QPS value is determined to be 550QPS on the capacity performance graph according to the time point t=11:22, so that the system baseline parameter can be determined to be 550QPS.

[0137] In the implementation manner of the present disclosure, the method of pre-selecting the target service node may be manually selected by a staff member, or may be automatically selected by the system during the stress testing process, which is described below in the present disclosure.

[0138] S240: Determine the stress test result of the system based on the system baseline parameters and preset flow data.

[0139] In the embodiment of the present disclosure, the system baseline parameters obtained through the above process can reflect the maximum QPS that the entire system can bear. If the QPS actually received by the system is greater than or equal to the system baseline parameters, it means that at least one service node SRV in the system may be at risk of capacity overload. If the QPS actually received by the system is lower than the system baseline parameters, it means that all service nodes SRV in the system can operate in a safe state and will not be overloaded.

[0140] Therefore, in the embodiments of the present disclosure, after the system baseline parameters are calculated, the system baseline parameters can be used as a measure of the maximum capacity of the system, thereby providing feedback to the optimization and adjustment of the system in many aspects. The functions of the system baseline parameters are described below:

[0141] 1) Guide system or service node expansion

[0142] The system baseline parameters provide a benchmark for measuring system performance. By comparing the system baseline parameters with future requirements, it can be determined whether the system or service nodes need to be expanded.

[0143] For some fixed-period online activities, such as an online promotion of a fast food brand, the preset traffic data N for a certain time period in the future can be obtained by summarizing historical experience, and then the preset traffic data N is compared with the system baseline parameters.

[0144] If the preset traffic data N exceeds the system baseline parameter, it means that the current system performance cannot support the future data volume, and it is likely that capacity overload will occur after the activity goes online, which will lead to system failure and huge losses to the platform. Therefore, appropriate measures can be taken to expand the system or some service nodes in the system to meet future needs.

[0145] 2) Guidance system optimization and adjustment

[0146] System baseline parameters provide a basis for predicting the need for system upgrades or adjustments. By detecting changes in system baseline parameters, it can be determined whether the system capacity has reached or is close to its limit, thereby determining whether the system needs to be upgraded or adjusted to support higher workloads and processing capabilities.

[0147] For example, in some implementations, when the amount of system request data is close to the system baseline parameter for a long time, it indicates that the system performance has approached the limit. At this time, relevant measures can be considered to optimize and adjust the system performance.

[0148] For example, in some other implementations, during multiple stress tests, the system baseline parameters show a downward trend over time, which indicates that the system performance is declining or requires maintenance. At this time, relevant measures can be considered to optimize and adjust the system performance.

[0149] From the above, we can see that system baseline parameters are of great significance for system performance quantification, system expansion guidance, and system maintenance and tuning. Therefore, relatively more accurate system baseline parameters are urgently needed parameter indicators for system stress testing.

[0150] In the embodiments of the present disclosure, by integrating the performance parameters of multiple dimensions of the service nodes, more comprehensive and accurate capacity baseline parameters can be obtained, which more accurately reflect the performance limits of the service nodes. In addition, by integrating the capacity baseline parameters of all service nodes on the entire link to determine the system baseline parameters of the entire system, the system performance upper limit can be quantified more accurately, thereby obtaining accurate stress testing results, greatly reducing the risk of system capacity overload, perceiving the potential danger of reduced system performance, and improving system operation stability.

[0151] like Figure 5 As shown, in some embodiments, the system stress testing method of the present disclosure example, the process of determining the capacity baseline parameter corresponding to each service node SRV includes:

[0152] S221. Compare each type of performance parameter of each service node with its corresponding risk threshold, and record the time point when each type of performance parameter reaches the risk threshold according to the comparison result.

[0153] S222. Determine the earliest first target time point from the time points corresponding to each type of performance parameter, and determine the capacity parameter corresponding to the first target time point in the capacity data as the capacity baseline parameter of the service node.

[0154] In some implementations of the present disclosure, the capacity data and performance parameters of each service node SRV in the system during the stress test may be obtained through the aforementioned S210 process.

[0155] Take one of the service nodes SRV as an example. Assume that the capacity data of the service node SRV is as follows: Figure 3 As shown in the figure, the performance parameters include request error rate, request response time and CPU usage. Figure 4 As shown, the process of determining the capacity baseline parameters of the service node SRV is described below.

[0156] In the example of the present disclosure, the risk threshold pre-set for each type of performance parameter can be expressed as:

[0157] CPU usage, risk threshold 50%;

[0158] Request response time, risk threshold 350ms;

[0159] Request error rate, risk threshold 1%.

[0160] For the service node SRV, its CPU usage is compared with the risk threshold of 50% in the above example. If the CPU usage is greater than or equal to the risk threshold of 50% at a certain moment, this time point can be recorded. For example, in an example, the CPU usage of the service node SRV reaches the risk threshold of 50% at 11:22, and the time point 11:22 can be recorded.

[0161] At the same time, the request response time is compared with the risk threshold of 350ms in the above example. If the request response time at a certain moment is greater than or equal to the risk threshold of 350ms, this time point can be recorded. For example, in an example, the request response time of the service node SRV reaches the risk threshold of 350ms at 11:55, and the time point 11:55 can be recorded.

[0162] Similarly, compare its request error rate with the risk threshold of 1% in the above example. If the request error rate at a certain moment is greater than or equal to the risk threshold of 1%, this time point can be recorded. For example, in an example, the request error rate of the service node SRV is always lower than 1% during the entire stress test, so there is no recorded time point.

[0163] For the service node SRV, the time points when each type of performance parameter reaches the risk threshold have been recorded, namely, the time point 11:22 when the CPU usage reaches the risk threshold of 50%, and the time point 11:55 when the request response time reaches the risk threshold of 350ms. Since the request error rate is always lower than the risk threshold, no time point is recorded.

[0164] In addition, it can be understood that for each type of performance parameter, it may be greater than or equal to the risk threshold at multiple time points. In the embodiments of the present disclosure, all time points greater than or equal to the risk threshold can be recorded, or only the first time point greater than or equal to the risk threshold can be recorded. Both do not affect subsequent calculations, so the present disclosure does not impose any restrictions on this.

[0165] For the service node SRV, its CPU usage reaches the risk threshold at time point 11:22, and its request response time reaches the risk threshold at time point 11:55, indicating that its capacity is overloaded at both time points 11:22 and 11:55.

[0166] In the disclosed embodiment, it is necessary to select the earliest time point from the time points where capacity overload occurs as the first target time point. For example, in the above example, since the time point 11:22 is earlier than the time point 11:55, the time point 11:22 is determined as the first target time point.

[0167] It can be understood that for the service node SRV, its capacity overload situation has occurred at the time point 11:22, so its subsequent process may have been running in a risky state. Therefore, in the embodiment of the present disclosure, the time point when the capacity overload situation first occurs needs to be used as the first target time point.

[0168] After determining the first target time point 11:22, you can Figure 3 The capacity parameter corresponding to the first target time point 11:22, that is, the QPS value, is determined in the capacity data of the service node SRV shown. Figure 3 It can be seen that the QPS value corresponding to the first target time point 11:22 is 550QPS, so 550QPS can be determined as the capacity baseline parameter of the service node SRV. The capacity baseline parameter can be found in Figure 3 The capacity data shown is indicated by a dotted line.

[0169] For the service node SRV, the obtained capacity baseline parameter can be understood as follows: at the time point 11:22, the QPS value corresponding to the service node SRV reaches 550, and at this time, the service node SRV has reached the performance limit.

[0170] The above only illustrates the process of determining the capacity baseline parameters of one service node SRV. For other service nodes SRV included in the system, it is only necessary to repeat the above method process to obtain the capacity baseline parameters corresponding to each service node SRV.

[0171] It can be seen from the above that in the embodiments of the present disclosure, the capacity baseline parameters of the service node are comprehensively quantified by multi-dimensional performance parameters, and the obtained capacity baseline parameters can more accurately reflect the maximum performance of the service node.

[0172] like Figure 6 As shown, in some embodiments, the system stress testing method of the present disclosure example, the process of determining the system baseline parameters includes:

[0173] S231. Determine a target service node from multiple service nodes.

[0174] Based on the foregoing, it can be known that the target service node refers to a service node with the highest overload risk selected from multiple service nodes SRV included in the system.

[0175] In some implementations, the process of determining the target service node from a plurality of service nodes in the system may include: determining the target service node from a plurality of service nodes based on a user operation instruction.

[0176] That is, the target service node can be manually selected by the staff. For example, in one example, the staff can select a service node with poor capacity performance from multiple service nodes in the entire system based on prior knowledge. After receiving the user's operation instruction to select a service node, the system determines the service node selected by the user as the target service node based on the operation instruction.

[0177] In some other implementations, the process of determining a target service node from a plurality of service nodes in the system may include: based on capacity data of each service node, determining a service node with a highest capacity parameter peak as the target service node.

[0178] It can be understood that the target service node refers to the service node with the highest risk of capacity overload, which often means that the QPS peak value of this service node is the highest. Therefore, in the embodiment of the present disclosure, the capacity data of all service nodes can be counted, and the service node with the highest capacity parameter (i.e., QPS) peak value can be determined as the target service node.

[0179] Of course, those skilled in the art will understand that the above are only two exemplary implementations of the present disclosure. In other implementations, the target service node may be determined based on other methods. For example, the service node that reaches the risk threshold the earliest may be selected as the target service node. The present disclosure will not elaborate on this.

[0180] S232: Determine the earliest second target time point based on the first target time point corresponding to the capacity baseline parameter of each service node.

[0181] Through the aforementioned Figure 5 In the implementation mode, the capacity baseline parameter corresponding to each service node SRV has been obtained, and the capacity baseline parameter of each service node SRV corresponds to a first target time point, for example Figure 5 In the example of implementation mode, the capacity baseline parameter of the service node SRV is 550QPS, and the corresponding first target time point is 11:22.

[0182] In the embodiment of the present disclosure, the first target time points corresponding to the capacity baseline parameters of all service nodes SRV can be compared, and the earliest time point can be selected as the second target time point. Figure 1 As shown, the system includes 3 service nodes, and their respective capacity baseline parameters, i.e., the first target time points, are as shown in the following table 1:

[0183] Table 1

[0184] Service Node Capacity baseline parameters First target time point SRV1 550QPS 11:22 SRV2 675QPS 12:50 SRV3 620QPS 12:35

[0185] In the disclosed example, by comparing the first target time point of each service node, it can be determined that the earliest time point 11:22 is the second target time point.

[0186] S233: Determine the capacity parameter corresponding to the second target time point in the capacity data of the target service node as the system baseline parameter.

[0187] In the embodiment of the present disclosure, the target service node has been determined from multiple service nodes SRV through the aforementioned S231. In the present disclosure example, it is assumed that the determined target service node is SRV1, and its corresponding capacity data is Figure 3 The QPS capacity performance graph is shown.

[0188] The second target time point 11:22 is obtained by the aforementioned S232, and then the corresponding capacity parameter is found from the capacity data of the target service node SRV2 using the second target time point 11:22. Figure 3 In the capacity performance diagram of the target service node SRV2 shown, it is determined that the capacity parameter corresponding to 11:22 is 550QPS, so 550QPS can be determined as the system baseline parameter of the entire system.

[0189] From the above, it can be seen that in the embodiments of the present disclosure, by integrating the performance parameters of multiple dimensions of the service nodes, more comprehensive and accurate capacity baseline parameters can be obtained, which more accurately reflect the performance limits of the service nodes. In addition, the capacity baseline parameters of all service nodes on the entire link are integrated to determine the system baseline parameters of the entire system, which can more accurately quantify the system performance upper limit, thereby obtaining accurate stress testing results, greatly reducing the risk of system capacity overload, perceiving the potential danger of reduced system performance, and improving system operation stability.

[0190] In the above implementation, only one risk threshold is set for each type of performance parameter, such as a risk threshold of 50% for CPU usage, a risk threshold of 350ms for request response time, and a risk threshold of 1% for request error rate. In other implementations, two risk thresholds can also be set, one as a warning threshold and the other as an alarm threshold. If the alarm threshold is greater than the warning threshold, Figure 7 and Figure 8 The implementation method is described.

[0191] like Figure 7 As shown, in some embodiments, the system stress testing method of the present disclosure example, the process of determining the capacity baseline parameters of each service node SRV includes:

[0192] S710. For each type of performance parameter, in response to the performance parameter being greater than or equal to its corresponding warning threshold, record a first time point; in response to the performance parameter being greater than or equal to its corresponding alarm threshold, record a second time point.

[0193] In the disclosed embodiment, the risk threshold corresponding to each type of performance parameter includes a warning threshold and an alarm threshold. The warning threshold can only be used as a warning signal. If the performance parameter exceeds the warning threshold but does not reach the alarm threshold, it means that the service node SRV is about to have an overload risk, but has not yet reached the capacity overload situation, which plays a warning role. The alarm threshold refers to an alarm signal. If the performance parameter exceeds the alarm threshold, it means that the service node SRV has an overload problem and an alarm signal needs to be generated.

[0194] For example, in one example, the risk threshold pre-set for each type of performance parameter can be expressed as:

[0195] CPU usage, warning threshold 40%, alarm threshold 50%;

[0196] Request response time, warning threshold 300ms, alarm threshold 350ms;

[0197] Request error rate, warning threshold 0.5%, alarm threshold 1%.

[0198] Therefore, in the example of this disclosure, taking one of the service nodes SRV as an example, assuming that the capacity data of the service node SRV is as follows Figure 3 As shown in the figure, the performance parameters include request error rate, request response time and CPU usage. Figure 4 As shown, the process of determining the capacity baseline parameters of the service node SRV is described below.

[0199] For the service node SRV, its CPU usage is compared with the warning threshold of 40% in the above example. If the CPU usage reaches the warning threshold of 40% at a certain moment, the first time point can be recorded. For example, in an example, the CPU usage of the service node SRV reaches the warning threshold of 40% at 11:18, and the first time point 11:18 can be recorded.

[0200] The CPU usage is compared with the alarm threshold of 50% in the above example. If the CPU usage reaches the alarm threshold of 50% at a certain moment, the second time point can be recorded. For example, in an example, the CPU usage of the service node SRV reaches the alarm threshold of 50% at 11:22, and the second time point 11:22 can be recorded.

[0201] Similarly, the request response time is compared with the warning threshold of 300ms in the above example. If the request response time reaches the warning threshold of 300ms at a certain moment, the first time point can be recorded. For example, in one example, the request response time of the service node SRV reaches the warning threshold of 300ms at 11:48, and the first time point 11:48 can be recorded.

[0202] The request response time is compared with the alarm threshold of 350ms in the above example. If the request response time reaches the alarm threshold of 350ms at a certain moment, the second time point can be recorded. For example, in an example, the request response time of the service node SRV reaches the alarm threshold of 350ms at 11:55, and the second time point 11:55 can be recorded.

[0203] Similarly, compare its request error rate with the warning threshold of 0.5% in the above example. If the request error rate reaches the risk threshold of 0.5% at a certain moment, this first time point can be recorded. For example, in one example, the request error rate of the service node SRV is always lower than 1% during the entire stress test process, so there is no record of the first time point. It can be understood that since the request error rate is always lower than the warning threshold of 0.5%, it is also lower than the alarm threshold of 1%, and there is no record of the second time point.

[0204] S720. Determine the earliest third time point from the first time points corresponding to the various performance parameters, and determine the capacity parameter corresponding to the third time point in the capacity data as the security baseline parameter of the service node.

[0205] S730. Determine the earliest fourth time point from the second time points corresponding to the various performance parameters, and determine the capacity parameter corresponding to the fourth time point in the capacity data as the warning baseline parameter of the service node.

[0206] Through the above-mentioned S710 example, the first time point and the second time point corresponding to each type of performance parameter of the service node SRV are obtained, which can be shown in the following Table 2:

[0207] Table 2

[0208] First time point Second time point CPU usage 11:18 11:22 Request response time 11:48 11:55 Request Error Rate — —

[0209] For the service node SRV, the earliest time point can be selected from the first time points corresponding to each type of performance parameter as the third time point. For example, in the example of Table 2, 11:18 is the earliest time point in the first time points, that is, the third time point 11:18. Similarly, the earliest time point can be selected from the second time points corresponding to each type of performance parameter as the fourth time point. For example, in the example of Table 2, 11:22 is the earliest time point in the second time points, that is, the fourth time point 11:22.

[0210] After determining the third time point 11:18 and the fourth time point 11:22, Figure 3 The corresponding capacity parameter, i.e., the QPS value, is determined from the capacity data of the service node SRV shown. Figure 3 As shown, the capacity parameter corresponding to the third time point 11:18 is 500QPS, so the safety baseline parameter of the service node SRV is 500QPS. The capacity parameter corresponding to the fourth time point 11:22 is 550QPS, so the warning baseline parameter of the service node SRV is 550QPS.

[0211] It can be understood that for the safety baseline parameter 500QPS and the warning baseline parameter 550QPS of the service node, if the QPS value at a certain moment is less than the safety baseline parameter 500QPS, it means that the service node SRV is in a safe state. If the QPS value at a certain moment is greater than or equal to the safety baseline parameter 500QPS, but less than the warning baseline parameter 550QPS, it means that the service node SRV is approaching the performance limit and needs to enter the early warning state. If the QPS value at a certain moment is greater than or equal to the warning baseline parameter 550QPS, it means that the service node SRV has entered a risky state and a capacity overload has occurred.

[0212] From the above, it can be seen that in the embodiments of the present disclosure, by further subdividing the capacity baseline parameters into safety baseline parameters and warning baseline parameters, the performance of the service nodes can be better monitored, risks can be perceived in a timely manner, and the system stress testing effect can be improved.

[0213] like Figure 8 As shown, in some embodiments, the system stress testing method of the present disclosure example, the process of determining the system baseline parameters includes:

[0214] S810. Determine the earliest third time point according to the third time points corresponding to the security baseline parameters of each service node, and determine the capacity parameter corresponding to the earliest third time point in the capacity data of the target service node as the system security baseline parameter.

[0215] S820. Determine the earliest fourth time point according to the fourth time points corresponding to the alert baseline parameters of the respective service nodes, and determine the capacity parameter corresponding to the earliest fourth time point in the capacity data of the target service node as the system alert baseline parameter.

[0216] In the implementation manner of the present disclosure, it is also necessary to determine the target service node from multiple service nodes in advance. Those skilled in the art may refer to the aforementioned S231 process, which will not be described in detail.

[0217] In one example, combining Figure 1 As shown, it is assumed that the system includes 3 service nodes in total, and SRV1 is determined as the target service node from the 3 service nodes. The capacity data corresponding to the target service node SRV1 is as follows: Figure 3 shown.

[0218] In this example, through the above Figure 7 In the implementation mode, the security baseline parameters and the corresponding third time point, as well as the warning baseline parameters and the corresponding fourth time point corresponding to each service node SRV have been obtained. For example, in one example, the security baseline parameters and the third time point, as well as the warning baseline parameters and the fourth time point of each service node can be shown in the following Table 3:

[0219] Table 3

[0220] Service Node Security baseline parameters The third time point Alert baseline parameters Fourth time point SRV1 500QPS 11:18 550QPS 11:22 SRV2 600QPS 12:05 675QPS 12:50 SRV3 550QPS 11:40 620QPS 12:35

[0221] In the embodiment of the present disclosure, the earliest third time point can be determined from the third time point corresponding to each service node. For example, in Table 3 above, the earliest third time point is 11:18, and then the capacity data of the target service node SRV1 (for example Figure 3 As shown in FIG. 1 , the capacity parameter corresponding to the earliest third time point 11:18 is found to be 500QPS, thereby determining that the system safety baseline parameter of the entire system is 500QPS.

[0222] Similarly, the earliest fourth time point can be determined from the fourth time point corresponding to each service node. For example, in Table 3 above, the earliest fourth time point is 11:22, and then the capacity data of the target service node SRV1 (for example Figure 3 As shown in FIG. 1 , the capacity parameter corresponding to the earliest fourth time point 11:22 is found to be 550QPS, thereby determining that the system alert baseline parameter of the entire system is 550QPS.

[0223] Through the above process, the system safety baseline parameter 500QPS and the system warning baseline parameter 550QPS can be obtained.

[0224] In some implementations, after obtaining the system safety baseline parameters, ie, the system alert baseline parameters, the stress test results of the current system can be determined based on preset traffic data for a certain period of time in the future to determine whether the current system capabilities meet future needs.

[0225] For example, in the previous example, by summarizing historical experience, we can get the preset traffic data N for a certain time period in the future, and then compare the preset traffic data N with the system safety baseline parameter 500QPS and the system warning baseline parameter 550QPS.

[0226] If the preset traffic data N is less than the system security baseline parameter of 500QPS, it means that the current system performance is in a safe state and can fully meet the access requirements of the preset traffic data N in the future period. If the preset traffic data N is greater than or equal to the system security baseline parameter of 500QPS, but less than the system warning baseline parameter of 550QPS, it means that the current system performance is in a risky state, and the access requirements of the preset traffic data N in the future period are close to the system performance limit. Appropriate measures can be taken to optimize, adjust or expand the system. If the preset traffic data N is greater than or equal to the system warning baseline parameter of 550QPS, it means that the current system performance is in a state of waiting for expansion, and the access requirements of the preset traffic data N in the future period have exceeded the system performance limit. Appropriate measures must be taken to expand the system or some service nodes to meet future needs.

[0227] As for the specific process of optimizing, adjusting, and expanding the capacity of the system or service node, those skilled in the art may understand and fully implement it by referring to the relevant technology, and the present disclosure will not elaborate on it.

[0228] From the above, it can be seen that in the embodiments of the present disclosure, by integrating the performance parameters of multiple dimensions of the service nodes, a more comprehensive and accurate capacity baseline parameter can be obtained, which more accurately reflects the performance limit of the service node, and the system baseline parameters of the entire system are determined by integrating the capacity baseline parameters of all service nodes on the entire link, which can more accurately quantify the upper limit of system performance, thereby obtaining accurate stress testing results, greatly reducing the risk of system capacity overload, perceiving the potential danger of reduced system performance, and improving system operation stability. In addition, by further subdividing the system baseline parameters into system safety baseline parameters and system alert safety parameters, the system performance can be better monitored, risks can be perceived in a timely manner, and the system stress testing effect can be improved.

[0229] In some embodiments, the present disclosure provides a system stress testing device, such as Fig. 9 As shown, the system stress testing device of the example of the present disclosure includes:

[0230] The acquisition module 10 is configured to acquire capacity data and performance parameters of each service node during the stress test, wherein the performance parameters include two or more types of parameters;

[0231] The node baseline module 20 is configured to determine the capacity baseline parameter corresponding to each of the service nodes from the capacity data according to the comparison result of the performance parameter of each of the service nodes with the risk threshold of the preset performance parameter;

[0232] The system baseline module 30 is configured to determine the system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test;

[0233] The result determination module 40 is configured to determine the stress test result of the system based on the system baseline parameters and preset flow data.

[0234] From the above, it can be seen that in the embodiments of the present disclosure, by integrating the performance parameters of multiple dimensions of the service nodes, more comprehensive and accurate capacity baseline parameters can be obtained, which more accurately reflect the performance limits of the service nodes. In addition, the capacity baseline parameters of all service nodes on the entire link are integrated to determine the system baseline parameters of the entire system, which can more accurately quantify the system performance upper limit, thereby obtaining accurate stress testing results, greatly reducing the risk of system capacity overload, perceiving the potential danger of reduced system performance, and improving system operation stability.

[0235] In some embodiments, the node baseline module 20 is configured to:

[0236] Compare each type of performance parameter of each of the service nodes with its corresponding risk threshold, and record the time point when each type of performance parameter reaches the risk threshold according to the comparison result;

[0237] A first target time point with the earliest time is determined from the time points corresponding to each type of performance parameter, and a capacity parameter corresponding to the first target time point in the capacity data is determined as a capacity baseline parameter of the service node.

[0238] It can be seen from the above that in the embodiments of the present disclosure, the capacity baseline parameters of the service node are comprehensively quantified by multi-dimensional performance parameters, and the obtained capacity baseline parameters can more accurately reflect the maximum performance of the service node.

[0239] In some embodiments, the system baseline module 30 is configured to:

[0240] Determine a target service node from multiple service nodes;

[0241] Determine the earliest second target time point based on the first target time point corresponding to the capacity baseline parameter of each service node;

[0242] The capacity parameter corresponding to the second target time point in the capacity data of the target service node is determined as the system baseline parameter.

[0243] From the above, it can be seen that in the embodiments of the present disclosure, by integrating the performance parameters of multiple dimensions of the service nodes, more comprehensive and accurate capacity baseline parameters can be obtained, which more accurately reflect the performance limits of the service nodes. In addition, the capacity baseline parameters of all service nodes on the entire link are integrated to determine the system baseline parameters of the entire system, which can more accurately quantify the system performance upper limit, thereby obtaining accurate stress testing results, greatly reducing the risk of system capacity overload, perceiving the potential danger of reduced system performance, and improving system operation stability.

[0244] In some implementations, the risk threshold of each performance parameter includes a warning threshold and an alarm threshold, and the alarm threshold is greater than the warning threshold; the node baseline module 20 is configured as follows:

[0245] For each type of performance parameter, in response to the performance parameter being greater than or equal to its corresponding warning threshold, record a first time point, determine a third time point with the earliest time from the first time points corresponding to each type of performance parameter, and determine the capacity parameter corresponding to the third time point in the capacity data as the security baseline parameter of the service node;

[0246] and / or,

[0247] In response to the performance parameter being greater than or equal to its corresponding alarm threshold, a second time point is recorded, a fourth time point with the earliest time is determined from the second time points corresponding to each type of performance parameter, and the capacity parameter corresponding to the fourth time point in the capacity data is determined as the warning baseline parameter of the service node, and the capacity baseline parameter includes the safety baseline parameter and the warning baseline parameter.

[0248] From the above, it can be seen that in the embodiments of the present disclosure, by further subdividing the capacity baseline parameters into safety baseline parameters and warning baseline parameters, the performance of the service nodes can be better monitored, risks can be perceived in a timely manner, and the system stress testing effect can be improved.

[0249] In some embodiments, the system baseline module 30 is configured to:

[0250] Determine the earliest third time point according to the third time points corresponding to the security baseline parameters of each service node, and determine the capacity parameter corresponding to the earliest third time point in the capacity data of the target service node as the system security baseline parameter;

[0251] The earliest fourth time point is determined according to the fourth time point corresponding to the warning baseline parameters of each service node, and the capacity parameters corresponding to the earliest fourth time point in the capacity data of the target service node are determined as the system warning baseline parameters. The system baseline parameters include system security baseline parameters and system warning baseline parameters.

[0252] From the above, it can be seen that in the embodiments of the present disclosure, by further subdividing the system baseline parameters into system safety baseline parameters and system alert safety parameters, the system performance can be better monitored, risks can be perceived in a timely manner, and the system stress testing effect can be improved.

[0253] In some embodiments, the system baseline module 30 is configured to:

[0254] Determine a target service node from a plurality of service nodes based on a user operation instruction;

[0255] or,

[0256] Based on the capacity data of each service node, the service node with the highest capacity parameter peak is determined as the target service node.

[0257] In some embodiments, the system baseline parameters include system safety baseline parameters and system alert baseline parameters; the result determination module 40 is configured to:

[0258] In response to the preset flow data being less than the system safety baseline parameter, determining that the system stress test result is in a safe state;

[0259] In response to the preset flow data being greater than or equal to the system safety baseline parameter and less than the system warning baseline parameter, determining that the system stress test result is in a risk state;

[0260] In response to the preset flow data being greater than or equal to the system warning baseline parameter, it is determined that the system stress test result is in a state to be expanded.

[0261] In some embodiments, the performance parameters include CPU usage, request response time, and request error rate;

[0262] and / or,

[0263] The capacity data of a service node includes the number of queries per second or the number of transactions per second during the stress test.

[0264] From the above, it can be seen that in the embodiments of the present disclosure, by integrating the performance parameters of multiple dimensions of the service nodes, more comprehensive and accurate capacity baseline parameters can be obtained, which more accurately reflect the performance limits of the service nodes. In addition, the capacity baseline parameters of all service nodes on the entire link are integrated to determine the system baseline parameters of the entire system, which can more accurately quantify the system performance upper limit, thereby obtaining accurate stress testing results, greatly reducing the risk of system capacity overload, perceiving the potential danger of reduced system performance, and improving system operation stability.

[0265] In some embodiments, the present disclosure provides a system, which can be, for example, Figure 1 The microservice system shown includes:

[0266] Processor; and

[0267] The memory stores computer instructions, where the computer instructions are used to enable the processor to execute the method of any of the above embodiments.

[0268] In some embodiments, the present disclosure provides a storage medium storing computer instructions, where the computer instructions are used to enable a computer to execute the method of any of the above embodiments.

[0269] Specifically, Fig.10 A schematic diagram of a system 600 suitable for implementing the method of the present disclosure is shown. Fig.10 The system shown can realize the corresponding functions of the above-mentioned processor and storage medium.

[0270] like Fig.10As shown, the system 600 includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a memory 602 or a program loaded from a storage part 608 into the memory 602. Various programs and data required for the operation of the system 600 are also stored in the memory 602. The processor 601 and the memory 602 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0271] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0272] In particular, according to an embodiment of the present disclosure, the above method process can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program tangibly contained on a machine-readable medium, and the computer program includes a program code for executing the above method. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 609, and / or installed from a removable medium 611.

[0273] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and a module, a program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0274] Obviously, the above embodiments are merely examples for the purpose of clear explanation, and are not intended to limit the embodiments. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the embodiments here. The obvious changes or modifications derived therefrom are still within the scope of protection of the present invention.

Claims

1. A system stress testing method, characterized in that: The system includes a plurality of service nodes, and the method includes: Acquire capacity data and performance parameters of each service node during the stress test, where the performance parameters include two or more types of parameters; Determining a capacity baseline parameter corresponding to each of the service nodes from the capacity data according to a comparison result between the performance parameter of each of the service nodes and a preset risk threshold of the performance parameter; Determine the system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test; The stress test result of the system is determined based on the system baseline parameters and preset flow data.

2. The method according to claim 1, characterized in that The determining, from the capacity data, a capacity baseline parameter corresponding to the service node according to a comparison result between the performance parameter of each service node and a preset risk threshold value of the performance parameter includes: Compare each type of performance parameter of each of the service nodes with its corresponding risk threshold, and record the time point when each type of performance parameter reaches the risk threshold according to the comparison result; A first target time point with the earliest time is determined from the time points corresponding to each type of performance parameter, and a capacity parameter corresponding to the first target time point in the capacity data is determined as a capacity baseline parameter of the service node.

3. The method according to claim 2, characterized in that The determining of the system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test process includes: Determine a target service node from the plurality of service nodes; Determine the earliest second target time point based on the first target time point corresponding to the capacity baseline parameter of each service node; The capacity parameter corresponding to the second target time point in the capacity data of the target service node is determined as the system baseline parameter.

4. The method according to claim 1, characterized in that: The risk threshold of each performance parameter includes a warning threshold and an alarm threshold, and the alarm threshold is greater than the warning threshold; the determining the capacity baseline parameter corresponding to each service node from the capacity data according to the comparison result of the performance parameter of each service node with the preset risk threshold of the performance parameter includes: For each type of performance parameter, in response to the performance parameter being greater than or equal to its corresponding warning threshold, a first time point is recorded, and the earliest third time point is determined from the first time points corresponding to each type of performance parameter, and the capacity parameter corresponding to the third time point in the capacity data is determined as the safety baseline parameter of the service node; and / or, in response to the performance parameter being greater than or equal to its corresponding alarm threshold, a second time point is recorded, and the earliest fourth time point is determined from the second time points corresponding to each type of performance parameter, and the capacity parameter corresponding to the fourth time point in the capacity data is determined as the warning baseline parameter of the service node, and the capacity baseline parameter includes the safety baseline parameter and the warning baseline parameter.

5. The method according to claim 4, characterized in that The determining of the system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test process includes: Determine the earliest third time point according to the third time points corresponding to the security baseline parameters of each service node, and determine the capacity parameter corresponding to the earliest third time point in the capacity data of the target service node as the system security baseline parameter; The earliest fourth time point is determined according to the fourth time point corresponding to the alert baseline parameters of each service node, and the capacity parameter corresponding to the earliest fourth time point in the capacity data of the target service node is determined as the system alert baseline parameter, and the system baseline parameter includes the system safety baseline parameter and the system alert baseline parameter.

6. The method according to claim 3, characterized in that The determining a target service node from the multiple service nodes includes: Determining the target service node from the plurality of service nodes based on a user operation instruction; or, Based on the capacity data of each service node, a service node with the highest capacity parameter peak is determined as the target service node.

7. The method according to any one of claims 1 to 6, characterized in that: The system baseline parameters include the system safety baseline parameters and the system alert baseline parameters; the stress test results of the system determined based on the system baseline parameters and preset flow data include: In response to the preset flow data being less than the system safety baseline parameter, determining that the stress test result of the system is in a safe state; In response to the preset flow data being greater than or equal to the system safety baseline parameter and less than the system warning baseline parameter, determining that the stress test result of the system is in a risk state; In response to the preset flow data being greater than or equal to the system warning baseline parameter, it is determined that the stress test result of the system is in a state to be expanded.

8. A system stress testing device, characterized in that: include: An acquisition module is configured to acquire capacity data and performance parameters of each service node during the stress test, wherein the performance parameters include two or more types of parameters; A node baseline module is configured to determine a capacity baseline parameter corresponding to each of the service nodes from the capacity data according to a comparison result of a performance parameter of each of the service nodes with a preset risk threshold of the performance parameter; A system baseline module is configured to determine system baseline parameters according to the capacity baseline parameters of each service node and the capacity data of the target service node during the stress test; The result determination module is configured to determine the stress test result of the system based on the system baseline parameters and preset flow data.

9. A system, characterized in that: include: processor; and A memory storing computer instructions, wherein the computer instructions are used to enable the processor to execute the method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: Computer instructions are stored, and the computer instructions are used to make a computer execute the method according to any one of claims 1 to 7.

Images