Performance bottleneck determination method and device

Abstract

The embodiment of the invention provides a performance bottleneck determination method and device. When the method is executed, firstly, real-time resource consumption data and real-time performance index data of tested equipment are obtained; determining whether the performance of the tested equipment is abnormal or not according to the real-time performance index data; if the performance is abnormal, determining candidate bottleneck resources according to the real-time resource consumption data; determining resource performance influence factors of the candidate bottleneck resources; wherein the resource performance impact factor of the candidate bottleneck resource indicates the contribution degree to the performance abnormality; and determining a performance bottleneck according to the resource performance impact factor of the candidate bottleneck resource, the performance bottleneck being a resource of which the resource performance factor accords with a preset condition in the candidate bottleneck resource. Therefore, the performance index data, the resource consumption data and other data which comprehensively reflect the real state of the tested equipment are utilized, the problem that the identification and positioning precision is insufficient due to the fact that a single index is utilized for identifying and positioning the performance bottleneck is solved, and the precision of identifying and positioning the performance bottleneck is improved.

Description

Technical Field

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

[0002] A performance bottleneck refers to a weak link in a server's overall performance caused by factors such as resource exhaustion, inefficient configuration, low code execution, or flawed architecture. These bottlenecks may occur at the hardware level, such as the central processing unit (CPU), memory, disk, or network, or at the software level, such as the database, middleware, or application code. Quickly and accurately identifying and locating performance bottlenecks is a prerequisite for optimizing server performance and improving service quality.

[0003] Existing technologies often identify and locate performance bottlenecks based on a single metric. However, as server system architectures become increasingly complex, distributed (e.g., microservice architecture), virtualized, and containerized, the dependencies and interaction paths between components become exceptionally intricate. A single metric cannot fully reflect the true state of the system. For example, a server's slow response may not be due to insufficient computing resources, but rather a bottleneck in another remote service or database it depends on. Therefore, how to quickly and accurately pinpoint the root cause of performance bottlenecks has become a pressing technical problem. Summary of the Invention

[0004] This application provides a method and apparatus for determining performance bottlenecks, which are used to accurately locate the root cause of performance bottlenecks.

[0005] In a first aspect, embodiments of this application provide a method for determining performance bottlenecks, the method comprising:

[0006] Acquire real-time resource consumption data and real-time performance index data of the device under test;

[0007] Based on the real-time performance index data, determine whether the device under test has abnormal performance;

[0008] If the performance is abnormal, candidate bottleneck resources are determined based on the real-time resource consumption data;

[0009] Determine the resource performance impact factor of the candidate bottleneck resource; wherein the resource performance impact factor of the candidate bottleneck resource indicates the degree of contribution to the performance anomaly;

[0010] Based on the resource performance impact factors of the candidate bottleneck resources, the bottleneck root cause of the performance bottleneck is determined. The bottleneck root cause is the resource among the candidate bottleneck resources whose resource performance factors meet preset conditions.

[0011] Optionally, determining whether the tested device has abnormal performance based on the real-time performance index data includes:

[0012] Based on the real-time performance index data and the performance baseline that matches the real-time performance index data, determine whether the device under test has abnormal performance.

[0013] The performance baseline is used as a benchmark to determine whether the real-time performance index data has experienced performance anomalies.

[0014] Optionally, the performance baseline includes a benchmark index data range, and determining whether the device under test has abnormal performance based on the real-time performance index data and the performance baseline matching the real-time performance index data includes:

[0015] If the real-time performance index data is not within the range of the benchmark index data, the performance of the device under test is determined to be abnormal.

[0016] If the real-time performance index data is within the range of the benchmark index data, the device under test is determined to be performing normally.

[0017] Optionally, the method for creating the performance baseline includes:

[0018] The performance baseline is created using historical performance data, or using performance data from the stable operation phase of the device under test.

[0019] Optionally, if the performance is abnormal, determining candidate bottleneck resources based on the real-time resource consumption data includes:

[0020] If the performance is abnormal, determine whether the real-time resource consumption data is under high pressure or is entering a high-pressure state; if so, determine the resource corresponding to the real-time resource consumption data as the candidate bottleneck resource.

[0021] The high-pressure state indicates that the real-time message resource data is greater than or equal to a preset resource threshold.

[0022] Optionally, determining the resource performance impact factor of the candidate bottleneck resource includes:

[0023] The resource performance impact factor of the candidate bottleneck resource is determined based on the resource saturation level, resource waiting queue, correlation with the performance index within a preset period of deterioration, and / or historical experience weight.

[0024] Optionally, determining the root cause of the performance bottleneck based on the resource performance impact factor of the candidate bottleneck resource includes:

[0025] Candidate bottleneck resources whose resource performance impact factors rank in the top n are identified as highly suspicious performance bottlenecks; where n is a positive integer.

