A software performance bottleneck locating method and device

Abstract

The embodiment of the application provides a software performance bottleneck positioning method and device, and relates to the technical field of computer application. The method obtains pressure test data of a software to-be-tested version by executing software pressure test, and queries historical configuration information corresponding to the software to-be-tested version. Then, the changed configuration item of the software to-be-tested version is determined according to the pressure test data and the historical configuration information. Then, the performance bottleneck node is positioned based on the changed configuration item and in combination with the request time consumption of each node of the historical version link. Then, in combination with the resource utilization rate and the software and hardware configuration information, the bottleneck root cause of the performance bottleneck node is analyzed to generate performance bottleneck positioning information. The method can realize automatic positioning of the software full-link performance bottleneck, quickly identify the node with the performance bottleneck in the link, improve the software performance bottleneck positioning and performance tuning efficiency, reduce the performance test cost before the software goes online, and speed up the processing speed of the production performance problem after the software goes online.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a method and apparatus for locating software performance bottlenecks. Background Technology

[0002] Computer software, also known as computer applications, is a collection of computer data and instructions configured for computer hardware, possessing data or signal processing capabilities. Computer software can be deployed as a complete logical entity, comprising core components such as programs, data, and documents, according to specific business needs. As business continues to develop, the importance of software performance increases daily; however, software performance during development can be affected by various factors, leading to performance bottlenecks.

[0003] A software performance bottleneck refers to the smallest capacity link in the execution path of a software system that limits the overall throughput or response time. Software performance bottlenecks can determine the upper limit of a software system's performance, therefore, it is necessary to locate them. This includes locating the end-to-end performance bottleneck in high-concurrency scenarios. When locating software performance bottlenecks, a comprehensive investigation can be conducted based on the specific problem, combining various complex information such as hardware and software configuration, hardware resource utilization, and software thread stacks, to identify the software link node causing the bottleneck.

[0004] Software performance bottleneck localization is a costly, time-consuming, and challenging problem that severely tests the experience of the personnel involved. For example, it is difficult to pinpoint the nodes where performance bottlenecks occur, identify the sources of performance bottlenecks within those nodes, and find a lack of direction for performance tuning. This is especially true for large software systems with complex architectures and lengthy processes, where bottleneck localization and performance tuning are inefficient, pre-deployment performance testing is costly, and post-deployment production performance issues are handled slowly. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method and apparatus for locating software performance bottlenecks to solve the problem of low efficiency in locating software performance bottlenecks.

[0006] According to a first aspect of this application, a method for locating software performance bottlenecks is provided, the method comprising: Obtain load test data for the software version under test, including the hardware and software configuration information of the link nodes of the software version under test and the performance data of the version under test; Query the historical configuration information corresponding to the software version to be tested; Based on the stress test data and the historical configuration information, determine the changed configuration items for the software version to be tested; Based on the changed configuration items, and combined with the request time of each node in the historical version link, the performance bottleneck node is located. The performance bottleneck node is the node where the request time of the software under test version differs from the request time of the historical version. By combining resource utilization and the aforementioned hardware and software configuration information, the root causes of the performance bottleneck nodes are analyzed to generate performance bottleneck location information.

[0007] In some embodiments, obtaining load test data for the software version under test includes: Set a test strategy based on the software version to be tested. The test strategy can be a general test strategy or the test strategy of the previous version submitted for testing. Save the hardware and software configuration information of the link node of the software version under test to the database; Software load testing is performed based on the aforementioned testing strategy to record the performance data of the version under test during the software load testing process. The performance data of the version under test includes the request time, node resource utilization, and occurrence time of each node in the software link. The performance data of the version under test is saved to the database in chronological order of occurrence.

[0008] In some embodiments, a testing strategy is set according to the version of the software to be tested, including: Obtain the software version to be tested; Based on the software version to be tested, query the database for historical version performance data of the same software. When no historical version performance data for the same software is found, the test strategy is set to the general test strategy. When querying historical version performance data of the same software, the test strategy is set to the test strategy of the previous version submitted for testing.

[0009] In some embodiments, querying the historical configuration information corresponding to the software version under test includes: Based on the software version under test, query the historical performance data of the same software version. Bottleneck judgment conditions are set based on the historical version performance data. The bottleneck judgment conditions include at least one of the historical version performance and preset business requirement indicators extracted from the historical version performance data. Extract the performance of the version under test from the performance data of the version under test; When the performance of the version under test is lower than that of the historical version, and / or the performance of the version under test does not meet the preset business requirement indicators, the historical configuration information corresponding to the software version under test is queried.

[0010] In some embodiments, when the performance of the version under test is lower than that of the historical version, the method further includes: Extract the historical time consumption of each node in the historical version link from the historical version performance data; Based on the historical time consumption, nodes with time consumption differences are filtered out from the performance data of the version under test. The nodes with time consumption differences are nodes in the link of the version under test whose request time is higher than the historical time consumption. Construct a first performance bottleneck node list based on the nodes with different time consumption; Calculate the time difference value of the time difference node, where the time difference value is the difference between the request time of the time difference node and the historical time. The first performance bottleneck node list is sorted according to the time difference value to obtain the second performance bottleneck node list; Locate the performance bottleneck node from the second list of performance bottleneck nodes.

