A performance detection method, device, medium and product for service change code

Abstract

The application discloses a performance detection method and device for service change code, a medium and a product, and relates to the technical field of software testing. The method comprises the following steps: acquiring performance analysis data corresponding to a plurality of stable software version branches of a target service running online respectively and generating stable performance fingerprints corresponding to the stable software versions respectively; determining that a target software version branch of the target service has undergone offline code change, generating test performance analysis data corresponding to the target software version branch according to a new version of the target service code and a to-be-tested performance fingerprint corresponding to the test performance analysis data; selecting a target stable performance fingerprint from the stable performance fingerprints, comparing each to-be-tested function call association feature in the to-be-tested performance fingerprint with each benchmark function call association feature in the target stable performance fingerprint, and obtaining a performance detection result. The technical scheme of the embodiment of the application can realize automatic performance risk assessment and interpretable early warning, and improves delivery quality and stability.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and in particular to a method, device, medium, and product for performance testing of service change code. Background Technology

[0002] With the widespread adoption of microservice architectures and the need for rapid business iteration, the stability and predictability of service performance have become core indicators of software delivery quality. In production environments, accurately and promptly identifying performance regression issues introduced by code changes and pinpointing their root causes is a key challenge in ensuring service level agreements (SLAs).

[0003] Current technologies primarily rely on collecting performance analysis data during the testing phase and generating flame graphs for manual comparison, or setting extremely coarse-grained threshold rules for monitoring. However, existing solutions generally suffer from problems such as a severe lag in performance issue detection, low automation and high dependence on expert experience, inefficient use of massive amounts of performance analysis data, and a lack of interpretable evidence chains pointing to specific code changes. Consequently, they cannot automatically assess performance impact and provide clear remediation guidance before code integration or release. Summary of the Invention

[0004] This invention provides a method, device, medium, and product for performance testing of service change code, in order to solve the technical problem of difficulty in automating the assessment of performance regression risks and root cause localization after code changes.

[0005] According to one aspect of the present invention, a method for performance testing of service change code is provided, the method comprising: Obtain performance analysis data corresponding to multiple stable software version branches running online for the target service; the performance analysis data includes multiple call chains and the number of calls corresponding to each call chain, and each call chain includes multiple functions chained together in the order of calls; Using the stability performance analysis data of each stable software version branch, generate stability performance fingerprints corresponding to each stable software version. After determining that the target software version branch of the target service has undergone offline code changes, based on the new version of the target service code that matches the target software version branch, test performance analysis data corresponding to the target software version branch and test performance fingerprints corresponding to the test performance analysis data are generated. In the stable performance fingerprint, a target stable performance fingerprint is selected, and the associated features of each function call under test in the performance fingerprint under test are compared with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance test results that match the new version of the target service code.

[0006] According to another aspect of the present invention, a performance testing apparatus for service change code is provided, the apparatus comprising: The data acquisition module is used to acquire performance analysis data corresponding to multiple stable software version branches running online for the target service. The performance analysis data includes multiple call chains and the number of calls corresponding to each call chain. Each call chain includes multiple functions chained together in the order of calls. The performance fingerprint generation module is used to generate a stability performance fingerprint corresponding to each stable software version using stability performance analysis data from each stable software version branch. The performance fingerprint comparison module is used to generate test performance analysis data corresponding to the target software version branch and test performance fingerprints corresponding to the test performance analysis data after it is determined that the target software version branch of the target service has undergone offline code changes, based on the new version of the target service code that matches the target software version branch. The detection result generation module is used to select the target stable performance fingerprint from the stable performance fingerprints, and compare the associated features of each function call under test in the performance fingerprint under test with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance detection result that matches the new version of the target service code.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the performance detection method for service change code as described in any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the performance detection method for service change code as described in any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0010] The technical solution of this invention obtains performance analysis data corresponding to multiple stable software version branches running online for a target service. The performance analysis data includes multiple call chains and the number of calls corresponding to each call chain. Each call chain includes multiple functions chained together in call order. Using the stable performance analysis data of each stable software version branch, stable performance fingerprints corresponding to each stable software version are generated. After determining that the target software version branch of the target service has undergone offline code changes, test performance analysis data corresponding to the target software version branch and a test performance fingerprint corresponding to the test performance analysis data are generated based on the new version of the target service code matching the target software version branch. A target stable performance fingerprint is selected from the stable performance fingerprints, and the call association features of each function to be tested in the test performance fingerprint are compared with the call association features of each benchmark function in the target stable performance fingerprint to obtain performance detection results matching the new version of the target service code. This solves the technical problem of difficult automated assessment and root cause localization of performance regression risks due to code changes, achieving the beneficial effects of early detection of performance degradation and accurate automated early warning and localization.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a performance testing method for service change code provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of another performance testing method for service change code provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart of another performance testing method for service change code provided in Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of a performance testing device for service change codes provided in Embodiment 4 of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device that implements a performance detection method for service change code according to an embodiment of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1 This is a flowchart of a performance testing method for service change code provided in Embodiment 1 of the present invention. This embodiment can be applied to the situation of automatically evaluating the impact of code changes on service performance. The method can be executed by a performance testing device for service change code. The device can be implemented in hardware and / or software and is generally configured in an electronic device.

[0017] Correspondingly, such as Figure 1 As shown, the method includes: S110. Obtain performance analysis data corresponding to multiple stable software version branches running on the target service online; wherein, the performance analysis data includes multiple call chains and the number of calls corresponding to each call chain, and each call chain includes multiple functions chained together in the order of calls.