[0026] Based on the highly suspicious performance bottleneck, the bottleneck indicator features corresponding to the highly suspicious performance bottleneck are matched from a preset bottleneck feature pattern library; the bottleneck feature pattern library includes bottleneck indicator features corresponding to multiple performance bottlenecks.

[0027] Based on the bottleneck indicator characteristics and the corresponding real-time data, the root cause of the bottleneck is determined from the highly suspicious performance bottlenecks.

[0028] Optionally, the real-time resource consumption data includes one or more of the following: CPU utilization, memory usage, disk I / O rate, disk I / O wait time, and network bandwidth usage.

[0029] Optionally, the real-time performance metrics data include one or more of the following: request response time, throughput, maximum concurrent user data, and error rate.

[0030] Secondly, embodiments of this application provide a performance bottleneck determination device, the device comprising:

[0031] The acquisition unit is used to acquire real-time resource consumption data and real-time performance index data of the device under test.

[0032] An anomaly determination unit is used to determine whether the device under test has a performance anomaly based on the real-time performance index data.

[0033] A candidate determination unit is used to determine candidate bottleneck resources based on the real-time resource consumption data if the performance is abnormal.

[0034] A factor determination unit is used to determine the resource performance impact factor of the candidate bottleneck resource; wherein the resource performance impact factor of the candidate bottleneck resource indicates the degree of contribution to the performance anomaly.

[0035] The bottleneck determination unit is used to determine the bottleneck root cause of the performance bottleneck based on the resource performance impact factor of the candidate bottleneck resources. The bottleneck root cause is the resource among the candidate bottleneck resources whose resource performance factor meets the preset conditions.

[0036] Thirdly, embodiments of this application provide a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions), which, when the computer program is run, causes the computer to perform the method in any of the possible implementations of any of the above aspects.

[0037] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program (also referred to as code or instructions) that, when run on a computer, causes the computer to perform the method in any of the possible implementations of the second aspect described above.

[0038] Fifthly, embodiments of this application provide a chip system including one or more processors for calling and executing instructions stored in memory, causing the methods in any of the above aspects or possible implementations to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0039] This application provides a method and apparatus for determining performance bottlenecks. When executing the method, firstly, real-time resource consumption data and real-time performance index data of the device under test are acquired; based on the real-time performance index data, it is determined whether the device under test has performance anomalies; if performance anomalies are found, candidate bottleneck resources are determined based on the real-time resource consumption data; the resource performance impact factor of the candidate bottleneck resources is determined; wherein, the resource performance impact factor of the candidate bottleneck resources indicates the degree of contribution to the performance anomaly; based on the resource performance impact factor of the candidate bottleneck resources, the performance bottleneck is determined, and the performance bottleneck is the resource among the candidate bottleneck resources whose resource performance factor meets preset conditions.

[0040] Performance metrics data quantifies the behavior and capabilities of the device under test (DUT), while resource consumption data assesses its load level and health status. Therefore, utilizing comprehensive data reflecting the true state of the DUT, such as performance metrics and resource consumption data, avoids the problem of insufficient accuracy in identifying and locating performance bottlenecks when using a single metric. Furthermore, when performance is abnormal, based on real-time resource consumption data, potential bottleneck resources are first identified. Then, based on the resource performance impact factors of these potential bottleneck resources, the contribution of each candidate resource to the current performance problem is quantified. Finally, using the resource performance impact factors of the candidate bottleneck resources, the candidate performance bottleneck is determined. This method avoids false alarms and missed alarms caused by dynamic scenarios or improperly set thresholds, which can result from relying solely on whether resources exceed static allocation limits or simple performance values ​​exceed thresholds. Therefore, it can further improve the accuracy of identifying and locating performance bottlenecks. Attached Figure Description

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

[0042] Figure 1 A flowchart illustrating a method for determining performance bottlenecks provided in this application embodiment;

[0043] Figure 2 This is a schematic diagram of a performance bottleneck determination device provided in an embodiment of this application. Detailed Implementation

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

[0045] First, the technical terms involved in the embodiments of this application will be introduced.

[0046] (a) Performance index data.

[0047] Performance metrics, also known as key performance indicators (KPIs), are used to quantify server behavior and capabilities, including but not limited to: request response time, throughput, maximum concurrent users, and error rate. Specifically, request response time measures server processing speed, throughput measures server processing capacity, maximum concurrent users measures server load capacity, and error rate measures server stability.

[0048] (ii) Resource consumption data.

[0049] Resource consumption data refers to resource usage data at the service hardware and operating system levels, used to determine the server's load level and health status. This includes, but is not limited to, CPU utilization, memory utilization, disk input / output (I / O) performance metrics, and network bandwidth usage metrics. Specifically, CPU utilization reflects the server's workload; memory utilization relates to data processing caching efficiency and whether the system faces the risk of memory overflow; disk I / O performance metrics reflect the performance of data-intensive applications; and network bandwidth usage metrics determine data transmission efficiency and the presence of network congestion.