[0011] In some embodiments, when the performance of the version under test does not meet the preset business requirement indicators, the method further includes: The request time for traversing all nodes in the internal link of the software version under test; A third performance bottleneck node list is constructed based on the request time, and the third performance bottleneck node list includes nodes whose request time exceeds a preset time threshold; Based on the time consumption values, the third performance bottleneck node list is sorted to obtain the fourth performance bottleneck node list. Locate the performance bottleneck node from the fourth list of performance bottleneck nodes.

[0012] In some embodiments, after extracting the performance of the version under test from the performance data of the version under test, the method further includes: Extract historical version performance from the historical version performance data; The performance difference is calculated based on the performance of the version under test and the performance of the historical version. The performance difference is the ratio of the difference between the performance of the version under test and the performance of the historical version to the performance of the historical version. Obtain the preset performance deviation coefficient; When the performance difference is greater than or equal to the preset performance deviation coefficient, it is determined that the performance of the version under test is lower than that of the historical version.

[0013] In some embodiments, by combining resource utilization and the hardware and software configuration information, the root cause of the performance bottleneck node is analyzed to generate performance bottleneck location information, including: Based on the performance bottleneck node, extract the configuration item of the version to be tested associated with the performance bottleneck node from the software and hardware configuration information; Retrieve the historical configuration items associated with the performance bottleneck node from the historical configuration information; By comparing the configuration items of the version under test with the historical configuration items, the configuration differences are determined; Based on the configuration differences, performance bottleneck location information containing change-type bottlenecks is generated.

[0014] In some embodiments, by combining resource utilization and the hardware and software configuration information, the root cause of the performance bottleneck node is analyzed to generate performance bottleneck location information, including: Obtain the resource utilization rate of the performance bottleneck node; Calculate the resource indicators for the version under test based on the resource utilization rate; Extract historical version resource metrics from the historical version performance data; If the resource metrics of the version under test are higher than those of the historical version, performance bottleneck location information containing resource-related bottlenecks is generated.

[0015] According to a second aspect of this application, a software performance bottleneck location device is provided, the device comprising: The data acquisition module is used to acquire load test data of the software version under test. The load test data includes the hardware and software configuration information of the link nodes of the software version under test and the performance data of the version under test. The hardware and software configuration acquisition module is used to query the historical configuration information corresponding to the software version under test; The configuration change item determination module is used to determine the configuration change items of the software version to be tested based on the stress test data and the historical configuration information. The performance bottleneck location module is used to locate the performance bottleneck node based on the changed configuration item and the request time of each node in the historical version link. The performance bottleneck node is the node where the request time of the software under test is different from the request time of the historical version. The root cause analysis module is used to combine resource utilization and the hardware and software configuration information to analyze the root cause of the performance bottleneck node, so as to generate performance bottleneck location information.

[0016] According to a third aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described software performance bottleneck location method.

[0017] According to a fourth aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described software performance bottleneck location method.

[0018] By employing the above technical solutions, embodiments of this application provide a method and apparatus for locating software performance bottlenecks. The method obtains load test data for the software version under test by performing load testing and queries the historical configuration information corresponding to the software version under test. Then, based on the load test data and historical configuration information, it determines the changed configuration items of the software version under test. Next, based on the changed configuration items and the request latency of each node in the historical version's link, it locates the performance bottleneck node. Finally, it analyzes the root cause of the bottleneck node by combining resource utilization and hardware / software configuration information to generate performance bottleneck location information. This method can automatically locate performance bottlenecks across the entire software link, quickly identifying nodes with performance bottlenecks in the link. The method also automatically performs root cause analysis on the link nodes with performance bottlenecks to locate the source of the problem and indicate the direction for performance tuning. This method can improve the efficiency of software performance bottleneck location and performance tuning, reduce the cost of performance testing before software deployment, and accelerate the handling of production performance problems after software deployment.

[0019] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic flowchart of the software performance bottleneck localization method provided in the embodiments of this application; Figure 2 This is a schematic diagram illustrating the process of determining whether a performance bottleneck exists in a flow, as provided in an embodiment of this application. Figure 3 This is a schematic diagram of the functional modules of an electronic device provided in an embodiment of this application; Figure 4 A flowchart illustrating the process of determining whether the performance of the version under test is lower than that of historical versions, provided for an embodiment of this application; Figure 5 A schematic diagram of the software performance bottleneck location device provided in this application embodiment. Detailed Implementation

[0021] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0022] In this embodiment, software refers to a collection of computer data and instructions that can run in a computer environment. Software can be organized in a specific order to provide specific functions and performance. It should be understood that the term software is broad and refers to a collection of data and instructions that can run in various computer environments. For example, software may include system software, application software, and middleware running on a single computer device, or network software, database software, and communication software running in a cluster of multiple computer devices.

[0023] Software can be a standalone application with a single function, or a software system composed of multiple applications. Software can include multiple components. For example, based on logical structure, software can include program code, data, and documentation. Based on architectural composition, software can include a user interface layer, business logic layer, data access layer, and infrastructure layer.

[0024] In some embodiments, software may include key components such as modules, interfaces, libraries, dependencies, resource files, and metadata. A module, also called a component, is an independent unit used to implement a specific function; an interface defines the interaction contract between modules; a library, also called a framework, stores a collection of reusable code; dependencies are external resources required for the software to run; resource files are non-code auxiliary files used during software operation; and metadata describes the software itself.