[0018] The performance analysis data can be understood as raw runtime data collected through continuous performance profiling tools. Its core content consists of a massive number of call chain samples. Each sample records a complete function call sequence (i.e., multiple functions chained together in the order of call) at a single moment of program execution, as well as the number of times that call chain appears within the sampling period.

[0019] In this embodiment, the first step is to collect performance analysis data from historical versions of the target service that are considered to be running stably and have not experienced performance incidents. This process is continuous or periodic. The acquired performance analysis data is standardized and transformed into a series of standardized call chain samples and their respective frequencies. Each call chain is a sequence of functions arranged in execution order, thus providing a unified and computable data foundation for subsequent analysis.

[0020] S120. Using the stability performance analysis data of each stable software version branch, generate stability performance fingerprints corresponding to each stable software version.

[0021] Among them, stable performance fingerprint can be understood as a structured and quantifiable data model constructed based on performance analysis data of the target service's stable online version. It is composed of multi-dimensional features and is stored in the baseline library as a reliable performance benchmark.

[0022] In this embodiment, performance data belonging to each stable version is obtained by analyzing the stability performance analysis data of each stable software version branch. A structured performance fingerprint that characterizes the runtime behavior of each version is constructed. Specifically, this process aggregates all call chain samples of the version to generate a prefix tree reflecting the overall call topology. Based on this tree, a series of multi-dimensional features are calculated, such as the distribution of core functions by resource consumption, the depth statistics of call chains, the grouping of hot function nodes by their call context, and the monitoring summary of several predefined key business paths. Combining this information constitutes the fingerprint representing the unique performance characteristics of the version.

[0023] S130. After determining that the target software version branch of the target service has undergone offline code changes, generate test performance analysis data corresponding to the target software version branch and test performance fingerprints corresponding to the test performance analysis data based on the new version of the target service code that matches the target software version branch.

[0024] In this embodiment, when a new code change is detected in a specific version branch of the target service (e.g., a developer submits a merge request), a dedicated test is conducted on the new version of the target service code that includes the new changes. This new version of the target service code is deployed in the test environment and subjected to simulated load. Performance analysis data generated during the test execution is collected, and a corresponding performance fingerprint is generated for this test version using the same method as for building stable fingerprints. This fingerprint represents the performance impact of the code change.

[0025] S140. Select the target stable performance fingerprint from the stable performance fingerprints, and compare the associated features of each function call under test in the performance fingerprint under test with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance test results that match the new version of the target service code.

[0026] In this context, correlation features can be understood as a series of structured metrics extracted from performance fingerprints to quantify the function call behavior patterns during service runtime. It is not a single metric, but rather a collective term for multiple features.

[0027] In this embodiment, after generating the fingerprint to be tested, a stable version fingerprint that is earlier in the timeline and most closely related to the currently changed code base is selected from the established stable performance fingerprint database as the comparison benchmark. Subsequently, various function call association features contained in the fingerprint to be tested, such as the structure of the call prefix tree and multi-dimensional feature vectors, are compared and analyzed in detail with the corresponding features in the selected benchmark fingerprint. By identifying the differences between the two, a detection result and evaluation report on the potential performance impact of the current code change is finally output.

[0028] The technical solution of this invention obtains performance analysis data corresponding to multiple stable software version branches running online for a target service. The performance analysis data includes multiple call chains and the number of calls corresponding to each call chain. Each call chain includes multiple functions chained together in call order. Using the stable performance analysis data of each stable software version branch, stable performance fingerprints corresponding to each stable software version are generated. After determining that the target software version branch of the target service has undergone offline code changes, test performance analysis data corresponding to the target software version branch and a test performance fingerprint corresponding to the test performance analysis data are generated based on the new version of the target service code matching the target software version branch. A target stable performance fingerprint is selected from the stable performance fingerprints, and the call association features of each function to be tested in the test performance fingerprint are compared with the call association features of each benchmark function in the target stable performance fingerprint to obtain performance detection results matching the new version of the target service code. This solves the technical problem of difficult automated assessment and root cause localization of performance regression risks due to code changes, achieving the beneficial effects of early detection of performance degradation and accurate automated early warning and localization.

[0029] Example 2 Figure 2 This is a flowchart of a performance testing method for service change code provided in Embodiment 2 of the present invention. This embodiment is based on and optimized from the above embodiments. Specifically, the operation of "obtaining performance analysis data corresponding to multiple stable software version branches running online in the target service" has been refined.

[0030] Correspondingly, such as Figure 2 As shown, the method includes: S210. Based on the exception log records of the target service, filter out the problematic software version branches from the multiple software version branches running online in the target service to obtain the stable software version branches corresponding to the target service.

[0031] In this embodiment, the first step in constructing a stable performance fingerprint is to select reliable software versions running on the target service line as data sources. Specifically, by querying the historical anomaly logs or fault records of the target service, problematic versions that have experienced known performance issues or incidents are identified and excluded from all software version branches running on the target service line. After this filtering, the remaining versions are identified as stable software version branches, which serve as a reliable foundation for subsequently constructing performance benchmarks.

[0032] S220. Obtain the stable operation period of each stable software version branch during its actual online operation, and obtain the stable operation log data of each stable software version branch during the stable operation period.

[0033] In this embodiment, after identifying the stable version branches, it is necessary to further collect operational data of these versions in a stable and normal state in the online production environment. To do this, it is necessary to analyze the historical operational records of each stable version to identify continuous time periods where no major failures occurred and performance remained stable. Then, detailed operational log data generated during these "stable" time periods are specifically extracted from the operations and maintenance monitoring system to provide a foundation for the next step of performance analysis.