[0050] Furthermore, CPU utilization-related resource consumption data includes: overall CPU utilization percentage, which measures the overall CPU workload; user-mode CPU utilization percentage (User Time), which measures the CPU time consumed by applications; kernel-mode CPU utilization percentage (System Time), which measures the CPU time consumed by the operating system kernel; CPU run queue length, which indicates the number of tasks waiting for the CPU to process and is a direct reflection of excessive CPU pressure; and I / O wait time percentage, which refers to the proportion of time the CPU waits for disk I / O operations to complete. If the I / O wait time percentage is greater than a preset percentage threshold, it indicates an I / O bottleneck.

[0051] Resource consumption data related to memory usage includes: total physical memory, used memory, available memory, and free memory percentage; cache and buffer usage; virtual memory swap space usage and swap activity frequency. Frequent virtual memory activity is a strong signal of severe physical memory shortage; page fault rate, especially main page faults, indicates the need to read data from disk, impacting performance.

[0052] Resource consumption data related to disk I / O performance metrics include: number of disk read / write operations per second and data volume per second; disk activity time percentage: the percentage of time the disk spends processing I / O requests, a consistently high percentage indicates disk saturation; average disk queue length: the number of I / O requests waiting for disk service, an excessively long queue indicates an I / O bottleneck; average service time and average wait time.

[0053] Resource consumption data related to network bandwidth usage metrics include: the data transmission / reception rate of each network interface; the number of network connections (e.g., active connections, waiting connections); the number of retransmissions or retransmission rate of Transmission Control Protocol (TCP), where high retransmissions may indicate network congestion or poor quality; the number of erroneous packets and packet loss rate of network interfaces; and network latency (e.g., measured by ping or application-specific probes).

[0054] (III) Performance bottleneck.

[0055] A performance bottleneck refers to a weak link in a server's overall performance that limits the performance of one or more components due to resource constraints, improper configuration, inefficient code execution, or flawed architecture. During performance testing, if a server fails to achieve preset performance targets under specific loads (e.g., excessively long response times or insufficient throughput), it typically indicates the presence of one or more performance bottlenecks in the system.

[0056] The following describes a performance bottleneck determination method provided by an embodiment of this application. It should be noted that the performance bottleneck determination method provided by this application can be applied in the performance testing process of a server, where the server is the device under test, and the executing entity can be a computing device (also known as a performance testing device) different from the server.

[0057] Appendix Figure 1 A flowchart of a performance bottleneck determination method provided in this application embodiment, the method comprising:

[0058] S110. Obtain real-time resource consumption data and real-time performance index data of the device under test.

[0059] In this embodiment, the performance testing device can configure a data acquisition period during the performance testing process, and based on this acquisition period, collect real-time resource consumption data and real-time performance index data of the device under test. The acquisition period can be 1 second, 5 seconds, or adjusted according to the sensitivity of the device under test.

[0060] To facilitate subsequent processing, the real-time resource consumption data and real-time performance index data collected by the performance testing equipment are accompanied by precise timestamps.

[0061] Furthermore, since the real-time resource consumption data and real-time performance index data directly acquired by performance testing equipment may contain noise, missing data, or inconsistent formats, preprocessing can be performed to ensure analysis quality. Specific preprocessing methods include, but are not limited to, the following:

[0062] Data cleaning and alignment are used to remove obviously outlier or invalid data points. This ensures that all metrics are strictly aligned over time, typically using a unified timestamp as a benchmark.

[0063] Missing value handling refers to handling individual data points missing due to network jitter or temporary data acquisition failures. Depending on the data characteristics, methods such as forward fill, backward fill, linear interpolation, or mean / median fill can be used. If the missing segment is too long, it may be necessary to mark the data for that period as unreliable.

[0064] Data smoothing: For certain indicators, such as instantaneous CPU utilization, high-frequency spikes may occur, affecting trend judgment. Methods such as moving averages and exponential smoothing can be used for smoothing to better reveal their short-term and long-term trends.

[0065] Data standardization: For subsequent analysis algorithms that are sensitive to data scale (such as certain machine learning models or weighted algorithms), indicators with different scales and different value ranges can be made comparable by minimax normalization (scaling them to an interval) or Z-score standardization (converting them into a distribution with a mean of 0 and a standard deviation of 1).

[0066] S120. Based on the real-time performance index data, determine whether the device under test has abnormal performance.

[0067] In this embodiment of the application, the performance testing tool can determine whether the device under test is experiencing performance abnormalities based on real-time performance metrics data. For example, the real-time performance metrics data are request response time and throughput. If the request response time is too long or the throughput does not meet the standard, the device under test is determined to be experiencing performance abnormalities.

[0068] In one example, to improve measurement accuracy, the performance testing equipment can determine whether the device under test is experiencing performance abnormalities based on real-time performance index data and a performance baseline that matches the real-time performance index data; wherein, the performance baseline is used as a benchmark for determining whether the real-time performance index data shows performance abnormalities.