[0025] To meet specific business needs, software development can be tailored to the computer hardware conditions within the business scenario. The software development process can involve stages such as requirements analysis, system design, coding implementation, testing and verification, deployment and launch, and operation and maintenance. Furthermore, for the software development process, each independent, identifiable execution unit in the software can be defined as a node (Node / Span). That is, each node can represent a specific operation or processing step in the software. A node can include core attributes such as name, timestamp, status, metadata, and context. The name is used to label the operation content and type of the node; the timestamp indicates the start and end times of the node request, which can be used to calculate request latency; the status indicates the execution result of the node operation, such as success, failure, timeout, etc.; metadata can include node-related tags, logs, exception information, etc.; and the context is used to label path identifiers (Trace ID), node identifiers (Span ID), and hierarchy identifiers (Parent ID) for the specified stages.

[0026] In the software development process, a directed path consisting of multiple related nodes can also be called a link / trace. A link can be used to represent a complete request flow, that is, the end-to-end request execution trajectory. For example, for a software system for transaction business, a complete link may include the user's browser, gateway service (node ​​A), order service (node ​​B), inventory service (node ​​C), payment service (node ​​D), and database (node ​​E), etc.

[0027] As business grows, the importance of software performance increases daily. However, software performance during development is affected by various factors, leading to performance bottlenecks. A software performance bottleneck refers to the smallest capacity step in the execution path of a software system that limits the overall throughput or response time. Software performance bottlenecks can determine the upper limit of a software system's performance, therefore, it is necessary to locate them. For example, this can involve identifying end-to-end performance bottlenecks in high-concurrency scenarios.

[0028] In some embodiments, when locating software performance bottlenecks, a comprehensive investigation can be conducted based on various complex information such as hardware and software configuration, hardware resource utilization, and software thread stacks, in order to identify the software link nodes causing the software performance bottleneck.

[0029] However, identifying software performance bottlenecks is a costly, time-consuming, and challenging problem that heavily relies on the experience of the personnel involved. For example, it is difficult to pinpoint the nodes where performance bottlenecks occur, identify the sources of performance bottlenecks within those nodes, and find a lack of direction for performance tuning. This is especially true for large software systems with complex architectures and lengthy processes, where bottleneck identification and performance tuning are inefficient, pre-deployment performance testing is costly, and post-deployment production performance issues are handled slowly.

[0030] To address the issue of low efficiency in locating software performance bottlenecks, this application provides a method for locating software performance bottlenecks in certain embodiments. This method offers a complete approach to bottleneck location, simplifying the bottleneck identification process and improving efficiency by extracting node latency as a key performance element. Based on automatic analysis of full-link node latency, historical versions of link node hardware and software configurations, and historical software version performance data, this method possesses good versatility and is applicable to software across various industries, server models, programming languages, and technical architectures.

[0031] The method can be applied to electronic devices with data processing capabilities. These electronic devices include, but are not limited to, computers, servers, mobile terminals, smart wearable devices, and industrial control machines. For ease of description, this application embodiment uses an electronic device as the execution subject of the method. It should be understood that the method can also be applied to other types of execution subjects, which are not illustrated in this application embodiment. Figure 1 As shown, the method includes: S101. Obtain the load test data of the software version to be tested.

[0032] When identifying software performance bottlenecks, the first step is to obtain load testing data for the software version under test. This load testing data refers to the data obtained by recording test parameters and results during the load testing process, following a pre-defined testing strategy. Therefore, the load testing data can include the hardware and software configuration information of the link nodes in the software version under test, as well as the performance data of the version under test.

[0033] In some embodiments, in order to obtain load test data of the software version to be tested, a test strategy can be set according to the software version to be tested, wherein the test strategy is a general test strategy or the test strategy of the previous version submitted for testing.

[0034] When setting a test strategy based on the software version to be tested, you can first obtain the software version to be tested, and then query the database for historical performance data of the same software version. Based on the query results of historical performance data of the same software version, if no historical performance data of the same software version is found, you can set the test strategy to a general test strategy; if historical performance data of the same software version is found, you can set the test strategy to the test strategy of the previous version submitted for testing.

[0035] For example, the testing strategy can be determined and the software load test executed based on the version of the software to be tested. Depending on the version, two testing strategies can be set: a general testing strategy and a testing strategy for the previous version. For new services or interfaces submitted for initial testing without historical performance data, the project's preset general testing strategy can be used, such as a load test with 100 concurrent threads, increasing by 10 threads per minute, for a total load test of 10 minutes.

[0036] For services or interfaces that have historical performance data stored for secondary or multiple testing, the testing strategy of the previous testing version of the relevant service can be used, that is, the same number of load testing threads, load testing time, load testing data volume, etc., to ensure that the pressure side is constant.

[0037] After setting the test strategy, software load testing can be performed according to the set test strategy. Before performing software load testing, the software and hardware configuration information of the link nodes of the software version under test can be saved to the database to store the software and hardware configuration information of the link nodes of the software version under test in the database for subsequent use.

[0038] Then, based on the testing strategy, software load testing is performed to record the performance data of the version under test during the load testing process. The recorded performance data includes performance parameters such as request latency and node resource utilization at each node of the software pipeline. Furthermore, while recording the performance data, the corresponding occurrence time is associated with the recorded content. After recording the performance data, it can also be saved to a database in chronological order.

