Performance index generation method, device and equipment and computer readable storage medium

Abstract

The embodiment of the invention relates to the technical field of performance testing, and discloses a performance index generation method, device and equipment and a computer readable storage medium, and the method comprises the steps: determining a back-end service list under the condition of obtaining a performance index request; and determining interface information according to the back-end service list, querying a calling interface corresponding to the monitoring service and a calling interface corresponding to the log service from the interface information, and obtaining performance indexes based on the calling interface corresponding to the monitoring service and the calling interface corresponding to the log service, thereby generating a performance index table according to the obtained performance indexes. According to the technical scheme, the accuracy of the performance indexes is effectively improved, it is ensured that the performance indexes can be adjusted according to the real-time test scene, and the performance indexes of the performance test are directly determined without manual intervention.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of performance testing technology, specifically to a method, apparatus, device, and computer-readable storage medium for generating performance indicators. Background Technology

[0002] The current performance testing process relies on manual intervention to query interfaces and manually set interface performance metrics, resulting in a lack of analysis of the actual situation. Furthermore, because manual intervention cannot be adjusted in a timely manner according to the test scenario, the effectiveness of performance testing is poor. Summary of the Invention

[0003] In view of the above problems, embodiments of the present invention provide a method, apparatus, device and computer-readable storage medium for generating performance indicators, which solves the problem that the effectiveness of performance indicators is poor due to the manual intervention in determining performance indicators in the prior art.

[0004] According to one aspect of the present invention, a method for generating performance indicators is provided, the method comprising: In the case of a request to obtain performance metrics, determine the list of backend services; Determine the interface information based on the backend service list; Performance metrics are obtained based on the calling interfaces corresponding to the monitoring service and the logging service found in the interface information. A performance index table is generated based on the aforementioned performance indexes.

[0005] According to another aspect of the present invention, a performance index generation apparatus is provided, comprising: The service determination module is used to determine the list of backend services when a performance metric request is received. An interface determination module is used to determine interface information based on the backend service list; The interface call module is used to query the call interface corresponding to the monitoring service and the call interface corresponding to the log service from the interface information. The metrics acquisition module is used to acquire performance metrics based on the call interfaces corresponding to the monitoring service and the log service. The indicator determination module is used to generate a performance indicator table based on the performance indicators.

[0006] According to another aspect of the present invention, a performance indicator generation device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform the operation of the performance metric generation method described above.

[0007] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction that causes a performance indicator generating device / apparatus to perform the operation of the performance indicator generating method described above.

[0008] This invention, upon receiving a performance metric request, determines a list of backend services; based on this list, it identifies interface information, queries the corresponding API calls for the monitoring service and the logging service, and obtains performance metrics based on these API calls. A performance metric table is then generated from the obtained metrics. This avoids the problem of poor performance metric validity caused by manual intervention, effectively improving the accuracy of performance metrics and ensuring that they can be adjusted according to real-time testing scenarios. Performance metrics for performance testing are determined directly without manual intervention.

[0009] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0010] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a first embodiment of the performance index generation method provided by the present invention is shown. Figure 2 A flowchart illustrating a second embodiment of the performance metric generation method provided by the present invention is shown. Figure 3 A database design schematic diagram of a second embodiment of the performance metric generation method provided by the present invention is shown; Figure 4 A flowchart illustrating a third embodiment of the performance index generation method provided by the present invention is shown; Figure 5 A schematic diagram of the index generation process of a third embodiment of the performance index generation method provided by the present invention is shown; Figure 6 A schematic diagram of the structure of a first embodiment of the performance index generation device provided by the present invention is shown; Figure 7 A schematic diagram of an embodiment of the performance index generation device provided by the present invention is shown. Detailed Implementation

[0011] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0012] Figure 1 A flowchart of a first embodiment of the performance metric generation method of the present invention is shown, the method being executed by a performance metric generation device. Figure 1 As shown, the method includes the following steps: Step 10: In the case of obtaining performance metrics requests, determine the list of backend services.

[0013] Among them, the performance metric request can be a performance metric request generated based on the performance test request in the performance test scenario. When the performance metric request is triggered, the API of Apisix is ​​automatically accessed to query all UpStreams, find all backend services and generate a list of backend services.