[0069] The performance baseline can be a performance indicator data line that changes over time. If the point corresponding to the real-time performance indicator data is located on the performance baseline, it is determined that the real-time performance indicator data will not cause the device under test to malfunction. If the real-time performance indicator data deviates from the corresponding performance baseline, it is determined that the real-time performance indicator data will cause the device under test to malfunction.

[0070] In one example, the performance baseline includes a benchmark metric data range. For instance, the benchmark metric data range could be the mean of the performance metric data over time plus or minus m standard deviations, or the expected value range predicted using a more complex time-series forecasting model. Here, m is a positive integer. In this case, if the real-time performance metric data is outside the benchmark metric data range, the device under test is determined to be abnormal; if the real-time performance metric data is within the benchmark metric data range, the device under test is determined to be performing normally.

[0071] In another example, to avoid large errors caused by a single data point, a first preset time period can be used. If the performance metrics acquired within this first preset time period are not within the range of the baseline metrics, then the device under test is determined to be abnormal. For example, during the test, if the real-time monitoring response time is consistently higher than the baseline upper limit by X%, or the throughput is consistently lower than the baseline lower limit by Y%, or the error rate suddenly increases by more than Z times, then a performance abnormality is determined.

[0072] Furthermore, to improve judgment accuracy, the performance testing tool dynamically creates performance baselines. Specific methods include: creating performance baselines using historical performance data, or creating performance baselines based on performance data from the stable operation phase of the device under test during the current performance test. The use of dynamic baselines allows for automatic adaptation to the normal performance range of different servers under different load levels. This approach can be continuously enhanced and evolved through knowledge accumulation, better adapting to potential new technology stacks and unknown performance bottlenecks in the future. This "knowledge-driven" evolvability makes it more resilient and valuable for long-term applications compared to complex models that rely entirely on static rules or certain training-fixed, unchanging models.

[0073] It should be noted that in actual use, there may be multiple performance metric data points, and a corresponding performance baseline should be created for each performance metric data point. When performing anomaly detection, the real-time performance metric data is compared with the corresponding performance baseline for judgment.

[0074] It should be noted that the test device may exhibit abnormal performance or normal performance. If the performance is normal, the performance testing tool will not perform any further operations.

[0075] In this application and embodiment, by comparing real-time performance index data with the performance baseline, real-time monitoring and accurate judgment of performance anomalies are achieved.

[0076] S130. If the performance is abnormal, determine the candidate bottleneck resources based on the real-time resource consumption data.

[0077] If a performance anomaly occurs, the performance testing equipment will simultaneously analyze the absolute values ​​and trends of various resource consumption indicators at the time of the anomaly (and within the second preset time window prior to it).

[0078] It should be noted that the performance testing tool sets a high-stress state for each resource. A high-stress state indicates a state where resource consumption is greater than or equal to a preset resource threshold. For example, the high-stress state set by the performance testing tool for each resource is: total CPU utilization consistently >85%, memory utilization consistently >90%, disk busy rate consistently >80%, main network interface bandwidth utilization consistently >80%, CPU run queue length consistently >2 times the number of CPU cores, and disk I / O queue length consistently > a preset value (e.g., 4 or 5).

[0079] If real-time resource consumption data reflects that a resource is under high pressure or is entering a high-pressure state, then that resource is considered a candidate bottleneck resource, which is a potential resource that could cause performance abnormalities (also known as performance degradation).

[0080] Specifically, the indicator that real-time resource consumption data is entering a high-pressure state means that the difference between the real-time resource consumption data and the reference threshold corresponding to the high-pressure state is less than or equal to a preset difference, and that the real-time resource consumption data was on an upward trend before the current moment. The preset difference is a difference set by those skilled in the art as needed.

[0081] For example, if the total CPU utilization is consistently >85% between times T1 and T2, then the CPU utilization is determined to be a candidate bottleneck resource. As another example, if the total CPU utilization ranges from 40% to 83% between times T1 and T2, meaning that although the total CPU utilization is not under high pressure, the difference from the reference threshold is 2%, which is less than the preset difference of 5%. However, since the total CPU utilization is on an upward trend, i.e., the total CPU utilization is entering a high-pressure state, this resource is considered a candidate bottleneck resource.

[0082] It should be noted that T1 and T2 are different times.

[0083] This embodiment quickly and accurately identifies the potential sources of performance anomalies by analyzing resource consumption data in real time and under high pressure, providing a focal point for subsequent bottleneck root cause analysis. Furthermore, this approach can improve the processing efficiency of subsequent workflows.

[0084] S140. Determine the resource performance impact factor of the candidate bottleneck resource; wherein, the resource performance impact factor of the candidate bottleneck resource indicates the degree of contribution to the performance anomaly.

[0085] The Resource Performance Impact Factor (RPIF) is used to measure the contribution of candidate bottleneck resources to performance anomalies. The higher the RPIF of a resource, the more likely it is to cause current performance problems. The performance testing tool in this application can determine the root cause of the bottleneck based on the RPIF of candidate bottleneck resources.