[0039] For example, a software version performance data acquisition module can be deployed in electronic devices. This module can access data from any historical version, any business scenario / interface, and any performance metric. After confirming the testing strategy for the software version under test and executing load testing, the software version performance data acquisition module can acquire and save performance data for all scenarios of each software version, such as baseline performance for single-interface scenarios, mixed performance for multi-interface scenarios, and performance for long-term stable operation scenarios.

[0040] The recorded performance data includes scenario-specific business performance data, such as Requests Per Second (QPS) or Transactions Per Second (TPS), request latency, business error rate, and resource utilization. Request latency can include average latency and percentile latency. During the recording of business performance data, the associated scenario stress testing strategies and test times can also be stored. For example, scenario stress testing strategies can include the number of threads used in the stress test, thread increment strategies, and peak duration. Test times can include test start time and test end time.

[0041] The recorded data can be stored in a database. Before the load test begins, the latest hardware and software configuration information for each node in the software test version's pipeline can be saved to the database. During the load test, request latency data, node resource utilization data, and associated occurrence times for each node in the software pipeline are saved to the database in chronological order. Similarly, after the load test ends, the performance data of the software test version is saved to the database.

[0042] In some embodiments, after acquiring load test data, the software version under test can also be used to detect whether there are performance bottlenecks, i.e., ... Figure 2As shown, after obtaining the load testing data for the software version under test, you can first query the historical performance data of the same software version. Then, you can set bottleneck judgment conditions based on the historical version performance data. The bottleneck judgment conditions include at least one of the historical version performance data extracted from the historical version performance data and preset business requirement indicators.

[0043] Then, extract the performance of the version under test from the performance data of the version under test, and when the performance of the version under test is lower than the historical version performance, and / or the performance of the version under test does not meet the preset business requirement indicators, query the historical configuration information corresponding to the software version under test.

[0044] For example, electronic devices can have a built-in performance data acquisition module to obtain performance data for the software version under test and historical versions. This module can then retrieve performance data for both the software version under test and historical versions from a database.

[0045] Then, based on the acquired historical version performance data, it is determined whether the software has performance bottlenecks. A performance bottleneck assessment strategy is formed by setting bottleneck assessment conditions. Specifically, the performance bottleneck assessment strategy includes that the performance of the current version under test is no less than that of the previous historical version, and that the performance of the current version under test must meet business requirements. If any one of the bottleneck assessment conditions is not met, a performance bottleneck is considered to exist.

[0046] That is, Figure 3 As shown, the electronic device can also have a built-in software version performance bottleneck detection module. This module can determine whether a performance bottleneck exists based on a performance bottleneck detection strategy. Specifically, if the performance of the current version under test is not lower than that of the previous historical version, and the performance of the current version under test meets business requirements, then no performance bottleneck is identified, and the software performance bottleneck identification process can be terminated. However, if the performance of the current version under test is lower than that of the previous historical version, or if the performance of the current version under test does not meet business requirements, then a performance bottleneck is identified, and the next step can be performed.

[0047] S102. Query the historical configuration information corresponding to the version of the software to be tested.

[0048] After obtaining load test data for the software version under test and identifying performance bottlenecks, you can query the historical configuration information corresponding to the software version under test. This historical configuration information consists of the hardware and software configuration information of the link nodes recorded during load testing of previous software versions.

[0049] To query historical configuration information for the software version under test, a configuration information query command can be generated based on the software version under test. This command can include the target software and the software version under test. The command is then sent to the database to retrieve historical configuration information. Upon receiving the query command, the database first identifies the target software based on the software version under test, and then extracts the configuration information from previous versions of the same target software during load testing—this is the historical configuration information.

[0050] For example, electronic devices can have a built-in software link node hardware and software configuration acquisition module. This module can collect and save the hardware and software configuration information of all software link nodes and each version, and can be used to automatically analyze and compare the configuration items that have changed (differences) between the version under test and the previous historical version.

[0051] Historical configuration information can include node software configuration items and node hardware configuration items. Specifically, historical configuration information includes the software and hardware information that various software programs on the node depend on for operation, such as the underlying hardware machine type, CPU and memory parameters, upper-layer application software code version, application configuration, middleware code version, and middleware configuration.

[0052] Node software configuration information includes application-layer configuration items and full service configuration items. Application-layer configuration items can include software service names, version numbers, and full service configuration items. The software service name can represent all services on this node, including middleware. Full service configuration items can include configuration files and startup parameters for business software, and configuration files for middleware software. Operating system-layer configuration items include system type, version number, kernel version number, and kernel parameters.

[0053] Node hardware configuration information may include the hardware machine name, model, and main performance parameters. Taking main performance parameters as an example, these may include the number of CPU cores, memory size, disk read / write speed and capacity, number of network cards, and network bandwidth.

[0054] S103. Determine the change configuration items for the software version to be tested based on the load test data and historical configuration information.

[0055] After obtaining historical configuration information, the modified configuration items for the software version under test can be determined based on the load test data and historical configuration information. Modified configuration items refer to configuration items that differ between the load test data of the software version under test and the historical configuration information corresponding to previous software versions.

[0056] To identify changed configuration items, after obtaining load test data and historical configuration information, the hardware and software configuration information of the software version under test can be extracted from the load test data. Then, the configuration items associated with each node in the software pipeline—namely, the configuration items for the version under test and the configuration items for the historical versions—can be read from both the hardware and software configuration information and the historical configuration information. Finally, by comparing the configuration items for the version under test with those for the historical versions, the changed configuration items that differ from those in the historical versions can be identified.