[0034] S230. Based on the stable operation log data of each stable software version branch, obtain the performance analysis data corresponding to each stable software version branch.

[0035] In this embodiment, the acquired stable operation log data includes raw information collected by performance profiling tools. These logs are then parsed and structured, standardized performance analysis data is extracted using these tools. This typically means converting the raw log entries into clear call chains (i.e., function call sequences) and counting the total number of occurrences of each call chain within the sampling period, thereby forming a performance analysis data set that can be used for quantitative analysis and fingerprint construction.

[0036] S240. Using the stability performance analysis data of each stable software version branch, generate stability performance fingerprints corresponding to each stable software version.

[0037] S250. After determining that the target software version branch of the target service has undergone offline code changes, generate test performance analysis data corresponding to the target software version branch and test performance fingerprints corresponding to the test performance analysis data based on the new version of the target service code that matches the target software version branch.

[0038] Optionally, based on the above embodiments, generating test performance analysis data corresponding to the target software version branch according to the new version of the target service code that matches the target software version branch may include: Deploy the new version of the target service code in the test environment and apply a preset stress test load to the new version of the target service code; During the stress test, test run log data of the new version of the target service code is collected in real time, and test performance analysis data is extracted from the test run data.

[0039] Generally, when it's necessary to assess the performance impact of a new version of a service's code, the first step is to deploy the target service code, which includes the latest changes, in an independent, controlled test environment. Then, according to pre-defined scenarios and intensities, the target service is subjected to loads simulating real business pressure and concurrent requests. The aim is to stimulate its runtime behavior in a near-production environment, thereby exposing its potential performance characteristics or bottlenecks.

[0040] Generally, during the stress test, the accompanying monitoring and data collection tools will run simultaneously, continuously recording detailed operational logs of the target service under load. Subsequently, from these massive amounts of raw operational logs, a specific processing flow will be used to identify, clean, and extract structured performance analysis data, such as various function call paths and their sampling frequency. This data will serve as the core basis for evaluating the performance of this code change.

[0041] S260. Select the target stable performance fingerprint from the stable performance fingerprints, and compare the associated features of each function call under test in the performance fingerprint under test with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance test results that match the new version of the target service code.

[0042] Optionally, based on the above embodiments, selecting the target stable performance fingerprint from the stable performance fingerprint may include: From the stable performance fingerprints, select the stable performance fingerprints of the corresponding stable software version branch that are earlier than the target software version branch in time sequence, and form a target stable performance fingerprint candidate set; From the candidate set of target stable performance fingerprints, select the stable performance fingerprint that is closest to the code base of the corresponding stable software version branch and the target software version branch, and use it as the target stable performance fingerprint.

[0043] Generally, when assessing the potential performance impact of a new code change, the primary task is to find a reliable performance benchmark for comparison. To ensure this benchmark is valuable, the first step is to filter from an established performance fingerprint database those fingerprints corresponding to software versions that were confirmed to be stable and running earlier than the current version under test. These fingerprints represent the service's historically good performance before the current modification, and collecting them forms an initial candidate range for further refinement.

[0044] Generally, after determining the initial candidate pool, it's necessary to identify the most comparable benchmark. Therefore, the next step is to further analyze the historical stable versions corresponding to each candidate fingerprint, examining the degree of correlation between their code and the current target version that has undergone changes. For example, we can check if they are developed based on the same main branch or share most of the core code. Ultimately, the performance fingerprint of the historical stable version that is most similar to the current target version in terms of code and has the most direct correlation will be selected from the candidate set as the core comparison benchmark for this evaluation—the target stable performance fingerprint.

[0045] The technical solution of this invention filters out problematic software version branches from multiple online software version branches based on the abnormal log records of the target service to obtain stable software version branches. It then acquires the stable running time period and stable running log data of each stable software version branch during actual online operation, and obtains corresponding performance analysis data based on this log data. Furthermore, it uses the stable performance analysis data of each stable software version branch to generate stable performance fingerprints corresponding to each stable software version. After determining that the target software version branch of the target service has undergone offline code changes, it generates corresponding test performance analysis data and test performance fingerprints based on the matching new version of the target service code. Finally, it selects the target stable performance fingerprint from the stable performance fingerprints and compares the association features of each function call to be tested in the test performance fingerprint with the association features of each benchmark function call in the target stable performance fingerprint to obtain performance detection results matching the new version of the target service code. This technical solution solves the problem of automated assessment and root cause localization of performance regression risks due to code changes, achieving beneficial effects of early warning and accurate localization. In particular, through meticulous screening and data preparation, it ensures the high quality and reliability of the performance comparison benchmark from the source.

[0046] Example 3 Figure 3This is a flowchart of a performance testing method for service change code provided in Embodiment 3 of the present invention. This embodiment is based on and optimized from the above embodiments. Specifically, the operation of "using the stability performance analysis data of each stable software version branch to generate a stability performance fingerprint corresponding to each stable software version" has been refined.

[0047] Correspondingly, such as Figure 3 As shown, the method includes: S310. Obtain performance analysis data corresponding to multiple stable software version branches running on the target service online; wherein, the performance analysis data includes multiple call chains and the number of calls corresponding to each call chain, and each call chain includes multiple functions chained together in the order of calls.

[0048] S320. Obtain the current stability performance analysis data corresponding to the current stable software version branch, and construct the call chain prefix tree corresponding to the current stable software version branch based on the current stability performance analysis data; The call chain prefix tree is constructed using functions in the call chain as nodes and the chain relationships between functions in the call chain as edges. The node information of each function node includes the total number of calls to that node, as well as the total number of calls to all nodes contained in all subtrees rooted at that node.