[0014] In one implementation, the backend service list includes a list of backend services that need to be monitored. By dynamically obtaining the backend service list, there is no need to manually maintain the service list, and the currently running service instances can be automatically identified.

[0015] For example, when requesting performance metrics, the APISIX gateway's Admin API is called to query all upstream service configurations, determine all backend services that need to be monitored, and generate a list of backend services.

[0016] Step 20: Determine the interface information based on the backend service list.

[0017] The interface information consists of the definition information of all API interfaces for each backend service. By iterating through the service list obtained in the first step, the Swagger documentation interface provided by each service is accessed, the Swagger documentation is parsed, and the service name, method, definition path, and corresponding matching expression for each interface are extracted. The interface information is then determined based on the service name, method, definition path, and corresponding matching expression for each interface.

[0018] In one implementation, after obtaining the list of backend services, the system accesses the Swagger documentation for each service. Swagger provides a structured description of the API, clearly listing all available interfaces, request methods, paths, and parameters. By parsing this information, the system can automatically understand all the interfaces exposed by each service.

[0019] In one implementation, step 20 further includes: traversing the backend service list, accessing the interface documentation of each service one by one, and obtaining the service name, method, interface definition path, and regular expression of the interface corresponding to each service; and determining the interface information based on the service name, method, interface definition path, and regular expression of the interface corresponding to each service.

[0020] The process involves accessing the Apisix system's API to query all upstream services, then iterating through the list of services and accessing their Swagger documentation to obtain their API information. Each API definition is then parsed, retaining the service name, method, API definition path, and regular expression. This parsed data is saved to a database for later use when calling the service API. The regular expression is used to convert parameters in the path into regular expressions for matching the actual URL. For example, ` / xxx / {usercode} / user` is converted to ` / xxx / [A-Za-z0-9]{10} / user`, where `{usercode}` is replaced with the corresponding regular expression (based on parameter type and length).

[0021] For example, Swagger can automatically parse all backend HTTP / HTTPS interface information, updated daily without omission. To illustrate the process of traversing the queried service list, the Swagger document of each service is accessed one by one to obtain the interface information of each service, as shown in Table 1. Table 1:

[0022] For example, to further illustrate the parsing of the interface definition, the service name, method, path, and regular expression are retained. Refer to the converted interface data shown in Table 2. Table 2:

[0023] Step 30: Query the calling interfaces corresponding to the monitoring service and the logging service from the interface information.

[0024] Among them, the monitoring service refers to the Grafan service, and the logging service is the ELK service. By obtaining the call interfaces of the Grafan service and the ELK service from the interface information, key data for determining performance metrics can be obtained through the call interfaces of the Grafan service and the ELK service.

[0025] Step 40: Obtain performance metrics based on the API calls corresponding to the monitoring service and the API calls corresponding to the log service.

[0026] In one implementation, ELK is used to analyze historical logs and trends. The ELK stack excels at processing and analyzing massive amounts of historical log data. Interface access pattern analysis: By statistically analyzing historical logs, the call frequency of each interface at different time periods (e.g., daily / weekly peak times) is determined, thereby estimating the request volume that needs to be simulated for performance testing. Key interfaces are identified: Based on access frequency, business importance (e.g., order payment interfaces), or latency sensitivity, core parameters that require priority performance testing are identified. Response time and other information in historical logs are analyzed to establish a reasonable performance baseline for each interface, serving as a reference for comparing performance test results.

[0027] In one implementation, Grafana is primarily used to visualize and monitor real-time system status data. Here, it might provide the following key information: System resource utilization: for example, CPU, memory, disk I / O, and network utilization, helping to understand how the system performs under stress. Application performance metrics: such as application service latency, throughput (QPS / TPS), and error rate. Key performance parameters: by analyzing historical monitoring data, a performance baseline for stable system operation can be identified, as well as safe thresholds for resource utilization (e.g., CPU utilization is generally not recommended to consistently exceed 70%–80%).

[0028] Step 50: Generate a performance index table based on the performance indexes.

[0029] The performance metrics include the performance tests parsed from the calls to ELK services and Grafana services. These are the standard metrics that each interface needs to achieve, and a performance metric table is generated based on the standard metrics that each interface needs to achieve.