[0057] For example, the software link node hardware and software configuration acquisition module can access all link nodes, any historical version, any hardware and software configuration information, and any two versions of differing configuration items. Therefore, electronic devices can obtain hardware and software configuration information for the software link nodes through this module, query historical configuration information from the database, and then compare the configuration items to identify the changed configuration items in the current version under test.

[0058] S104. Based on the changed configuration items, and combined with the request time of each node in the historical version link, locate the performance bottleneck node.

[0059] Once the changed configuration items are identified, performance bottleneck nodes can be located based on these changes. In locating bottleneck nodes, the request latency of each node in the historical software version's pipeline can be obtained first, and then combined with the request latency of each node in the historical version's pipeline to pinpoint the performance bottleneck node. Specifically, the performance bottleneck node is the node where the request latency of the software version under test differs from the request latency of historical versions.

[0060] For example, electronic devices can be equipped with a module for collecting software link node time consumption and resource utilization data. This module can collect data such as request time consumption and resource utilization of each node in the entire software link, associate them with the corresponding occurrence time, and save the collected data in chronological order. It can also support comparing the node time consumption and resource utilization data of the software version under test and the previous historical version, and identify nodes where the data of the two versions differ.

[0061] The software link node time consumption and resource utilization acquisition module can collect data at preset sampling intervals, which can be set according to actual needs, such as 1s, 5s, 60s, etc. The request time data collected by this module can include average time consumption, maximum or minimum time consumption, percentile time consumption, etc. Percentile time consumption can include 95th percentile time consumption, 99th percentile time consumption, etc. Resource utilization data includes CPU utilization, memory usage, disk I / O, and network bandwidth, etc.

[0062] Based on the acquired software link node time and resource utilization, performance bottlenecks are then located. When locating performance bottlenecks, the database can be queried to retrieve the time and resource utilization data of each node in the software version under test and the previous historical version, based on the test time. Nodes with discrepancies in time consumption data between the two versions can then be identified to automatically locate software link performance bottlenecks.

[0063] When locating performance bottlenecks in the software pipeline, different bottleneck location methods can be adopted based on the bottleneck judgment conditions met by the load test data of the software version under test. That is, when locating performance bottleneck nodes, different location analysis strategies can be applied according to the judgment conditions of the bottleneck source.

[0064] In some embodiments, when the performance of the version under test is lower than that of historical versions—that is, when the performance of the current version under test does not meet the bottleneck judgment condition that the performance of the version under test is not lower than that of the previous historical version—then the differences in the link nodes between the two versions can be considered. To this end, the historical latency of each node in the historical version link can be extracted from the historical version performance data. Based on the historical latency, nodes with latency differences can be filtered out from the performance data of the version under test. These nodes are those in the link of the version under test whose request latency is higher than the historical latency.

[0065] Next, a first performance bottleneck node list is constructed based on the nodes with different time consumption, and the time consumption difference value of each node is calculated, where the time consumption difference value is the difference between the request time and the historical time of the node. Then, the first performance bottleneck node list is sorted according to the time consumption difference value to obtain a second performance bottleneck node list, and the performance bottleneck node is located from the second performance bottleneck node list.

[0066] For example, if the performance of the current version under test is lower than that of the previous historical version based on load test data, meaning it does not meet the bottleneck judgment condition that the performance of the current version under test should not be lower than that of the previous historical version, then we can focus on the differences in the link nodes between the two versions. Therefore, we can filter out the nodes whose output time differs from those of the nodes whose time consumption data differs between the two versions, and then filter out the nodes whose time consumption of the current version under test is higher than that of the previous historical version, forming a first performance bottleneck node list. The nodes in the first performance bottleneck node list are the performance bottleneck nodes.

[0067] After constructing the first performance bottleneck node list, the nodes in the first performance bottleneck node list can be sorted in descending order of their time consumption differences to obtain the second performance bottleneck node list. The second performance bottleneck node list is an ordered list of the severity levels of the performance bottleneck nodes, and the nodes at the top of the second performance bottleneck node list are the performance bottleneck nodes that most significantly constrain software performance. Subsequent performance tuning can be carried out on the nodes sequentially, referring to the order of the second performance bottleneck node list.

[0068] Based on this, electronic devices can use a built-in software link performance bottleneck localization module to identify software performance bottlenecks, locate bottleneck nodes, and perform root cause analysis of node performance bottlenecks. The software link performance bottleneck localization module first determines whether a performance bottleneck exists in the software link based on a performance bottleneck judgment strategy. If a bottleneck exists, it analyzes and locates the node time data from the software link node time and resource utilization collection module to obtain a list of link nodes with performance bottlenecks, automatically sorting them according to the severity of the bottleneck for priority risk identification. If no bottleneck is found, the process ends.

[0069] In some embodiments, when the performance of the version under test does not meet preset business requirement indicators, the differences between the link nodes within the version under test can be considered. When locating the software performance bottleneck, the request latency of all nodes within the internal link of the version under test can be traversed first, and a third performance bottleneck node list can be constructed based on the request latency. This third performance bottleneck node list includes nodes whose request latency exceeds a preset latency threshold. Then, based on the latency values, the third performance bottleneck node list is sorted to obtain a fourth performance bottleneck node list, and the performance bottleneck node is located from this fourth performance bottleneck node list.