[0086] In one implementation, the resource performance impact factor of the candidate bottleneck resource is determined based on the resource saturation level, resource waiting queue, correlation with the performance index within a preset period, and / or historical experience weight.

[0087] Resource saturation refers to how close the resource utilization rate is to its physical limit (usually 100%). The closer it is to the limit, the greater the potential impact. For example, saturation score = (current utilization rate / limit)^k, where k is an adjustment factor, and k is greater than 0.

[0088] Resource wait queue metrics, such as wait queue length, directly reflect the intensity of resource contention. Longer queues typically have a greater negative impact on performance. Examples include CPU run queue length, disk I / O queue length, and network buffer overflow.

[0089] Correlation with short-term synchronous deterioration of performance metrics: Within the time window when performance metrics begin to deteriorate, calculate the correlation between the trend of change in resource consumption data and the trend of performance deterioration (such as Pearson product-moment correlation coefficient, Spearman's rank correlation coefficient, or more simply, the number of occurrences of synchronous growth / deterioration). For example, if the response time increases sharply while the utilization rate of a certain resource also increases sharply, its correlation score is high.

[0090] Among them, the historical experience weight (optional) is a basic weight that can be assigned to certain resources based on historical data analysis or expert experience, which are more likely to become bottlenecks in specific application scenarios.

[0091] For example, if the resource consumption data is CPU utilization, then the RPIF of that resource is:

[0092] RPIF_cpu=w1*SaturationScore_cpu+w2*NormalizedRunQueue_cpu+w3*CorrelationScore_cpu_vs_ResponseTime+w4 BaseWeight*cpu

[0093] Wherein, RPIF_cpu is the CPU resource performance impact factor, SaturationScore_cpu is the CPU resource saturation score, NormalizedRunQueue_cpu is the CPU resource waiting queue score, CorrelationScore_cpu_vs_ResponseTime is the correlation score between the CPU and the short-term synchronous change of business response time deterioration, and BaseWeight*cpu is the historical experience weight of the CPU; w1, w2, w3, and w4 are weights, where w1, w2, w3, and w4 are all numbers greater than 0 and less than 1, and w1+w2+w3+w4=1. These weights can be preset or trained from historical data through machine learning methods.

[0094] This application's embodiments quantify the contribution of resources to performance anomalies by incorporating key factors such as resource saturation, wait queue length, and correlation with performance metrics using RPIF. This helps in the subsequent accurate identification of bottleneck root causes.

[0095] S150. Based on the resource performance impact factor of the candidate bottleneck resource, determine the bottleneck root cause of the performance bottleneck, wherein the performance bottleneck is the resource among the candidate bottleneck resources whose resource performance factor meets the preset conditions.

[0096] In one example, the preset condition might be the candidate bottleneck resource with the highest RPIF. That is, the performance testing equipment will use the resource with the highest RPIF as the root cause of the bottleneck.

[0097] In another example, the preset condition might be that the RPIF (Resource Performance Index) ranks among the top n candidate bottleneck resources. That is, the performance testing equipment can use the top n candidate bottleneck resources as the root cause of the bottleneck.

[0098] Furthermore, to improve the accuracy of the judgment, the performance testing equipment can identify candidate bottleneck resources whose resource performance impact factors rank in the top n as highly suspicious performance bottlenecks. Then, it matches the bottleneck feature patterns, also known as bottleneck indicator features, from a pre-set bottleneck feature pattern library. Based on the bottleneck indicator features and the corresponding real-time data, the performance testing equipment can determine the root cause of the bottleneck from among the highly suspicious performance bottlenecks.

[0099] The bottleneck feature pattern library predefines various typical server-side performance bottleneck scenarios and their corresponding multi-dimensional indicator feature combinations. These patterns are derived from industry experience, known problem cases, and in-depth analysis of system behavior.

[0100] For example, the bottleneck feature pattern library includes:

[0101] Mode 1: CPU computing power bottleneck. The bottleneck indicators are as follows: the total CPU utilization rate is consistently higher than the preset threshold (e.g., >90%), the CPU run queue length far exceeds the number of CPU cores, the user-mode CPU ratio is higher than the core-mode CPU ratio (if the application is computationally intensive) or the core-mode CPU ratio is higher than the user-mode CPU ratio (if the system calls are frequent or there are driver issues), the response time increases linearly with the CPU utilization rate, and the throughput may decrease after reaching the bottleneck period.

[0102] Mode 2: Physical memory exhaustion bottleneck. The bottleneck indicators for this mode are: available physical memory is below a preset threshold (e.g., <5%), frequent swapping activity (consistently high swap out), a significant increase in major page faults, sluggish overall system response, generally increased response time for various applications, and CPU utilization may decrease or fluctuate irregularly due to waiting for memory swapping.

[0103] Mode 3: Disk I / O Bottleneck (Specific Disk). The bottleneck characteristics of this mode are: the target disk's busy rate is consistently close to 100%, the disk I / O queue length is consistently high, the average I / O service time is significantly increased, the CPU's I / O wait time accounts for a higher percentage than other resources, and the response time of application modules that rely on this disk for read and write operations deteriorates sharply.

[0104] Mode 4: Network bandwidth / connection bottleneck. The bottleneck indicators for this mode are: the bandwidth utilization of the network interface for sending or receiving continuously approaches the link limit, network latency increases, packet loss rate rises, TCP retransmissions increase, response time of application modules that rely on network communication increases, or a large number of connection timeout errors occur.

[0105] Pattern 5: Application internal logic bottlenecks (e.g., lock contention, inefficient algorithms, slow external service dependencies). The bottleneck indicators for this pattern are: the utilization of major physical resources such as CPU, memory, disk, and network may not be extremely saturated, but the number of threads in a specific application remains consistently high, there are a large number of waiting states in the thread stack (e.g., WAITING, BLOCKED), or the call time for a specific API / service is abnormally high (this needs to be combined with APM tool data). Response time is high while throughput is low.

[0106] It should be noted that the embodiments of this application can use a preset matching algorithm to match the bottleneck feature patterns corresponding to the highly suspected performance bottlenecks from a preset bottleneck feature pattern library. The preset matching algorithm can employ rule-based logical judgment, fuzzy matching, or a simple scoring mechanism.

[0107] Furthermore, after identifying the bottleneck characteristics of highly suspicious performance bottlenecks, the performance testing equipment can generate and output a structured, easy-to-understand performance bottleneck diagnostic report. For example, the performance bottleneck diagnostic report includes: the exact time period in which the bottleneck occurred; the diagnosed bottleneck type (e.g., CPU computing power bottleneck, physical memory exhaustion bottleneck, disk X I / O read bottleneck, network egress bandwidth bottleneck, application A XX interface logic bottleneck, etc.); the candidate bottleneck resources used as the basis for judgment and their specific values ​​and status at that time; the status of other key resource consumption indicators and performance indicators related to the bottleneck pattern at the time of the bottleneck occurrence (including charts), or a brief assessment of the potential business impact of the bottleneck.

[0108] Furthermore, the performance bottleneck diagnostic report also includes: based on the matched bottleneck pattern, providing preliminary and possible root cause speculation as well as general optimization suggestions (for example, if it is a CPU bottleneck, it is recommended to check the processes / threads with high CPU consumption and optimize the code algorithm; if it is a memory bottleneck, it is recommended to check for memory leaks, adjust JVM parameters or increase physical memory, etc.).

[0109] It should be noted that, in this embodiment, the performance bottleneck diagnostic report can be presented in various formats, such as text, HTML, or integrated into the performance testing platform dashboard. Operations personnel can use this diagnostic report to determine the root cause of the bottleneck.

[0110] This application embodiment introduces a bottleneck feature pattern library, enabling more detailed classification of identified bottlenecks. The pattern library pre-stores bottleneck indicator features for various typical scenarios, such as CPU computing bottlenecks, memory exhaustion bottlenecks, specific disk I / O bottlenecks, network congestion bottlenecks, and even application internal logic bottlenecks. After identifying the dominant influencing factors through RPIF analysis, the system matches these factors and their related indicator states with the pattern library, thus not only determining that "a bottleneck exists," but also clearly identifying "what type of bottleneck." For example, even with high response time, this application embodiment can distinguish whether it is due to CPU overload (high CPU utilization, long run queue) or disk I / O waiting (high disk busy rate, long I / O queue, high CPU I / O waiting). This detailed differentiation capability provides far more specific and actionable guidance for subsequent targeted optimization measures than a vague "bottleneck occurrence."

[0111] Among them, performance index data can quantify the behavior and capabilities of the device under test, while resource consumption data can determine the load level and health status of the device under test. Therefore, by using performance index data and resource consumption data to comprehensively reflect the true status of the device under test, we can avoid the problem of insufficient identification and positioning accuracy when using a single index to identify and locate performance bottlenecks.

[0112] Furthermore, when performance is abnormal, based on real-time resource consumption data, potential bottleneck resources are first identified. Then, based on the resource performance impact factors of the potential bottleneck resources, the contribution of each candidate resource to the current performance problem is quantified. Finally, using the resource performance impact factors of the candidate bottleneck resources, the candidate performance bottleneck is determined. This method can avoid false alarms and missed alarms caused by the dynamic nature of the scenario or improper threshold settings due to the judgment logic of whether resources exceed the static allocation limit or simple performance value exceeds the threshold. Therefore, it can further improve the accuracy of identifying and locating performance bottlenecks.

[0113] Furthermore, this application embodiment can also determine whether performance indicators have truly deteriorated by using a performance baseline, and then combine the comprehensive status of multi-dimensional resource consumption data to quantify the contribution of each candidate resource to the current performance problem by calculating RPIF. Finally, this analysis result is matched and verified with a predefined "bottleneck feature pattern library". This series of combined measures can more accurately distinguish the real performance bottlenecks and effectively identify those bottlenecks caused by complex interactions of multiple factors that are difficult to detect by traditional methods.

[0114] Furthermore, the embodiments of this application also enable more proactive operation and maintenance through RPIF calculation and trend monitoring. For example, a server can be configured to issue an early warning when the RPIF value of certain critical resources continues to increase, showing an early trend towards a known bottleneck pattern, but before core performance indicators (such as user response time) completely exceed the SLA warning threshold. This early identification of a "sub-healthy" state helps the operation and maintenance team intervene before performance problems fully erupt and affect user experience, realizing a shift from "passive firefighting" to "proactive prevention," which is consistent with the concept of "predicting failures before they occur" mentioned in some literature.

[0115] In summary, this invention, through its innovative analysis methods and system design, demonstrates significant advantages in terms of accuracy, precision, efficiency, adaptability, and future potential in performance bottleneck diagnosis.

[0116] In addition, this application also provides a performance bottleneck determination device.

[0117] Appendix Figure 2 This is a schematic diagram of a performance bottleneck determination device provided in an embodiment of this application. The device 200 applies a performance testing equipment and includes:

[0118] The acquisition unit 201 is used to acquire real-time resource consumption data and real-time performance index data of the device under test;

[0119] The anomaly determination unit 202 is used to determine whether the device under test has a performance anomaly based on the real-time performance index data.

[0120] The candidate determination unit 203 is used to determine candidate bottleneck resources based on the real-time resource consumption data if the performance is abnormal.

[0121] The factor determination unit 204 is used to determine the resource performance impact factor of the candidate bottleneck resource; wherein the resource performance impact factor of the candidate bottleneck resource indicates the degree of contribution to the performance anomaly.

[0122] The bottleneck determination unit 205 is used to determine the bottleneck root cause of the performance bottleneck based on the resource performance impact factor of the candidate bottleneck resources. The bottleneck root cause is the resource among the candidate bottleneck resources whose resource performance factor meets the preset conditions.

[0123] Optionally, the anomaly determination unit 202 is specifically used for:

[0124] Based on the real-time performance index data and the performance baseline that matches the real-time performance index data, determine whether the device under test has abnormal performance.

[0125] The performance baseline is used as a benchmark to determine whether the real-time performance index data has experienced performance anomalies.

[0126] Optionally, the performance baseline includes a benchmark index data range, and determining whether the device under test has abnormal performance based on the real-time performance index data and the performance baseline matching the real-time performance index data includes:

[0127] If the real-time performance index data is not within the range of the benchmark index data, the performance of the device under test is determined to be abnormal.

[0128] If the real-time performance index data is within the range of the benchmark index data, the device under test is determined to be performing normally.

[0129] Optionally, the performance baseline can be created using historical performance data, or it can be created using performance data from the stable operation phase of the device under test.

[0130] The anomaly determination unit 202 is specifically used for: if the performance is abnormal, determining whether the real-time resource consumption data is in a high-pressure state or is entering a high-pressure state; if so, determining that the resource corresponding to the real-time resource consumption data is the candidate bottleneck resource;

[0131] The high-pressure state indicates that the real-time message resource data is greater than or equal to a preset resource threshold.

[0132] Optionally, the factor determination unit 204 is specifically used to determine the resource performance impact factor of the candidate bottleneck resource based on the resource saturation level, resource waiting queue, correlation with the performance index within a preset period and / or historical experience weight.

[0133] The bottleneck identification unit 205 is specifically used to: identify candidate bottleneck resources whose resource performance impact factors rank in the top n as highly suspicious performance bottlenecks; where n is a positive integer;

[0134] Based on the highly suspicious performance bottleneck, the bottleneck indicator features corresponding to the highly suspicious performance bottleneck are matched from a preset bottleneck feature pattern library; the bottleneck feature pattern library includes bottleneck indicator features corresponding to multiple performance bottlenecks.

[0135] Based on the bottleneck indicator characteristics and the corresponding real-time data, the root cause of the bottleneck is determined from the highly suspicious performance bottlenecks.

[0136] Optionally, real-time resource consumption data includes one or more of the following:

[0137] CPU utilization, memory usage, disk I / O rate, disk I / O wait time, and network bandwidth usage metrics.

[0138] Optionally, real-time performance metrics data may include one or more of the following:

[0139] Request response time, throughput, maximum concurrent user data, and error rate.

[0140] This application provides a performance bottleneck identification device. It first acquires real-time resource consumption data and real-time performance index data of the device under test (DUT). Based on the real-time performance index data, it determines whether the DUT has performance anomalies. If performance is abnormal, it identifies candidate bottleneck resources based on the real-time resource consumption data. It then determines the resource performance impact factor of each candidate bottleneck resource, where the resource performance impact factor indicates its contribution to the performance anomaly. Based on the resource performance impact factor of the candidate bottleneck resources, it identifies the performance bottleneck, which is the resource among the candidate bottleneck resources whose resource performance factor meets preset conditions. Therefore, by utilizing comprehensive data reflecting the true state of the DUT, such as performance index data and resource consumption data, it avoids the problem of insufficient identification and location accuracy when using a single indicator to identify and locate performance bottlenecks.

[0141] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0142] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0143] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0144] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the network device or terminal device in any of the foregoing method embodiments.