[0030] In one implementation, by combining Apisix, Grafana, and ELK, a complete closed loop of traffic data analysis can be completed simply by querying through interfaces and correlating data from different systems. This allows for direct modification of performance test pass criteria on the performance testing platform without human intervention. This reduces departmental collaboration, lowers labor costs, and improves testing efficiency.

[0031] As can be seen from the above, in the performance metric generation method provided by the embodiments of the present invention, when a performance metric request is obtained, a list of backend services is determined; and interface information is determined based on the list of backend services. The call interfaces corresponding to the monitoring service and the log service are queried from the interface information, and performance metrics are obtained based on the call interfaces corresponding to the monitoring service and the log service. Thus, a performance metric table is generated based on the obtained performance metrics. This can avoid the problem of poor performance metric effectiveness caused by manual intervention in determining performance metrics, effectively improve the accuracy of performance metrics, and ensure that performance metrics can be adjusted according to real-time test scenarios. Performance metrics for performance testing can be determined directly without manual intervention.

[0032] Figure 2 A flowchart of another embodiment of the performance metric generation method of the present invention is shown, which is performed by a performance metric generation device. Figure 2 As shown, step 40 includes the following steps: Step 401: Obtain traffic performance metrics based on the call interface corresponding to the log service.

[0033] Specifically, obtaining traffic performance metrics through the API call corresponding to the log service refers to obtaining traffic performance metrics through the API call corresponding to the ELK service. Traffic performance metrics are constructed from the highest QPS and corresponding time periods for each API, as well as the API request-response time, and the highest QPS and corresponding time periods for all APIs.

[0034] In one implementation, step 401 further includes: obtaining the interface access logs of the calling interface corresponding to the log service; determining the highest QPS and corresponding time information of each interface based on the interface access logs and the regular expression; and determining traffic performance indicators based on the highest QPS and corresponding time information of each interface.

[0035] Specifically, the process involves obtaining interface access logs from the ELK system, filtering the logs to obtain the timestamp of the request, the request URL, and the interface response time; decomposing the request URL to obtain the actual interface path; performing path matching on the actual interface path based on the regular expression and the defined interface path to obtain the matching result; determining the maximum QPS and corresponding time information for each interface based on the matching result, the timestamp of the request, and the interface response time; and determining traffic performance metrics based on the maximum QPS and corresponding time information for each interface.

[0036] In one implementation, a matching expression is generated based on the interface definition and path parameter type to associate traffic data and interfaces. No manual intervention is required. The traffic performance indicator determination process includes: 1. The interface access logs of the call interface corresponding to the log service are filtered through the call interface corresponding to the ELK service to extract all interface access logs of the Nginx / View layer. The interface access logs record detailed information for each request. 2. The interface access logs are initially processed, removing redundant content and extracting necessary fields, including timestamps, request URLs, and response times. 3. Further parsing of the request URL includes: a. Splitting the URL into method, domain name, and path, such as extracting the request method (e.g., GET, POST), domain name, and path (excluding query parameters) from the logs. b. Removing request parameters from the path, i.e., deleting the English question mark and its aftermath; only the path portion is retained, for example, changing " / user / 1?name=test" to " / user / 1". c. Perform path matching using regular expressions. For paths containing parameters, perform regular expression matching and then replace them with the corresponding paths containing variable names. Use regular expression matching to match paths and convert the matched paths to paths with variable names defined in Swagger (e.g., matching " / user / 1" to " / user / {id}"). Prioritize matching paths without parameters, then match paths with parameters. For example, convert the actual path to the path form in the interface definition (i.e., replace the parameter part with variable names). For example, match / xxx / 1234567890 / user to / xxx / {userId} / user and record the corresponding interface. 4. Statistically analyze data with the same method, domain, and path by timestamp, accurate to the second, and store it in the database. For example, calculate the number of requests (QPS) and response time for each interface (method + domain + path) at a fine-grained time of second. 5. Calculate the QPS of each interface at different time points and find the highest QPS and the time period in which it occurred. At the same time, calculate the percentiles and extreme values ​​of the response time, such as: generating the highest QPS for each interface of each service, the highest QPS statistics for all interfaces, and the minimum, median, average, 90th, 95th, 98th, 99th and maximum values ​​of the response time for the corresponding time period based on the statistical data.