[0049] In this embodiment, to transform massive amounts of discrete performance analysis data into a structured model capable of efficient querying and analysis, a call chain prefix tree is first constructed for the current stable software version. This call chain prefix tree is based on all collected function call chain samples, with each function as a node and the call relationships between functions as edges connecting the nodes. The root represents the common entry point of the service, and the path from the root node to any leaf node corresponds to a complete, actually observed call chain. Each node records two key values: one is the number of times the function itself has been sampled; the other is the total number of times all downstream call chains (i.e., its subtrees) starting from that function have been sampled. This helps to quickly identify the popularity of the entire call subtree.

[0050] S330. Based on the node information of each node, identify the number of hot function nodes in the call chain prefix tree, and calculate the proportion feature vector of each hot function node.

[0051] In this embodiment, based on the constructed call chain prefix tree, the most resource-intensive function nodes in this version, i.e., hotspot function nodes, are identified. Typically, each function node is sorted according to its own sampling count or the total sampling count of its subtree, selecting the top-ranked functions. Then, the proportion of the sampling count of these hotspot function nodes to the total sampling count is calculated, and these proportions are arranged in order to form a proportion feature vector. This proportion feature vector can intuitively reflect which hotspot function nodes are primarily concentrated during the runtime of this version.

[0052] S340. Generate a depth distribution statistical feature vector based on the depth information from the root node to each leaf node of the call chain prefix tree.

[0053] In this embodiment, in addition to focusing on hot function nodes, it is also necessary to analyze the complexity of the overall service call chain. To this end, the path length (i.e., depth) from the root node to each leaf node in the call chain prefix tree is statistically analyzed, and the frequency distribution of paths at different depths (e.g., depths 1, 2, 3, etc.) across all call chain samples is calculated. This distribution is quantified into a distribution statistical feature vector, for example, recording the proportion of paths at depth 1, the proportion of paths at depth 2, and so on. This depth distribution statistical feature vector is highly sensitive to whether the service logic has become verbose or whether the call chain has been unexpectedly lengthened.

[0054] S350. Based on all call paths from tree nodes to each hotspot function node in the call chain prefix tree, generate hotspot clusters corresponding to each hotspot function node.

[0055] In this embodiment, simply knowing which function nodes are hotspots is insufficient; it's also necessary to understand the business context in which these function nodes become hotspots. Therefore, for each identified hotspot function node, all different complete call paths reaching that function (i.e., all possible paths from the root of the tree to the hotspot function node) are extracted from the prefix tree. Then, based on the similarity of these paths, a clustering algorithm is used to group hotspot function nodes with similar call contexts, forming several hotspot function clusters. This helps distinguish the behavior of the same hotspot function node in different business scenarios, or to associate different but always occurring hotspot function nodes.

[0056] S360. Locate the paths of each core business function in the call chain prefix tree, and generate a critical path summary based on the proportion and depth information of each core business function path in the call chain prefix tree.

[0057] In this embodiment, to prioritize the performance of core business logic, it is necessary to monitor several predefined, most critical business links (i.e., core business function paths) separately. These predefined paths are located and matched within the constructed call chain prefix tree. For each successfully matched core path, two key metrics are calculated: the proportion of samples taken on that path relative to the total number of samples, and the average call depth of that path. Summarizing these paths and their metrics forms a critical path summary, which directly reflects the performance status of the core business logic.

[0058] S370. The call chain prefix tree, the proportion feature vector of each hot function node, the depth distribution statistical feature vector, the hot clusters and key path summaries corresponding to each hot function node are used as function call association features to form a stable performance fingerprint corresponding to the current stable software version.

[0059] In this embodiment, after the above operations, multiple dimensions of features have been extracted from the performance data of one version. Finally, the call chain prefix tree, hotspot function node proportion feature vector, depth distribution statistical feature vector, hotspot function node clusters, and critical path summary of this version are combined to form a complete, structured, stable performance fingerprint. This stable performance fingerprint uniquely represents the performance behavior characteristics of this version of the service at a specific time and will be stored in a baseline library for subsequent comparisons.

[0060] S380. After determining that the target software version branch of the target service has undergone offline code changes, generate test performance analysis data corresponding to the target software version branch and test performance fingerprints corresponding to the test performance analysis data based on the new version of the target service code that matches the target software version branch.

[0061] S390. Select the target stable performance fingerprint from the stable performance fingerprints, and compare the associated features of each function call under test in the performance fingerprint under test with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance test results that match the new version of the target service code.

[0062] Optionally, based on the above embodiments, the association features of each function call to be tested in the performance fingerprint to be tested are compared with the association features of each benchmark function call in the target stable performance fingerprint to obtain the performance detection result matching the new version of the target service code. This can include: The performance fingerprint to be tested is compared with the target stable performance fingerprint to identify the associated features whose change exceeds a preset threshold. Based on the identified correlation features where the magnitude of the change exceeds a preset threshold, and in conjunction with the code change list of the new target service code, the correlation features of the significant performance change caused by this code change are determined; Based on the correlation characteristics of the significant performance changes, a comprehensive performance regression risk score is calculated by quantitatively evaluating the results using predefined scoring rules. Based on the correlation characteristics of the significant performance changes, the performance regression risk score, and the code change list, a performance test result report is generated and output, which indicates the root cause of the performance regression, the scope of impact, and the repair suggestions.