[0070] For example, when the performance of the version under test does not meet the bottleneck judgment condition that the performance of the version under test must meet the business requirements, we can focus on the differences between the link nodes within the version under test, assuming that all nodes may be performance bottleneck nodes. Therefore, in a request link, the node with higher latency has a greater impact on the processing performance of the entire link. Thus, we propose using node latency as a criterion for judging the severity level of performance bottlenecks.

[0071] Therefore, all nodes in the internal link of the version under test can be used as a performance bottleneck node list, i.e., the third performance bottleneck node list. Then, the nodes in the third performance bottleneck node list are sorted in descending order of the time consumption values ​​of each node in the version under test to obtain the fourth performance bottleneck node list, which serves as an ordered list of the severity levels of performance bottleneck nodes.

[0072] S105. Combining resource utilization and hardware / software configuration information, analyze the root causes of performance bottleneck nodes to generate performance bottleneck location information.

[0073] After locating the performance bottleneck node, a root cause analysis can be performed on the identified bottleneck node. This involves analyzing the time consumption data of the link node to locate the performance bottleneck node, and then combining this with resource utilization and hardware / software configuration to automatically analyze the root cause of the bottleneck, pinpoint the source of the problem, and indicate the direction for performance optimization.

[0074] When performing automatic bottleneck root cause analysis, resource utilization and hardware / software configuration information can be combined. That is, by combining resource utilization and hardware / software configuration information, the root cause of node performance bottlenecks can be automatically analyzed to pinpoint the specific source of the problem.

[0075] For example, for performance bottleneck nodes, electronic devices can call the node hardware and software configuration difference items of the software link node hardware and software configuration acquisition module and the resource utilization difference items of the software link node time consumption and resource utilization acquisition module. After analysis and location, the specific root cause of the performance bottleneck can be identified, which is convenient for subsequent direct optimization and resolution.

[0076] The results of bottleneck root cause analysis can be represented in the form of performance bottleneck location information. That is, electronic devices can combine resource utilization and hardware and software configuration information to analyze the bottleneck root cause of performance bottleneck nodes and generate performance bottleneck location information.

[0077] In some embodiments, when analyzing the root cause of a performance bottleneck node, the following steps can be taken: First, based on the performance bottleneck node, extract the configuration items of the version under test associated with the performance bottleneck node from the hardware and software configuration information, and obtain the historical configuration items associated with the performance bottleneck node from the historical configuration information. Then, by comparing the configuration items of the version under test with the historical configuration items, the configuration differences can be identified. Finally, performance bottleneck location information containing change-type bottlenecks can be generated based on the configuration differences.

[0078] For example, bottleneck root cause analysis can be performed on each node in the performance bottleneck node list 2 in the order of the nodes in the list. Root cause analysis can determine the root cause classification and determine the analysis priority order based on the different root cause classifications. For change-related bottlenecks, targeting existing services or interfaces, the historical configuration of the software link node's hardware and software can be retrieved from the database. After obtaining the configuration items that have changed in the current version under test, the differences in the node's hardware and software configuration can be obtained. If differences exist, the relevant differences are considered the root cause of the node's performance bottleneck.

[0079] In some embodiments, when analyzing the root cause of a performance bottleneck node, the resource utilization rate of the bottleneck node can also be obtained, and resource metrics for the version under test can be calculated based on the resource utilization rate. Then, historical version resource metrics are extracted from historical version performance data, and the resource metrics for the version under test are compared with those of historical versions. If the resource metrics for the version under test are higher than those of historical versions, performance bottleneck location information containing resource-related bottlenecks is generated.

[0080] For example, for resource bottlenecks, the performance of the version under test corresponding to the existing business or interface can be judged. When the performance of the current version under test is lower than that of the previous historical version, the resource utilization data of the node can be obtained to analyze whether the resource indicators of the version under test are higher than those of the previous historical version. If so, the relevant resource indicators are considered to be the root cause of the node performance bottleneck.

[0081] It should be noted that issues that do not meet the definition of bottlenecks that require the current version under test to have performance no lower than that of the previous historical version, or that do not meet the requirement that the current version under test must meet business requirements, can be uniformly classified as other bottlenecks.

[0082] In some embodiments, as a refinement and extension of the specific implementation of the above embodiments, in order to fully illustrate the specific implementation process of this embodiment, some embodiments of this application also provide a software performance bottleneck location method. The difference between this method and the above embodiments is that, in determining whether the performance of the current version under test is lower than the performance of the previous historical version, it is specifically divided into two cases: the performance of the current version under test is higher than the performance of the historical version, and the performance of the current version under test is lower than the performance of the historical version, but the performance difference is less than the performance deviation coefficient. Figure 4 As shown, the method includes: S201. Extract historical version performance data from historical version performance data; S202. Calculate the performance difference between the performance of the version under test and the performance of historical versions; S203, Obtain the preset performance deviation coefficient; S204. When the performance difference is greater than or equal to the preset performance deviation coefficient, it is determined that the performance of the version under test is lower than that of the historical version. S205. When the performance difference is less than the preset performance deviation coefficient, determine that the performance of the version under test is not lower than the performance of the historical version.

[0083] To determine whether the performance of the version under test is lower than that of historical versions, after extracting the performance data of the version under test from the performance data of the version under test, the performance data of historical versions can be extracted first. Then, a performance difference is calculated based on the performance of the version under test and the performance of historical versions, where the performance difference is the ratio of the difference between the performance of the version under test and the performance of historical versions to the performance of historical versions. A preset performance deviation coefficient is then obtained, and the performance difference is compared with the preset performance deviation coefficient. If the performance difference is greater than or equal to the preset performance deviation coefficient, it is determined that the performance of the version under test is lower than that of historical versions.