[0037] For example, to further illustrate the traffic data extracted from the ELK system, refer to Table 3, the traffic data illustration table; Table 3:

[0038] For example, regarding the traffic data illustration table in Table 3, this solution can parse and integrate the traffic data to obtain the integrated traffic data table, as shown in Table 4. Table 4 shows the parsed merged data (detailed response times, such as maximum and minimum response times, are omitted). Table 4:

[0039] Step 402: Obtain the load performance metrics according to the calling interface corresponding to the monitoring service.

[0040] Specifically, by accessing the Grafana system, service configuration information for each service is statistically analyzed based on time information contained in traffic performance metrics; load information for each node of each service during high-traffic periods is also statistically analyzed based on time information. Load performance metrics are then determined based on the service configuration information of each service and the load information for each node of each service during high-traffic periods.

[0041] In one implementation, step 402 further includes: statistically analyzing the service configuration information of the calling interface corresponding to the monitoring service based on the time information; statistically analyzing the load information of each node of each service in each high-traffic time period based on the time information and the traffic performance index; and determining the load performance index according to the service configuration information and the load information.

[0042] In one implementation, the Grafana system is accessed, and the Grafana service interface is called to collect statistics on the configuration of each service within the corresponding time period, including the number of nodes for each service and the CPU and memory configuration information of a single node.

[0043] For example, obtain the number of nodes for each service and the resource configuration (number of CPU cores, memory size) of each node from Grafana monitoring data.

[0044] In one implementation, resource consumption for each node is determined based on high-traffic time periods statistically analyzed in traffic performance metrics, including a. JVM: GC and FGC frequency; b. MySQL: active connection count and QPS; c. Hardware: CPU, memory, network, and disk. The CPU configuration, memory configuration, and number of nodes for each service are recorded and saved to the database. The services mapped to the nodes and the load of each node are also saved to the database.

[0045] For example, to further illustrate the database storage structure, you can refer to... Figure 3The database design diagram shown illustrates a database containing tables for interface information, traffic composition, performance metrics, traffic records, traffic data, server configuration, and server load. By storing all acquired interface information in the interface information table, and combining this information with traffic data, server configuration, and load, the performance metrics for each interface are determined, thus constructing the performance metric table. This allows for direct retrieval of performance metrics from the database as testing standards. The interface information table includes: interface id (int), service id (int), method (String), path (String), and matching expression (String). The traffic composition table includes: traffic id (int), record id (int), interface id (int), traffic id (int), timestamp (long), and traffic percentage (float). The traffic record table includes: record id (int), service id (int), and load id (int). The traffic data table includes: Traffic ID: int, QPS: float, Average Response Time: float, Median Response Time: type, 90-second Response Time Line: float, 95-second Response Time Line: float, 98-second Response Time Line: float, 99-second Response Time Line: float, Minimum Response Time: float, Maximum Response Time: float. The server configuration table includes: Service ID: int, Service Name: String, CPU Configuration: String, Memory Configuration: String, Network Configuration: String, Disk Configuration: String. The server load table includes: Load ID: int, CPU Utilization: float, Memory Utilization: float, Disk Utilization: float, Network Utilization: float. The performance metrics table includes: metric id: int, test scenario id: int, interface id: int, QPS: float, average response time: float, median response time: type, 90-line response time: float, 95-line response time: float, 98-line response time: float, 99-line response time: float, minimum response time: float, maximum response time: float.

[0046] For example, during the high-traffic periods identified in the traffic performance metrics, the resource usage of each node is examined, including JVM garbage collection, database metrics, and hardware resource usage. For further illustration of the load information for each service at each time point, refer to Table 5, the load diagram. Table 5:

[0047] As described above, the performance metric generation method provided in this embodiment of the invention, upon receiving a performance metric request, determines a list of backend services; it then iterates through the backend service list, determining interface information based on the service name, method, interface definition path, and regular expression of each service's corresponding interface. It queries the call interfaces corresponding to the monitoring service and the log service from this interface information, obtaining traffic performance metrics and load performance metrics based on the call interfaces corresponding to the monitoring service. A performance metric table is then constructed based on the traffic and load performance metrics. This allows for the automated collection of interface definitions, historical traffic data, and system load data to generate performance test metrics. These metrics are based on historical real data, making the performance test standards more objective and accurate. Furthermore, different test scenarios are considered, using different metrics as pass standards, making the tests more targeted. This avoids the problem of poor performance metric effectiveness caused by manual intervention in determining performance metrics, effectively improving the accuracy of performance metrics and ensuring that performance metrics can be adjusted according to real-time test scenarios, directly determining performance test metrics without manual intervention.

[0048] Figure 4 A flowchart of another embodiment of the performance metric generation method of the present invention is shown, which is performed by a performance metric generation device. Figure 4 As shown, step 50 includes the following steps: Step 501: Statistically analyze the traffic performance metrics and the load performance metrics according to the interface metrics to generate interface performance metrics.

[0049] Among them, the interface performance indicators are determined by the highest QPS of a single interface in the traffic performance indicators, response time, and server load in the load performance indicators.

[0050] Step 502: Statistically analyze the traffic performance index and the load performance index according to the service index to generate service performance index.

[0051] Specifically, service performance metrics are determined by analyzing the highest QPS of a single service within the traffic performance metrics, the composition of each interface, and the server load within the load performance metrics. By automatically parsing real traffic and service load from the production environment and mapping it to interfaces, performance metrics for each service and each interface are finally generated.

[0052] In one implementation, the service performance metric is a comprehensive performance metric determined by considering the server load among multiple interfaces' highest QPS, response time, and load performance metrics.

[0053] Step 503: Statistically analyze the traffic performance index and the load performance index according to the overall server index to generate the overall server performance index.

[0054] The overall server performance index is determined by the server's overall QPS, the composition of each interface, and the server load among the load performance indicators.

[0055] In one implementation, by aligning traffic data and load data by time, the performance of the interface, service, and the entire system during high-pressure periods is obtained. Step 504: Generate a performance indicator table based on the interface performance indicators, the service performance indicators, and the overall server performance indicators.

[0056] Specifically, by updating interface performance metrics, service performance metrics, and overall server performance metrics to the performance testing platform, the highest historical values ​​of these metrics are written into the performance metric table. The analyzed performance metrics (such as highest QPS, response time quantiles, resource utilization, etc.) are saved to the performance testing platform's metric table as a benchmark for performance testing.

[0057] For example, to further illustrate the indicator determination process in this scheme, refer to... Figure 5 The illustrated flowchart shows the metric generation process. Daily scheduled parsing begins by discovering all backend services via Apisix and returning a list of backend services. Then, by accessing the Swagger documentation of each backend service, all interfaces are located, and the returned interface list is parsed to obtain all interface information. Next, interfaces using Grafana and ELK services are retrieved from this information. The previous day's Nginx / View layer interface call logs are queried and parsed to obtain the highest QPS and corresponding time information for each interface. The resource consumption of all services in the previous day is also queried, and service configuration and load information are used to determine resource consumption. Based on the highest QPS and corresponding time information, service configuration information, and load information for each interface, performance metrics are generated. By calling the Grafana and ELK service interfaces, the required standards for each interface during performance testing are summarized and analyzed. In short, by using historical real traffic and system load data, scientific and data-driven pass / fail standards are provided for different testing scenarios, avoiding the subjectivity and inaccuracy of manually setting performance metrics.

[0058] In this embodiment, after step 50, the method further includes selecting the interface performance index from the performance index table as the test standard if a single interface stress test is performed; selecting the service performance index from the performance index table as the test standard if a multi-interface stress test is performed; and selecting the overall server performance index from the performance index table as the test standard if a multi-interface stability test is performed.

[0059] Different test metrics are used to determine whether a test passes or fails for different performance testing scenarios. These can be divided into single-interface stress testing, which involves high-concurrency testing on a single interface and using interface performance metrics as the pass standard; multi-interface stress testing, which involves high-concurrency testing on multiple interfaces simultaneously according to traffic ratio and using service performance metrics as the pass standard; and multi-interface stability testing, which involves long-term high-load testing on multiple interfaces simultaneously according to traffic ratio and using overall server performance metrics as the pass standard.