[0063] Generally, after obtaining the performance fingerprint representing the new code version to be tested and the target stable performance fingerprint as a benchmark, a detailed comparative analysis of the two is required. This comparison process covers multiple dimensions of the performance fingerprint, such as the structural differences in the call chain prefix tree between the two fingerprints, the similarity of the stack depth distribution, changes in the set of hot function nodes, and changes in key business path metrics. By using preset change thresholds, it is possible to automatically identify which dimensions of feature metrics have undergone significant changes beyond the normal range, thereby filtering out abnormal correlation features that require special attention.

[0064] Generally, after identifying significant changes, it's necessary to correlate these performance changes with specific code modifications to pinpoint their root cause. At this stage, a list of specific code changes resulting from the current code change (i.e., which functions were modified) is used to cross-validate and match the anomalous performance characteristics identified in the previous step with the modified functions in the list. This process aims to confirm which significant changes in performance metrics are indeed directly caused by the current code change, thereby filtering out massive amounts of performance data noise and focusing on changes truly caused by the modifications.

[0065] Generally, after identifying the significant performance changes caused by code modifications, the next step is to quantify the impact of these changes. This is done based on a predefined scoring rule, which assigns different weights and deduction standards to different dimensions of performance changes. For example, different types of performance regressions, such as the emergence of new hotspot function nodes, the dilution of the proportion of original core functions, and the lengthening of critical business paths, will be quantified into specific scores according to their severity. Finally, these scores are accumulated to calculate a comprehensive score that reflects the overall performance regression risk.

[0066] Generally, after completing the risk assessment, a user-friendly analysis report is ultimately generated. This report integrates all the aforementioned analysis results, clearly identifies the main root cause of the performance regression (e.g., which newly added function became a hotspot), clearly explains its scope of impact (e.g., which key business path was affected, and how much the expected increase in latency was), and provides actionable fixes or optimization suggestions based on code changes and performance pattern changes, thus completing the entire process from automated analysis to decision support.

[0067] Optionally, based on the above embodiments, and based on the correlation characteristics of the significant performance changes, a comprehensive performance regression risk score can be calculated by performing a quantitative evaluation using predefined scoring rules, which may include: If the correlation features of the significant performance change indicate that the structural similarity between the test call chain prefix tree and the benchmark call chain prefix tree is lower than the first threshold, then the first preset score is added to the comprehensive score. If the correlation feature of the significant performance change indicates that the similarity between the statistical feature vector of the depth distribution to be tested and the statistical feature vector of the baseline depth distribution is lower than the second threshold, then the second preset score is added to the comprehensive score. Based on the number and proportion of newly added hotspot function nodes identified from the correlation features of the significant performance changes, a third preset score is accumulated for each newly added hotspot function node, up to a maximum of a first upper limit score; Based on the degree of dilution of the original hotspot function nodes identified in the correlation features of the significant performance changes, a fourth preset score is added to each diluted function, up to a maximum of a second upper limit score. Based on the degree of change in the critical path summary among the correlation features of the significant performance changes, a fifth preset score is added to each critical path whose change exceeds the third threshold, up to a maximum of the third upper limit score; The scores obtained from the above dimensions are summed to obtain the comprehensive performance regression risk score.

[0068] Generally, the evaluation process begins by assessing the impact of code changes on the overall service call structure. This is done by comparing the call chain prefix trees of the tested version and the baseline version to calculate the similarity in their topological structures. If this similarity falls below a pre-defined threshold, it indicates that the code change may have significantly restructured or altered the core call relationships of the service. Such structural changes are typically accompanied by high performance uncertainty, and therefore, a corresponding score is added to the overall risk score.

[0069] Generally, the next step is to assess the impact of the code change on the complexity of the service execution chain. This is done by comparing the depth distribution characteristics of all call chains between the tested version and the baseline version. If the similarity between the two depth distribution vectors is lower than another preset threshold, it means that the change has caused an overall shift in the average nesting level of function calls. This is usually an important signal that leads to changes in request processing latency, and therefore a corresponding risk score will be added to the overall score.

[0070] Generally, the scoring rules also focus on whether new performance bottlenecks have been introduced, examining which previously non-hotspot functions have become new hotspots with significant resource consumption in the version under test. Each such newly added hotspot function node, if its resource consumption exceeds a certain limit, will be considered a potential risk point, and a preset risk score will be added to each point. To prevent scoring distortion due to a large number of minor hotspots, an upper limit will be set for the cumulative score in this dimension.

[0071] Generally, a weakening of the performance of existing core hotspot function nodes is also a risk that needs attention. The scoring process examines whether the resource allocation of important hotspot function nodes in the baseline version has significantly decreased in the tested version. Each existing hotspot function node identified as experiencing this "dilution" indicates that its core position may have been shaken or interfered with by the addition of new code. Therefore, a corresponding risk score is added to each function, with a preset upper limit for the cumulative score in this dimension.

[0072] Generally, performance changes to predefined core business critical paths are specifically assessed. The system checks the metrics of each critical path one by one. If the change in path depth or execution percentage exceeds a certain threshold, the critical business link is considered to have been substantially affected by the code change. Each critical path that experiences such a significant change will have a corresponding risk score added to the overall score, and there is also an upper limit to the cumulative score for this dimension.

[0073] Generally, the risk scores calculated from multiple dimensions, including structural changes, changes in depth distribution, new hotspots, hotspot dilution, and changes in the critical path, are summed up. This final sum is the comprehensive performance regression risk score for this code change, providing a quantitative overall risk indicator to assess the likelihood and severity of performance issues introduced by the change.