[0145] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0146] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0147] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.

[0148] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

Claims

1. A method for identifying performance bottlenecks, characterized in that, Applied to performance testing equipment, the method includes: The acquired real-time resource consumption data and real-time performance index data; Based on the real-time performance index data, determine whether the device under test has abnormal performance; If the performance is abnormal, candidate bottleneck resources are determined based on the real-time resource consumption data; Determine the resource performance impact factor of the candidate bottleneck resource; wherein the resource performance impact factor of the candidate bottleneck resource indicates the degree of contribution to the performance anomaly; Based on the resource performance impact factors of the candidate bottleneck resources, the bottleneck root cause of the performance bottleneck is determined. The bottleneck root cause is the resource among the candidate bottleneck resources whose resource performance factors meet preset conditions.

2. The determination method according to claim 1, characterized in that, The step of determining whether the tested device has abnormal performance based on the real-time performance index data includes: Based on the real-time performance index data and the performance baseline that matches the real-time performance index data, determine whether the device under test has abnormal performance. The performance baseline is used as a benchmark to determine whether the real-time performance index data has experienced performance anomalies.

3. The determination method according to claim 2, characterized in that, The performance baseline includes a benchmark index data range. Determining whether the device under test has abnormal performance based on the real-time performance index data and the performance baseline matching the real-time performance index data includes: If the real-time performance index data is not within the range of the benchmark index data, the performance of the device under test is determined to be abnormal. If the real-time performance index data is within the range of the benchmark index data, the device under test is determined to be performing normally.