[0084] For example, if the performance of the current version under test is lower than that of historical versions, but the performance difference is less than the performance deviation coefficient, it can be determined that the performance of the software version under test is not lower than that of historical versions. Therefore, the performance difference can be calculated based on the performance of the version under test and the performance of historical versions, where performance difference = (performance data of the current version under test – performance data of historical versions) / performance data of historical versions.

[0085] Next, obtain the preset performance deviation coefficient. The preset performance deviation coefficient represents the tolerance level for performance differences between two versions. It can be set according to the actual situation of the software and the type of performance metric value. Taking TPS as an example, the performance deviation coefficient can be set to 0.05. Then, by comparing the performance difference with the preset performance deviation coefficient, if the performance difference is greater than or equal to the preset performance deviation coefficient, it is determined that the performance of the version under test is lower than the performance of the historical version. Similarly, if the performance difference is less than the preset performance deviation coefficient, it is determined that the performance of the version under test is not lower than the performance of the historical version.

[0086] By applying the technical solutions of the above embodiments, the software performance bottleneck localization method described in the above embodiments is simple to operate and has high execution efficiency. Compared with the performance bottleneck localization process that requires combining various complex information such as software and hardware configuration, hardware resource utilization, and software thread stacks for investigation, the method can propose a brand-new general method for software performance bottleneck localization, extracting the key performance element of node time consumption, simplifying the bottleneck localization process, and improving bottleneck localization efficiency.

[0087] Furthermore, the method exhibits good versatility and wide applicability. Due to the varying characteristics of different industries, hardware resource types, and software architectures, software performance bottleneck identification is often limited. Many software domains focus on specific industry segments or programming languages, lacking a universal solution. This method, however, is based on the automatic analysis of end-to-end node time consumption, historical versions of node hardware and software configurations, and historical software performance data. Therefore, it possesses excellent versatility and can be applied to software across various industries, server models, programming languages, and technical architectures. In addition, the method can achieve performance bottleneck identification and root cause analysis while providing one-stop deployment, directly indicating the direction for performance optimization.

[0088] In some embodiments, as a specific implementation of the software performance bottleneck location method described in the above embodiments, some embodiments of this application also provide a software performance bottleneck location device, such as... Figure 5 As shown, the device includes: The data acquisition module is used to acquire load test data of the software version under test. The load test data includes the hardware and software configuration information of the link nodes of the software version under test and the performance data of the version under test. The hardware and software configuration acquisition module is used to query the historical configuration information corresponding to the software version under test; The configuration change item determination module is used to determine the configuration change items of the software version to be tested based on the stress test data and the historical configuration information. The performance bottleneck location module is used to locate the performance bottleneck node based on the changed configuration item and the request time of each node in the historical version link. The performance bottleneck node is the node where the request time of the software under test is different from the request time of the historical version. The root cause analysis module is used to combine resource utilization and the hardware and software configuration information to analyze the root cause of the performance bottleneck node, so as to generate performance bottleneck location information.

[0089] By applying the technical solutions of the above embodiments, the software performance bottleneck location device described in the above embodiments can obtain the load test data of the software version under test by performing software load testing, and query the historical configuration information corresponding to the software version under test. Then, based on the load test data and historical configuration information, the changed configuration items of the software version under test are determined. Then, based on the changed configuration items, combined with the request time of each node in the historical version link, the performance bottleneck node is located. Then, combined with resource utilization and hardware and software configuration information, the root cause of the bottleneck node is analyzed to generate performance bottleneck location information. The device can realize automatic location of the performance bottleneck of the entire software link and quickly identify the nodes with performance bottlenecks in the link. The device also automatically performs root cause analysis on the link nodes with performance bottlenecks to locate the source of the problem and indicate the direction of performance tuning. Through the device, the efficiency of software performance bottleneck location and performance tuning can be improved, the performance testing cost before software goes live can be reduced, and the processing speed of production performance problems after software goes live can be accelerated.

[0090] It should be noted that other corresponding descriptions of the functional units involved in the software performance bottleneck location device provided in the embodiments of this application can be found in the corresponding descriptions in the software performance bottleneck location method provided in the above embodiments, and will not be repeated here.

[0091] This application also provides a computer device, specifically a personal computer, server, network device, etc. The computer device includes a bus, processor, memory, and communication interface, and may also include input / output interfaces and a display device. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores location information. The network interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the various method embodiments.

[0092] Those skilled in the art will understand that the structure of the computer device described above is only a partial structure related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. A specific computer device may include more or fewer components, or combine certain components, or have different component arrangements.

[0093] In one embodiment, a computer-readable storage medium is also provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0094] In one embodiment, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0095] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0096] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods.

[0097] Any references to memory, database, or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc.

[0098] Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can take many forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0099] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchain. The processors involved in the embodiments provided in this application may be, but are not limited to, general-purpose processors, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc.

[0100] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0101] The embodiments described above are merely examples of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application.

Claims