[0074] In a specific embodiment, the predefined scoring rules can be instantiated as follows: if the tree edit distance between the call chain prefix tree of the fingerprint to be tested and the baseline fingerprint is greater than 45%, then 10 points are added to this indicator; if the KL divergence of the stack depth distribution statistical feature vectors of the two is greater than 0.4, then 20 points are added; for newly identified hot function nodes, if their resource share exceeds 5%, then 10 points are added to each new hotspot, but the maximum cumulative increase in this dimension is 30 points; for cases where existing hot function nodes are diluted, if the resource share of the top five hot function nodes in the baseline version decreases by more than 8%, then 5 points are deducted from each diluted function. The maximum deduction for this dimension is 20 points. For critical path summaries, if the change in a critical path exceeds ±25%, each critical path with such a change will receive an additional 10 points, with a maximum increase of 20 points for this dimension. Finally, the similarity of hotspot function node clusters is calculated. If the Jaccard similarity between two hotspot clusters is less than 0.5, each cluster below this similarity threshold will receive an additional 5 points, with a maximum increase of 20 points for this dimension. Finally, the scores accumulated from all the above dimensions are summed to obtain the comprehensive performance regression risk score for this code change, and the risk level can be further determined based on the range of this total score.

[0075] The technical solution of this invention involves acquiring performance analysis data corresponding to multiple stable software version branches running on the target service line. This performance analysis data includes multiple call chains and the number of calls corresponding to each call chain. Each call chain includes multiple functions chained together in call order. Then, current stable performance analysis data corresponding to the current stable software version branch is acquired, and a corresponding call chain prefix tree is constructed based on this data. This tree uses functions in the call chain as nodes and function chain relationships as edges. Each node records its total number of calls and the total number of calls in the subtree rooted at that node. Hotspot function nodes are identified based on the node information, and their proportion feature vectors are calculated. A depth distribution statistical feature vector is generated based on the depth information from the root node to each leaf node. Finally, the entire call path from the tree node to each hotspot function node is used to generate the feature vector. The process involves generating corresponding hotspot clusters; locating the paths of core business functions in the call chain prefix tree and generating critical path summaries based on their proportion and depth information; finally, using the call chain prefix tree, the proportion feature vectors of each hotspot function node, the depth distribution statistical feature vectors, the hotspot clusters, and the critical path summaries as function call association features to form a stable performance fingerprint corresponding to the current stable software version; after determining that the target software version branch of the target service has undergone offline code changes, generating corresponding test performance analysis data and performance fingerprints to be tested based on the matching new version of the target service code; selecting the target stable performance fingerprint from the stable performance fingerprints, and comparing the function call association features to be tested in the performance fingerprint with the baseline function call association features in the target stable performance fingerprint to obtain performance test results matching the new version of the target service code. This technical solution solves the problem of automated assessment and root cause localization of performance regression risks due to code changes, achieving beneficial effects of early warning and accurate localization. In particular, by transforming massive performance analysis data into structured multidimensional feature vectors and summaries, it realizes the computability and efficient comparative analysis of performance behavior patterns.

[0076] Example 4 Figure 4 This is a schematic diagram of a performance testing device for service change codes provided in Embodiment 4 of the present invention. Figure 4 As shown, the device includes: The data acquisition module 410 is used to acquire performance analysis data corresponding to multiple stable software version branches running on the target service line; wherein, the performance analysis data includes multiple call chains and the number of calls corresponding to each call chain, and each call chain includes multiple functions chained together in the order of calls; The performance fingerprint generation module 420 is used to generate a stability performance fingerprint corresponding to each stable software version using stability performance analysis data from each stable software version branch. The performance fingerprint comparison module 430 is used to generate test performance analysis data corresponding to the target software version branch and test performance fingerprint corresponding to the test performance analysis data after determining that the target software version branch of the target service has undergone offline code changes, based on the new version of the target service code that matches the target software version branch. The detection result generation module 440 is used to select the target stable performance fingerprint from the stable performance fingerprint, and compare the associated features of each function call to be tested in the performance fingerprint to be tested with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance detection result that matches the new version of the target service code.

[0077] The technical solution of this invention obtains performance analysis data corresponding to multiple stable software version branches running online for a target service. The performance analysis data includes multiple call chains and the number of calls corresponding to each call chain. Each call chain includes multiple functions chained together in call order. Using the stable performance analysis data of each stable software version branch, stable performance fingerprints corresponding to each stable software version are generated. After determining that the target software version branch of the target service has undergone offline code changes, test performance analysis data corresponding to the target software version branch and a test performance fingerprint corresponding to the test performance analysis data are generated based on the new version of the target service code matching the target software version branch. A target stable performance fingerprint is selected from the stable performance fingerprints, and the call association features of each function to be tested in the test performance fingerprint are compared with the call association features of each benchmark function in the target stable performance fingerprint to obtain performance detection results matching the new version of the target service code. This solves the technical problem of difficult automated assessment and root cause localization of performance regression risks due to code changes, achieving the beneficial effects of early detection of performance degradation and accurate automated early warning and localization.

[0078] Based on the above embodiments, the data acquisition module 410 is specifically used for: Based on the anomaly logs of the target service, filter out the problematic software version branches from the multiple software version branches running online in the target service to obtain the stable software version branches corresponding to the target service. Obtain the stable operation period of each stable software version branch during its actual online operation, and obtain the stable operation log data of each stable software version branch within the said stable operation period; Based on the stable operation log data of each stable software version branch, obtain the performance analysis data corresponding to each stable software version branch.