[0060] As described above, the performance metric generation method provided in this embodiment of the invention determines a backend service list upon receiving a performance metric request. It then iterates through the backend service list, determining interface information based on the service name, method, interface definition path, and regular expression of each service's corresponding interface. The method queries the call interfaces corresponding to the monitoring service and the log service from this interface information. Traffic performance metrics and load performance metrics are obtained based on the call interfaces corresponding to the monitoring service. A performance metric table containing interface performance metrics, service performance metrics, and overall server performance metrics is then constructed based on the traffic and load performance metrics. This method automatically collects interface definitions, historical traffic data, and system load data to generate performance test metrics. These metrics are based on historical real data, making the performance test standards more objective and accurate. Furthermore, different test scenarios are considered, using different metrics as pass standards, making the tests more targeted. This avoids the problem of poor performance metric effectiveness caused by manual intervention, effectively improving the accuracy of performance metrics and ensuring that performance metrics can be adjusted according to real-time test scenarios, directly determining performance test metrics without manual intervention.

[0061] Figure 6 A schematic diagram of an embodiment of the performance index generation device of the present invention is shown. Figure 6 As shown, the device 300 includes: a service determination module 310, an interface determination module 320, an interface call module 330, an indicator acquisition module 340, and an indicator determination module 350.

[0062] Service determination module 310 is used to determine the list of backend services when a performance metric request is received; The interface determination module 320 is used to determine interface information based on the backend service list; The interface call module 330 is used to query the call interface corresponding to the monitoring service and the call interface corresponding to the log service from the interface information. The metrics acquisition module 340 is used to acquire performance metrics based on the call interface corresponding to the monitoring service and the call interface corresponding to the log service. The indicator determination module 350 is used to generate a performance indicator table based on the performance indicators.

[0063] In an optional manner, the interface determination module 320 is further configured to traverse the backend service list, access the interface documentation of each service one by one, and obtain the service name, method, interface definition path, and regular expression of the interface corresponding to each service; and determine the interface information based on the service name, method, interface definition path, and regular expression of the interface corresponding to each service.

[0064] In an alternative embodiment, the metric acquisition module 340 is further configured to acquire traffic performance metrics based on the call interface corresponding to the log service; and acquire load performance metrics based on the call interface corresponding to the monitoring service.

[0065] In one optional approach, the metric acquisition module 340 is further configured to acquire the interface access logs of the call interface corresponding to the log service; determine the highest QPS and corresponding time information of each interface based on the interface access logs and the regular expression; and determine the traffic performance metrics based on the highest QPS and corresponding time information of each interface.

[0066] In an optional manner, the indicator acquisition module 340 is further configured to: statistically analyze the service configuration information of the calling interface corresponding to the monitoring service based on the time information; statistically analyze the load information of each node of each service in each high traffic time period based on the time information and the traffic performance indicator; and determine the load performance indicator based on the service configuration information and the load information.

[0067] In one optional embodiment, the metric determination module 350 is further configured to: statistically analyze the traffic performance metrics and the load performance metrics according to interface metrics to generate interface performance metrics; statistically analyze the traffic performance metrics and the load performance metrics according to service metrics to generate service performance metrics; statistically analyze the traffic performance metrics and the load performance metrics according to server overall metrics to generate server overall performance metrics; and generate a performance metric table based on the interface performance metrics, the service performance metrics, and the server overall performance metrics.

[0068] In one alternative approach, the indicator determination module 350 is further configured to select the interface performance indicator from the performance indicator table as the test standard if a single interface stress test is performed; select the service performance indicator from the performance indicator table as the test standard if a multi-interface stress test is performed; and select the overall server performance indicator from the performance indicator table as the test standard if a multi-interface stability test is performed.

[0069] The performance index generation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0070] Figure 7 The diagram shows a structural schematic of an embodiment of the performance index generation device of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the performance index generation device.

[0071] like Figure 7 As shown, the performance indicator generating device may include: processor 403, communication interface 404, memory 406, and communication bus 408.

[0072] The processor 403, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other network elements, such as clients or other servers. The processor 403 executes program 410, specifically performing the relevant steps described above in the embodiment of the performance indicator generation method.