4. The determining method according to claim 2 or 3, characterized in that, The method for creating the performance baseline includes: The performance baseline is created using historical performance data, or using performance data from the stable operation phase of the device under test.

5. The determination method according to claim 3, characterized in that, If the performance is abnormal, candidate bottleneck resources are determined based on the real-time resource consumption data, including: If the performance is abnormal, determine whether the real-time resource consumption data is under high pressure or is entering a high-pressure state; if so, determine the resource corresponding to the real-time resource consumption data as the candidate bottleneck resource. The high-pressure state indicates that the real-time message resource data is greater than or equal to a preset resource threshold.

6. The determination method according to claim 1, characterized in that, The determination of the resource performance impact factors of the candidate bottleneck resources includes: The resource performance impact factor of the candidate bottleneck resource is determined based on the resource saturation level, resource waiting queue, correlation with the performance index within a preset period of deterioration, and / or historical experience weight.

7. The determination method according to claim 1, characterized in that, The step of determining the root cause of the performance bottleneck based on the resource performance impact factor of the candidate bottleneck resource includes: Candidate bottleneck resources whose resource performance impact factors rank in the top n are identified as highly suspicious performance bottlenecks; where n is a positive integer. Based on the highly suspicious performance bottleneck, the bottleneck indicator features corresponding to the highly suspicious performance bottleneck are matched from a preset bottleneck feature pattern library; the bottleneck feature pattern library includes bottleneck indicator features corresponding to multiple performance bottlenecks. Based on the bottleneck indicator characteristics and the corresponding real-time data, the root cause of the bottleneck is determined from the highly suspicious performance bottlenecks.

8. The determination method according to claim 1, characterized in that, The real-time resource consumption data includes one or more of the following: CPU utilization, memory usage, disk I / O rate, disk I / O wait time, and network bandwidth usage metrics.

9. The determination method according to claim 1, characterized in that, The real-time performance metrics data include one or more of the following: Request response time, throughput, maximum concurrent user data, and error rate.

10. A performance bottleneck identification device, characterized in that, Application performance testing equipment, the apparatus comprising: The acquisition unit is used to acquire real-time resource consumption data and real-time performance index data of the device under test. An anomaly determination unit is used to determine whether the device under test has a performance anomaly based on the real-time performance index data. A candidate determination unit is used to determine candidate bottleneck resources based on the real-time resource consumption data if the performance is abnormal. A factor determination unit is used to determine the resource performance impact factor of the candidate bottleneck resource; wherein the resource performance impact factor of the candidate bottleneck resource indicates the degree of contribution to the performance anomaly. The bottleneck determination unit is used to determine the bottleneck root cause of the performance bottleneck based on the resource performance impact factor of the candidate bottleneck resources. The bottleneck root cause is the resource among the candidate bottleneck resources whose resource performance factor meets the preset conditions.

Images