1. A method for locating software performance bottlenecks, characterized in that, The method includes: Obtain load test data for the software version under test, including the hardware and software configuration information of the link nodes of the software version under test and the performance data of the version under test; Query the historical configuration information corresponding to the software version to be tested; Based on the stress test data and the historical configuration information, determine the changed configuration items for the software version to be tested; Based on the changed configuration items, and combined with the request time of each node in the historical version link, the performance bottleneck node is located. The performance bottleneck node is the node where the request time of the software under test version differs from the request time of the historical version. By combining resource utilization and the aforementioned hardware and software configuration information, the root causes of the performance bottleneck nodes are analyzed to generate performance bottleneck location information.

2. The method according to claim 1, characterized in that, Obtain load test data for the software version under test, including: Set a test strategy based on the software version to be tested. The test strategy can be a general test strategy or the test strategy of the previous version submitted for testing. Save the hardware and software configuration information of the link node of the software version under test to the database; Software load testing is performed based on the aforementioned testing strategy to record the performance data of the version under test during the software load testing process. The performance data of the version under test includes the request time, node resource utilization, and occurrence time of each node in the software link. The performance data of the version under test is saved to the database in chronological order of occurrence.

3. The method according to claim 2, characterized in that, Set up a testing strategy based on the version of the software to be tested, including: Obtain the software version to be tested; Based on the software version to be tested, query the database for historical version performance data of the same software. When no historical version performance data for the same software is found, the test strategy is set to the general test strategy. When querying historical version performance data of the same software, the test strategy is set to the test strategy of the previous version submitted for testing.

4. The method according to claim 1, characterized in that, Query the historical configuration information corresponding to the software version under test, including: Based on the software version under test, query the historical performance data of the same software version. Bottleneck judgment conditions are set based on the historical version performance data. The bottleneck judgment conditions include at least one of the historical version performance and preset business requirement indicators extracted from the historical version performance data. Extract the performance of the version under test from the performance data of the version under test; When the performance of the version under test is lower than that of the historical version, and / or the performance of the version under test does not meet the preset business requirement indicators, the historical configuration information corresponding to the software version under test is queried.

5. The method according to claim 4, characterized in that, When the performance of the version under test is lower than that of the historical version, the method further includes: Extract the historical time consumption of each node in the historical version link from the historical version performance data; Based on the historical time consumption, nodes with time consumption differences are filtered out from the performance data of the version under test. The nodes with time consumption differences are nodes in the link of the version under test whose request time is higher than the historical time consumption. Construct a first performance bottleneck node list based on the nodes with different time consumption; Calculate the time difference value of the time difference node, where the time difference value is the difference between the request time of the time difference node and the historical time. The first performance bottleneck node list is sorted according to the time difference value to obtain the second performance bottleneck node list; Locate the performance bottleneck node from the second list of performance bottleneck nodes.

6. The method according to claim 4, characterized in that, When the performance of the version under test does not meet the preset business requirement indicators, the method further includes: The request time for traversing all nodes in the internal link of the software version under test; A third performance bottleneck node list is constructed based on the request time, and the third performance bottleneck node list includes nodes whose request time exceeds a preset time threshold; Based on the time consumption values, the third performance bottleneck node list is sorted to obtain the fourth performance bottleneck node list. Locate the performance bottleneck node from the fourth list of performance bottleneck nodes.

7. The method according to claim 4, characterized in that, After extracting the performance data of the version under test from the performance data of the version under test, the method further includes: Extract historical version performance from the historical version performance data; The performance difference is calculated based on the performance of the version under test and the performance of the historical version. The performance difference is the ratio of the difference between the performance of the version under test and the performance of the historical version to the performance of the historical version. Obtain the preset performance deviation coefficient; When the performance difference is greater than or equal to the preset performance deviation coefficient, it is determined that the performance of the version under test is lower than that of the historical version.

8. The method according to claim 1, characterized in that, By combining resource utilization and the aforementioned hardware and software configuration information, the root cause of the performance bottleneck node is analyzed to generate performance bottleneck location information, including: Based on the performance bottleneck node, extract the configuration item of the version to be tested associated with the performance bottleneck node from the software and hardware configuration information; Retrieve the historical configuration items associated with the performance bottleneck node from the historical configuration information; By comparing the configuration items of the version under test with the historical configuration items, the configuration differences are determined; Based on the configuration differences, performance bottleneck location information containing change-type bottlenecks is generated.

9. The method according to claim 1, characterized in that, By combining resource utilization and the aforementioned hardware and software configuration information, the root cause of the performance bottleneck node is analyzed to generate performance bottleneck location information, including: Obtain the resource utilization rate of the performance bottleneck node; Calculate the resource indicators for the version under test based on the resource utilization rate; Extract historical version resource metrics from the historical version performance data; If the resource metrics of the version under test are higher than those of the historical version, performance bottleneck location information containing resource-related bottlenecks is generated.

10. A software performance bottleneck location device, characterized in that, The device includes: The data acquisition module is used to acquire load test data of the software version under test. The load test data includes the hardware and software configuration information of the link nodes of the software version under test and the performance data of the version under test. The hardware and software configuration acquisition module is used to query the historical configuration information corresponding to the software version under test; The configuration change item determination module is used to determine the configuration change items of the software version to be tested based on the stress test data and the historical configuration information. The performance bottleneck location module is used to locate the performance bottleneck node based on the changed configuration item and the request time of each node in the historical version link. The performance bottleneck node is the node where the request time of the software under test is different from the request time of the historical version. The root cause analysis module is used to combine resource utilization and the hardware and software configuration information to analyze the root cause of the performance bottleneck node, so as to generate performance bottleneck location information.

Images