[0079] Based on the above embodiments, the performance fingerprint generation module 420 is specifically used for: Obtain the current stability performance analysis data corresponding to the current stable software version branch, and construct the call chain prefix tree corresponding to the current stable software version branch based on the current stability performance analysis data; The call chain prefix tree is constructed by using functions in the call chain as nodes and the chain relationships between functions in the call chain as edges. The node information of each function node includes the total number of calls to that node, as well as the total number of calls to all nodes contained in all subtrees rooted at that node. Based on the node information of each node, identify the number of hot function nodes in the call chain prefix tree, and calculate the proportion feature vector of each hot function node. Based on the depth information from the root node to each leaf node of the call chain prefix tree, a depth distribution statistical feature vector is generated. Based on the complete call paths from tree nodes to each hotspot function node in the call chain prefix tree, generate hotspot clusters corresponding to each hotspot function node; Locate the paths of each core business function in the call chain prefix tree, and generate a critical path summary based on the proportion and depth of each core business function path in the call chain prefix tree. The call chain prefix tree, the proportion feature vector of each hot function node, the depth distribution statistical feature vector, the hot clusters and key path summaries corresponding to each hot function node are used as function call association features to form a stable performance fingerprint corresponding to the current stable software version.

[0080] Based on the above embodiments, the performance fingerprint comparison module 430 is specifically used for: Deploy the new version of the target service code in the test environment and apply a preset stress test load to the new version of the target service code; During the stress test, test run log data of the new version of the target service code is collected in real time, and test performance analysis data is extracted from the test run data.

[0081] Based on the above embodiments, the detection result generation module 440 is specifically used for: From the stable performance fingerprints, select the stable performance fingerprints of the corresponding stable software version branch that are earlier than the target software version branch in time sequence, and form a target stable performance fingerprint candidate set; From the candidate set of target stable performance fingerprints, select the stable performance fingerprint that is closest to the code base of the corresponding stable software version branch and the target software version branch, and use it as the target stable performance fingerprint.

[0082] Furthermore, based on the above embodiments, the detection result generation module 440 may further include: The fingerprint comparison submodule is used to compare the fingerprint of the performance to be tested with the fingerprint of the target stable performance, and identify the associated features whose change exceeds a preset threshold. The significant change filtering submodule is used to determine the associated features of significant performance changes caused by this code change based on the identified correlation features where the change magnitude exceeds a preset threshold, combined with the code change list of the new target service code; The scoring submodule is used to perform quantitative evaluation based on the correlation characteristics of the significant performance changes, using predefined scoring rules, and calculate a comprehensive performance regression risk score. The output results submodule is used to generate and output a performance test result report that indicates the root cause of performance regression, the scope of impact, and repair suggestions, based on the correlation characteristics of the significant performance changes, the performance regression risk score, and the code change list.

[0083] Based on the above embodiments, the scoring submodule is specifically used for: If the correlation features of the significant performance change indicate that the structural similarity between the test call chain prefix tree and the benchmark call chain prefix tree is lower than the first threshold, then the first preset score is added to the comprehensive score. If the correlation feature of the significant performance change indicates that the similarity between the statistical feature vector of the depth distribution to be tested and the statistical feature vector of the baseline depth distribution is lower than the second threshold, then the second preset score is added to the comprehensive score. Based on the number and proportion of newly added hotspot function nodes identified from the correlation features of the significant performance changes, a third preset score is accumulated for each newly added hotspot function node, up to a maximum of a first upper limit score; Based on the degree of dilution of the original hotspot function nodes identified in the correlation features of the significant performance changes, a fourth preset score is added to each diluted function, up to a maximum of a second upper limit score. Based on the degree of change in the critical path summary among the correlation features of the significant performance changes, a fifth preset score is added to each critical path whose change exceeds the third threshold, up to a maximum of the third upper limit score; The scores obtained from the above dimensions are summed to obtain the comprehensive performance regression risk score.

[0084] The performance testing device for service change code provided in this embodiment of the invention can execute the performance testing method for service change code provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0085] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0086] Example 5 Figure 5 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0087] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0088] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0089] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as performing a performance detection method for service change code as described in any embodiment of the present invention, i.e.: Obtain performance analysis data corresponding to multiple stable software version branches running online for the target service; the performance analysis data includes multiple call chains and the number of calls corresponding to each call chain, and each call chain includes multiple functions chained together in the order of calls; Using the stability performance analysis data of each stable software version branch, generate stability performance fingerprints corresponding to each stable software version. After determining that the target software version branch of the target service has undergone offline code changes, based on the new version of the target service code that matches the target software version branch, test performance analysis data corresponding to the target software version branch and test performance fingerprints corresponding to the test performance analysis data are generated. In the stable performance fingerprint, a target stable performance fingerprint is selected, and the associated features of each function call under test in the performance fingerprint under test are compared with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance test results that match the new version of the target service code.

[0090] In some embodiments, a performance testing method for service change code as described in any of the embodiments of the present invention can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the performance testing method for service change code as described above as described in any of the embodiments of the present invention can be performed. Alternatively, in other embodiments, processor 11 can be configured by any other suitable means (e.g., by means of firmware) to perform the performance testing method for service change code as described in any of the embodiments of the present invention.