[0073] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0074] Processor 403 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The performance indicator generation device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0075] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0076] Specifically, program 410 can be called by processor 403 to cause the XXX device to execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0077] This invention provides a computer-readable storage medium storing at least one executable instruction that, when executed on a performance metric generation device / apparatus, causes the performance metric generation device / apparatus to perform the performance metric generation method described in any of the above method embodiments.

[0078] The executable instructions can be used to cause the performance indicator generating device / app to execute the method provided in the above method embodiment. The implementation principle and technical effect are similar, and will not be described in detail here.

[0079] Furthermore, all information to be extracted in this application was obtained with the user's permission or consent; that is, when this application is applied to a specific product or technology, user permission is required to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0080] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments of this invention are not directed to any particular programming language.

[0081] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0082] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0083] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A performance indicator generation method characterized by, The method comprises: In the case of a performance index request, determining a backend service list; According to the interface information of the backend service list, the calling interface corresponding to the monitoring service and the calling interface corresponding to the log service are queried from the interface information; Based on the calling interface corresponding to the monitoring service and the calling interface corresponding to the log service, the performance index is obtained; According to the performance index, a performance index table is generated. According to the interface information of the backend service list, the calling interface corresponding to the monitoring service and the calling interface corresponding to the log service are queried from the interface information; 2. The method of claim 1, wherein, The performance index includes a traffic performance index and a load performance index, and the performance index is obtained based on the calling interface corresponding to the monitoring service and the calling interface corresponding to the log service, comprising: According to the calling interface corresponding to the log service, the traffic performance index is obtained; According to the calling interface corresponding to the monitoring service, the load performance index is obtained.

3. The method of claim 2, wherein, According to the calling interface corresponding to the log service, the traffic performance index is obtained, comprising: The interface access log of the calling interface corresponding to the log service is obtained; Based on the interface access log and the regular matching expression, the highest QPS of each interface and the corresponding time information are determined; 4. The method of claim 3, wherein, According to the highest QPS of each interface and the corresponding time information, the traffic performance index is determined. According to the calling interface corresponding to the monitoring service, the load performance index is obtained, comprising: Based on the time information, the service configuration information of the calling interface corresponding to the monitoring service is counted; Based on the time information and the traffic performance index, the load information corresponding to each node of each service in each high-traffic time period is counted; 5. The method of claim 4, wherein, According to the service configuration information and the load information, the load performance index is determined. According to the performance index, a performance index table is generated, comprising: According to the interface index, the traffic performance index and the load performance index are counted to generate an interface performance index; According to the service index, the traffic performance index and the load performance index are counted to generate a service performance index; 6. The method of claim 5, wherein, According to the server overall index, the traffic performance index and the load performance index are counted to generate a server overall performance index; According to the interface performance index, the service performance index and the server overall performance index, a performance index table is generated. After the performance index table is generated according to the performance index, it further comprises: If single-interface stress testing is performed, the interface performance index is selected from the performance index table as the test standard; If multi-interface stress testing is performed, the service performance index is selected from the performance index table as the test standard; 7. The method of claim 6, wherein, If multi-interface stability testing is performed, the server overall performance index is selected from the performance index table as the test standard. The device comprises: A service determination module for determining a backend service list in the case of a performance index request; ​ 8. A performance indicator generation apparatus characterized by comprising: ​ ​ An interface determination module is configured to determine interface information according to the backend service list; An interface calling module is configured to query a calling interface corresponding to the monitoring service and a calling interface corresponding to the log service from the interface information; An index acquisition module is configured to acquire performance indexes based on the calling interface corresponding to the monitoring service and the calling interface corresponding to the log service; An index determination module is configured to generate a performance index table according to the performance indexes.

9. A performance indicator generation device characterized by comprising: Comprise: A processor, a memory, a communication interface and a communication bus, the processor, the memory and the communication interface complete the communication among each other through the communication bus; The memory is used to store at least one executable instruction, and the executable instruction makes the processor execute the operations of the performance index generation method in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium has at least one executable instruction stored therein, and the executable instruction makes the performance index generation device / apparatus execute the operations of the performance index generation method in any one of claims 1-7 when the performance index generation device / apparatus runs.

Images