[0091] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0092] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0093] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0094] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0095] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0096] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0097] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0098] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for performance testing of service change code, characterized in that, include: Obtain performance analysis data corresponding to multiple stable software version branches running online for the target service; the performance analysis data includes multiple call chains and the number of calls corresponding to each call chain, and each call chain includes multiple functions chained together in the order of calls; Using the stability performance analysis data of each stable software version branch, generate stability performance fingerprints corresponding to each stable software version. After determining that the target software version branch of the target service has undergone offline code changes, based on the new version of the target service code that matches the target software version branch, test performance analysis data corresponding to the target software version branch and test performance fingerprints corresponding to the test performance analysis data are generated. In the stable performance fingerprint, a target stable performance fingerprint is selected, and the associated features of each function call under test in the performance fingerprint under test are compared with the associated features of each benchmark function call in the target stable performance fingerprint to obtain the performance test results that match the new version of the target service code.

2. The method according to claim 1, characterized in that, Obtain performance analysis data corresponding to multiple stable software version branches running online for the target service, including: Based on the anomaly logs of the target service, filter out the problematic software version branches from the multiple software version branches running online in the target service to obtain the stable software version branches corresponding to the target service. Obtain the stable operation period of each stable software version branch during its actual online operation, and obtain the stable operation log data of each stable software version branch within the said stable operation period; Based on the stable operation log data of each stable software version branch, obtain the performance analysis data corresponding to each stable software version branch.

3. The method according to claim 1, characterized in that, Using stability performance analysis data from each stable software version branch, generate stability performance fingerprints corresponding to each stable software version, including: Obtain the current stability performance analysis data corresponding to the current stable software version branch, and construct the call chain prefix tree corresponding to the current stable software version branch based on the current stability performance analysis data; The call chain prefix tree is constructed by using functions in the call chain as nodes and the chain relationships between functions in the call chain as edges. The node information of each function node includes the total number of calls to that node, as well as the total number of calls to all nodes contained in all subtrees rooted at that node. Based on the node information of each node, identify the number of hot function nodes in the call chain prefix tree, and calculate the proportion feature vector of each hot function node. Based on the depth information from the root node to each leaf node of the call chain prefix tree, a depth distribution statistical feature vector is generated. Based on the complete call paths from tree nodes to each hotspot function node in the call chain prefix tree, generate hotspot clusters corresponding to each hotspot function node; Locate the paths of each core business function in the call chain prefix tree, and generate a critical path summary based on the proportion and depth of each core business function path in the call chain prefix tree. The call chain prefix tree, the proportion feature vector of each hot function node, the depth distribution statistical feature vector, the hot clusters and key path summaries corresponding to each hot function node are used as function call association features to form a stable performance fingerprint corresponding to the current stable software version.

4. The method according to claim 1, characterized in that, Based on the new version of the target service code that matches the target software version branch, generate test performance analysis data corresponding to the target software version branch, including: Deploy the new version of the target service code in the test environment and apply a preset stress test load to the new version of the target service code; During the stress test, test run log data of the new version of the target service code is collected in real time, and test performance analysis data is extracted from the test run data.

5. The method according to claim 1, characterized in that, Select the target stable performance fingerprint from the stable performance fingerprint, including: From the stable performance fingerprints, select the stable performance fingerprints of the corresponding stable software version branch that are earlier than the target software version branch in time sequence, and form a target stable performance fingerprint candidate set; From the candidate set of target stable performance fingerprints, select the stable performance fingerprint that is closest to the code base of the corresponding stable software version branch and the target software version branch, and use it as the target stable performance fingerprint.

6. The method according to any one of claims 3-5, characterized in that, The associated features of each function call in the performance fingerprint under test are compared with the associated features of each benchmark function call in the target stable performance fingerprint to obtain performance test results that match the new version of the target service code, including: The performance fingerprint to be tested is compared with the target stable performance fingerprint to identify the associated features whose change exceeds a preset threshold. Based on the identified correlation features where the magnitude of the change exceeds a preset threshold, and in conjunction with the code change list of the new target service code, the correlation features of the significant performance change caused by this code change are determined; Based on the correlation characteristics of the significant performance changes, a comprehensive performance regression risk score is calculated by quantitatively evaluating the results using predefined scoring rules. Based on the correlation characteristics of the significant performance changes, the performance regression risk score, and the code change list, a performance test result report is generated and output, which indicates the root cause of the performance regression, the scope of impact, and the repair suggestions.

7. The method according to claim 1, characterized in that, Based on the correlation characteristics of the significant performance changes, a quantitative assessment is performed using predefined scoring rules to calculate a comprehensive performance regression risk score, including: If the correlation features of the significant performance change indicate that the structural similarity between the test call chain prefix tree and the benchmark call chain prefix tree is lower than the first threshold, then the first preset score is added to the comprehensive score. If the correlation feature of the significant performance change indicates that the similarity between the statistical feature vector of the depth distribution to be tested and the statistical feature vector of the baseline depth distribution is lower than the second threshold, then the second preset score is added to the comprehensive score. Based on the number and proportion of newly added hotspot function nodes identified from the correlation features of the significant performance changes, a third preset score is accumulated for each newly added hotspot function node, up to a maximum of a first upper limit score; Based on the degree of dilution of the original hotspot function nodes identified in the correlation features of the significant performance changes, a fourth preset score is added to each diluted function, up to a maximum of a second upper limit score. Based on the degree of change in the critical path summary among the correlation features of the significant performance changes, a fifth preset score is added to each critical path whose change exceeds the third threshold, up to a maximum of the third upper limit score; The scores obtained from the above dimensions are summed to obtain the comprehensive performance regression risk score.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the performance testing method for service change code as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a processor to execute the performance detection method for service change code as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, performs the performance testing method for service change code as described in any one of claims 1-7.

Images