Service methods, performance analysis methods, devices, servers, and storage media

Abstract

This invention discloses a service method performance analysis method, apparatus, server, and storage medium, including: acquiring the execution time and historical execution time data of the target service method; determining a dynamic execution time threshold based on the historical execution time data; when the execution time exceeds the dynamic execution time threshold, collecting call chain data of the target service method and CPU, memory, and I / O metrics data of the corresponding service nodes; and performing correlation analysis based on at least one of the call chain data, CPU metrics data, memory metrics data, and I / O metrics data, based on a preset rule base, to determine the root cause of the performance bottleneck. This invention enables the monitoring and analysis of the performance of the target service method based on dynamic thresholds and multi-dimensional metric data.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a service performance analysis method, apparatus, server, and storage medium. Background Technology

[0002] A method is a named sequence of statements in computer programming used to perform a specific task or achieve a specific function. In a microservice architecture, performance monitoring of service methods is crucial for ensuring system stability. However, existing technologies mainly suffer from problems such as inaccurate monitoring due to static thresholds, difficulty in locating the root cause of performance issues, and a lack of correlation between monitoring data and system resource metrics. Summary of the Invention

[0003] This invention aims to address at least one of the technical problems existing in the prior art. To this end, this invention proposes a service method performance analysis method, apparatus, server, and storage medium, capable of monitoring and analyzing the performance of a target service method based on dynamic thresholds and multi-dimensional index data.

[0004] In a first aspect, embodiments of the present invention provide a service method performance analysis method, comprising: Obtain the execution time and historical execution time data of the target service method; Based on the historical execution duration data, determine the dynamic execution duration threshold; If the execution time exceeds the dynamic execution time threshold, the call chain data of the target service method and the CPU, memory and I / O metrics of the corresponding service node are collected. Based on a preset rule base, correlation analysis is performed on at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data to determine the root cause of the performance bottleneck.

[0005] According to some embodiments of the present invention, determining the dynamic execution duration threshold based on the historical execution duration data includes: Within a preset moving window, the historical execution duration data is sorted to obtain an execution duration sequence; Based on the 95th percentile method, a dynamic execution time threshold is determined from the execution time sequence.

[0006] According to some embodiments of the present invention, the call chain data includes call duration, and the step of determining the root cause of performance bottlenecks by performing correlation analysis based on at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data according to a preset rule base includes: The percentage of call time is determined based on the call time and the execution duration.

[0007] According to some embodiments of the present invention, the CPU metric data includes at least one of system CPU utilization, process CPU utilization, and system load. The step of determining the root cause of performance bottlenecks by performing correlation analysis based on at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data according to a preset rule base further includes: The CPU load is determined based on at least one of the system CPU utilization, the process CPU utilization, and the system load; Based on a pre-defined rule base, the downstream service bottlenecks and computing bottlenecks are correlated and analyzed according to the proportion of call time and the CPU load to determine the root cause of the performance bottleneck.

[0008] According to some embodiments of the present invention, the memory metric data includes at least one of JVM heap memory utilization, JVM non-heap memory utilization, and system memory utilization, as well as JVM GC counts and JVM GC time. The step of determining the root cause of performance bottlenecks based on a preset rule base and performing correlation analysis according to at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data includes: The memory load is determined based on at least one of the JVM heap memory usage, the JVM non-heap memory usage, and the system memory usage. If the number of JVM GCs is greater than zero, determine the GC time percentage based on the JVM GC time and the execution duration. Based on a preset rule base, the memory bottleneck is analyzed in relation to the memory load and the GC time ratio to determine the root cause of the performance bottleneck.

[0009] According to some embodiments of the present invention, the step of performing correlation analysis on memory bottlenecks based on a preset rule base, according to the memory load and the GC time ratio, to determine the root cause of the performance bottleneck includes: When the memory load exceeds a preset first load threshold and the GC time percentage exceeds a preset first percentage threshold, the performance bottleneck is determined to be excessive memory pressure.

[0010] According to some embodiments of the present invention, the I / O metric data includes at least one of the following: active database connection pool count, database connection pool wait count, disk read / write speed, and network bandwidth utilization. The step of determining the root cause of performance bottlenecks based on a preset rule base and performing correlation analysis according to at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data includes: Based on a preset rule base, the database connection bottleneck is analyzed by correlation analysis based on at least one of the active connection count of the database connection pool, the waiting count of the database connection pool, the disk read / write rate, and the network bandwidth utilization rate, so as to determine the root cause of the performance bottleneck.

[0011] In a second aspect, embodiments of the present invention provide a service method performance analysis apparatus, comprising: The data acquisition module is used to obtain the execution time and historical execution time data of the target service method; The first determining module is used to determine a dynamic execution duration threshold based on the historical execution duration data; The data acquisition module is used to collect the call chain data of the target service method and the CPU, memory and I / O metrics data of the corresponding service nodes when the execution time exceeds the dynamic execution time threshold. The second determining module is used to determine the root cause of the performance bottleneck by performing correlation analysis based on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data, according to a preset rule base.

[0012] Thirdly, embodiments of the present invention provide a server, including a processor and a memory, wherein the memory stores a computer program, and the processor, when running the computer program, implements the above-described service method performance analysis method.

[0013] Fourthly, embodiments of the present invention provide a storage medium storing a computer program, which, when run, implements the above-described service method performance analysis method.

[0014] The embodiments of the present invention have at least the following beneficial effects: Determining dynamic execution duration thresholds based on historical execution duration data can adapt to changes in system performance baseline, significantly reducing false alarms and missed alarms. Based on a preset rule base, correlation analysis is performed on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data. Real-time analysis through multi-dimensional indicators can quickly locate the root cause of performance bottlenecks, reducing manual troubleshooting time.

[0015] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0016] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1This is a flowchart illustrating the steps of the service method performance analysis method according to an embodiment of the present invention. Figure 2 This is a schematic block diagram of the performance analysis device for the service method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the server in an embodiment of the present invention. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] In the description of this invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the stated number, and "above," "below," "within," etc. are understood to include the stated number. If "first," "second," etc. are used in the description, they are only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features or the order of the indicated technical features.

[0019] Please refer to Figure 1 This embodiment discloses a service method performance analysis method, including steps S100 to S400. It should be noted that the numbering of the steps in this embodiment is only for ease of review and understanding, and not to limit the execution order of the steps. The details of each step are described below: S100. Obtain the execution time and historical execution time data of the target service method; For example, a combination of Java annotations and Aspect-Oriented Programming (AOP) can be used to achieve automated monitoring and analysis of the performance of target service methods. For instance, a custom annotation can be defined, declared using Java's `@interface` keyword, to declaratively mark the target service method that needs performance monitoring. The custom annotation itself does not contain business logic, but it can carry metadata (such as optional parameters like monitoring granularity and whether historical data collection is enabled), thereby achieving semantic identification of the target service method.

[0020] In Spring AOP or other compatible AOP frameworks, write aspects that match the custom annotations. These aspects are configured to trigger before (@Before) and after (@AfterReturning / @After) advice before and after the execution of methods marked with custom annotations, or to use around (@Around) advice to more precisely capture the start and end times of the target service method's execution. The around advice records the start time of the target service method call and calculates the end time after the target service method completes its execution, thus obtaining the actual execution duration of this call. In this way, whenever the marked target service method is called, the corresponding execution duration can be automatically obtained without modifying the original business code, effectively decoupling the monitoring logic from the core business logic.

[0021] Furthermore, a historical execution time dataset is maintained, uniquely associated with the target service method. This dataset is indexed based on the method signature (including class name, method name, and parameter types) and continuously accumulates the execution time collected for each successful execution. For the current call, all previously completed and successfully recorded execution time data constitutes the "historical execution time data," which can be used for calculating subsequent dynamic execution time thresholds.

[0022] S200. Determine the dynamic execution duration threshold based on historical execution duration data; For example, traditional monitoring systems typically use static or fixed thresholds to determine anomalies in the execution time of service methods. However, such methods are difficult to adapt to dynamic changes in business load. For instance, during promotional events in e-commerce systems, due to factors such as a surge in concurrent requests and increased database pressure, the normal response time of service methods is usually significantly higher than usual. If the fixed thresholds set daily are still used, it is easy to trigger a large number of false alarms, which not only increases the operational burden but may also mask real performance problems. This embodiment, on the other hand, determines a dynamic execution time threshold based on historical execution time data, achieving dynamic monitoring with adaptive threshold adjustment.

[0023] In some application examples, step S200, determining the dynamic execution duration threshold based on historical execution duration data, includes: Within a preset moving window, the historical execution time data is sorted to obtain an execution time sequence; Based on the 95th percentile method, a dynamic execution time threshold is determined from the execution time sequence.

[0024] Specifically, a pre-defined time window or a fixed-capacity data structure (such as a circular buffer) is maintained for the target service method to continuously cache the execution time data collected from the most recent successful executions. For example, the buffer capacity can be configured to 1000, retaining only the execution time of the most recent 1000 calls, thus ensuring the timeliness and representativeness of the data used. Whenever the dynamic execution time threshold needs to be updated (e.g., after each new execution completes, or triggered at a fixed period), the historical execution time data in the buffer is sorted in ascending order to obtain an ordered execution time sequence. Then, using the 95th percentile method in statistics, the value located at the 95th percentile from the ordered execution time sequence is selected as the current dynamic execution time threshold. Taking 1000 samples as an example, the 950th data point after sorting (if counting from 0, the index is 949) is taken as the threshold. The 95th percentile threshold effectively reflects typical performance under current business load. It can exclude the interference of a small number of extremely slow requests (such as occasional high latency caused by network jitter) on the threshold, while retaining the response characteristics of the vast majority of normal requests. Therefore, when the execution time of a new call exceeds the dynamic execution time threshold, it can be determined that the call has potential performance anomalies, thereby triggering the subsequent root cause analysis process.

[0025] In this way, the dynamic execution duration threshold can be automatically adjusted according to changes in business traffic, system load and external dependency status, which helps to improve the accuracy of anomaly detection and effectively reduce false alarms or missed alarms caused by rigid thresholds. It is especially suitable for online service systems with obvious periodic or sudden traffic characteristics, such as e-commerce, financial transactions and content distribution.

[0026] Alternatively, in other application examples, the determination of the dynamic execution duration threshold can use an approximate quantile algorithm to reduce sorting overhead, which is suitable for high-frequency call scenarios; or it can be combined with a sliding time window (such as all calls within the last 5 minutes) to replace the fixed number of windows, in order to better adapt to services with large fluctuations in call frequency.

[0027] S300. When the execution time exceeds the dynamic execution time threshold, collect the call chain data of the target service method and the CPU, memory and I / O metrics data of the corresponding service node. For example, when the execution time of a target service method exceeds a dynamic execution time threshold, it can be preliminarily determined that the current call has a performance anomaly. At this time, multi-dimensional runtime data related to this call is collected to support subsequent automated correlation analysis. It is worth mentioning that in traditional operation and maintenance practices, when a service method responds slowly, operation and maintenance personnel usually need to log in to multiple independent systems such as the log system, host monitoring platform, and database performance view, and manually compare timestamps, call contexts, and resource metrics to infer the possible bottleneck location. This is not only inefficient and reliant on experience, but also, in a distributed microservice architecture, due to the complexity of the call chain and the heterogeneity of components, manual correlation analysis is prone to missing key clues. Although some application performance management (APM) tools on the market can automatically collect call chain data of service methods (such as those based on OpenTracing or OpenTelemetry standards), most APM tools only focus on application-layer metrics (such as method execution time, number of calls, or error rate), lacking the ability to correlate with underlying system resource metrics (such as CPU metrics, memory metrics, and I / O metrics) in real time and with fine granularity. Therefore, it is difficult to accurately distinguish whether performance problems originate from application code logic (such as inefficient algorithms and redundant loops) or infrastructure resource bottlenecks (such as CPU saturation, frequent garbage collection (GC) in memory, and disk I / O latency).

[0028] Therefore, this embodiment automatically collects call chain data and system resource metrics when an abnormal execution time is detected. The call chain data includes the complete call context information of the target service method, such as the method entry point, internal sub-call sequence, downstream service calls (e.g., remote calls initiated via Feign, Dubbo, etc.), and the call time at each stage. Call chain data can be obtained through bytecode enhancement, agent probes, or framework integration, conforming to the implementation mechanisms of mainstream APM tools. System resource metrics include CPU, memory, and I / O metrics of the service node where the target service method resides. It is worth noting that these metrics are not passively read after an anomaly occurs, but are actively collected during the execution of the target service method using a "snapshot" approach. Specifically, assuming the target service method starts execution at time T1 and ends execution at time T2, the following raw metrics of the host or container are sampled at time T1 and time T2 respectively. For example, the starting snapshot S1 (T1): {sysCpu (system CPU utilization): 20%, processCpu (process CPU utilization): 15%, heapUsed (heap memory utilization): 45%, activeDbConnections (database connection pool active connections): 8, ...}; the ending snapshot S2 (T2): {sysCpu: 85%, processCpu: 78%, heapUsed: 80%, activeDbConnections: 38, ...}.

[0029] Based on snapshot data from time T2 and time T1, the incremental or average changes in various resource metrics during the execution of the target service method are calculated, such as memory usage at time T2. The memory usage at time T1 is used to obtain resource consumption characteristics strongly correlated with this call. The calculated metric data is cached along with the original snapshot for subsequent analysis. When the execution time of this call exceeds a dynamic threshold, the call chain data and resource metric data corresponding to this call are extracted from the cache as input for root cause analysis.

[0030] S400, based on a preset rule base, performs correlation analysis based on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data to determine the root cause of performance bottlenecks.

[0031] For example, the rule base contains multiple diagnostic rules summarized and structured based on typical performance failure modes. Each rule defines a feature combination and corresponding root cause semantics of one or more indicators from call chain data, CPU indicator data, memory indicator data, and I / O indicator data under a specific performance bottleneck scenario. During root cause analysis, at least one of the collected call chain data, CPU indicator data, memory indicator data, and I / O indicator data is used as input and matched against the conditions of each rule in the rule base. Depending on the specific application requirements, the matching process can employ exact matching, threshold comparison, or fuzzy reasoning. Once the condition of a rule is met, the conclusion corresponding to that rule is triggered, i.e., the root cause of the performance bottleneck represented by the output rule is revealed.

[0032] Different rules can cover different data combinations across various dimensions, such as covering only call chain data, only CPU metrics data, call chain and memory metrics data, or CPU and I / O metrics data. This allows for the automatic identification of the fault mode best suited to the current anomaly scenario from multi-source, heterogeneous monitoring data, directly pinpointing the specific performance problem type, such as downstream service latency, CPU saturation, memory leaks, or database connection pool exhaustion, without requiring operations personnel to manually cross-reference multiple monitoring dashboards. Through a structured, pre-defined rule base based on experience-based knowledge, automated matching and reasoning based on multi-dimensional metrics data enables end-to-end automated correlation analysis from "anomaly detection" to "root cause localization," reducing reliance on human experience and improving troubleshooting efficiency.

[0033] In this way, determining the dynamic execution time threshold based on historical execution time data can adapt to changes in the system performance baseline, significantly reducing false alarms and false negatives. Based on a preset rule base, correlation analysis is performed on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data. Real-time analysis through multi-dimensional indicators can quickly locate the root cause of performance bottlenecks and reduce manual troubleshooting time.

[0034] In some application examples, the call chain data includes call time. Step S400: Based on a preset rule base, perform correlation analysis based on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data to determine the root cause of the performance bottleneck, including: determining the percentage of call time based on call time and execution duration.

[0035] For example, during the execution of a target service method, calls to one or more internal methods or external services are usually involved, such as local private methods, other business component methods, or remote service calls initiated through Feign, Dubbo, gRPC, etc. Based on the collected call chain data, the time consumption of each sub-call within the target service method can be analyzed in a fine-grained manner to identify potential code-level performance issues.

[0036] Specifically, the call chain data records the complete execution path of the target service method from entry to exit, including the start time, end time, method identifier (e.g., class name + method name), call type (local / remote), and nesting relationship of each sub-call. Based on the call chain data, the actual execution time of each sub-call can be extracted, i.e., the call duration, and the proportion of the call duration to the execution time of the target service method can be calculated, i.e., the call duration percentage. If the call duration percentage of a certain sub-call is significantly higher than a preset threshold (e.g., exceeding 70% or 80%), it can be preliminarily determined that the sub-call has performance anomalies, and it can be inferred that the performance bottleneck of the target service method may originate from its internal code logic problems.

[0037] The CPU metrics data include at least one of system CPU utilization, process CPU utilization, and system load. Step S400, based on a preset rule base, performs correlation analysis based on at least one of call chain data, CPU metrics data, memory metrics data, and I / O metrics data to determine the root cause of performance bottlenecks, and also includes: CPU load is determined based on at least one of system CPU utilization, process CPU utilization, and system load. Based on a pre-defined rule base, the system performs correlation analysis on downstream service bottlenecks and computing bottlenecks according to the proportion of call time and CPU load, thereby identifying the root cause of performance bottlenecks.

[0038] For example, CPU metrics include at least one of system CPU utilization, process CPU utilization, and system load. System CPU utilization characterizes the CPU activity at the system level; process CPU utilization characterizes the CPU utilization of JVM (Java Virtual Machine) processes. High process CPU utilization indicates that the application service itself is a computationally intensive task, such as large-scale encryption / decryption, serialization / deserialization, or complex business logic calculations; system load characterizes the average number of active processes in the system per unit time, reflecting the overall system pressure. When performing root cause analysis of performance bottlenecks, CPU load can be determined based on at least one of system CPU utilization, process CPU utilization, and system load. For example, when only system CPU utilization, process CPU utilization, or system load is collected, the collected data is considered CPU load; or, when the collected metrics include multiple of these metrics, the maximum value can be taken, or a corresponding threshold can be assigned to each metric, and when a metric exceeds the corresponding threshold, it is determined to be CPU load. Next, based on a pre-defined rule base, the system performs correlation analysis on downstream service bottlenecks and computational bottlenecks according to the proportion of call time and CPU load to determine the root cause of performance bottlenecks. For example, when the proportion of call time is greater than a first threshold and the CPU load is less than a first load threshold, the root cause of the performance bottleneck is determined to be a downstream service performance issue; or, when the proportion of call time is less than a second threshold and the CPU load is greater than a second load threshold, the root cause of the performance bottleneck is determined to be a performance issue of computationally intensive tasks. The proportion of call time can be used to reflect application-layer call behavior, while CPU load can be used to reflect system-layer resource status. By cross-analyzing application-layer call behavior (proportion of call time) and system-layer resource status (CPU load), different performance problems (such as waiting for external services and local computational overload) can be effectively distinguished, avoiding misjudgment based on a single indicator. This helps improve the accuracy of root cause localization and reduces the cost of manual intervention in troubleshooting, making it suitable for automated performance diagnosis scenarios of complex call chains in microservice architectures.

[0039] In addition, memory metrics data include at least one of JVM heap memory utilization, JVM non-heap memory utilization, and system memory utilization, as well as JVM GC counts and JVM GC time. Step S400, based on a preset rule base, performs correlation analysis based on at least one of call chain data, CPU metrics data, memory metrics data, and I / O metrics data to determine the root cause of performance bottlenecks, including: Determine the memory load based on at least one of JVM heap memory utilization, JVM non-heap memory utilization, and system memory utilization; When the number of JVM GC cycles is greater than zero, determine the percentage of GC time based on the JVM GC time consumption and execution duration; Based on a pre-defined rule base, the memory bottleneck is analyzed in relation to memory load and GC time percentage to determine the root cause of the performance bottleneck.

[0040] For example, in this embodiment, memory metrics are used to assess the memory resource usage of the Java Virtual Machine (JVM) and the host system during the execution of the target service method. JVM heap memory usage represents the proportion of currently used heap memory to the maximum heap capacity. If JVM heap memory usage rises rapidly in a short period and cannot be released through regular garbage collection (GC), it may reflect unreasonable memory usage behaviors such as excessively long object lifecycles, uncleaned caches, or memory leaks. JVM non-heap memory usage mainly covers the usage of areas such as Metaspace, thread stacks, and code caches. Abnormal growth in non-heap memory (such as continuous expansion of Metaspace) is usually related to class loader leaks, dynamically generating a large number of classes (such as reflection, CGLib proxies), or a surge in the number of threads, which may indicate abnormal runtime environment or framework configuration. System memory usage reflects the overall physical memory usage at the operating system level. When the system memory usage is too high, the operating system may trigger swap behavior, that is, swapping some memory pages to the swap space on disk to free up physical memory for other processes. Since disk I / O speed is much lower than memory access speed, swap behavior can significantly reduce the response performance of service methods and even trigger an avalanche effect.

[0041] Furthermore, JVM GC count refers to the total number of garbage collection events that occur during the execution of the target service method from start to finish; JVM GC time consumption refers to the total CPU time consumed by all GC activities during the execution from start to finish. It should be noted that the GC process typically triggers a "Stop-The-World" (STW) pause, where the JVM pauses all application threads to perform memory reclamation. Therefore, even if the business logic of the target service method itself has no performance defects, its execution time may still be significantly prolonged due to frequent or prolonged GC pauses, thus being misjudged as a code problem.

[0042] Therefore, this embodiment uses a pre-defined rule base to perform correlation analysis on memory bottlenecks based on memory load and GC time ratio to determine the root cause of performance bottlenecks. Specifically, memory load is determined based on at least one of JVM heap memory usage, JVM non-heap memory usage, and system memory usage. For example, when only JVM heap memory usage, JVM non-heap memory usage, or system memory usage is collected, the collected data is used as memory load. Alternatively, when the collected metrics include multiple of these metrics, the maximum value can be taken as memory load. Or, a corresponding threshold can be assigned to each metric, and when a metric exceeds the corresponding threshold, it is determined as memory load. Furthermore, when the number of JVM GC cycles is greater than zero, the GC time ratio is determined based on JVM GC time and execution duration. A higher GC time ratio indicates that the execution latency is more likely caused by GC pauses rather than the business logic itself. By combining the analysis of memory load and GC time percentage, it is possible to effectively distinguish between performance bottlenecks caused by code logic and those caused by GC activity, accurately locate memory-related performance bottlenecks, avoid misjudging JVM memory management behavior as code defects in target service methods, and improve the accuracy of root cause analysis and the efficiency of operation and maintenance decisions.

[0043] The above steps: Based on a pre-defined rule base, and according to memory load and GC time ratio, perform correlation analysis on memory bottlenecks to determine the root cause of performance bottlenecks, including: When the memory load exceeds the preset first load threshold and the GC time percentage exceeds the preset first percentage threshold, the performance bottleneck is determined to be excessive memory pressure.

[0044] For example, both the first load threshold and the first percentage threshold can be determined by static configuration or dynamic adaptive methods to balance deployment flexibility and adaptability to business scenarios.

[0045] For example, both the first load threshold and the first percentage threshold can be statically configured based on historical operational experience or system capacity planning. For instance, based on long-term operational data, the operations team can set the first load threshold as 85% heap memory utilization and the first percentage threshold as 30% of GC time consumption as a general benchmark. For example, separate circular buffers are maintained for memory load and GC time percentage. These buffers continuously cache the memory load and GC time percentage values ​​corresponding to the most recent (e.g., the last 1000) service method calls that were judged to be executed normally (i.e., without triggering abnormal alarms). Whenever the threshold needs to be updated (e.g., periodically triggered or when a new baseline is established), the historical data in the circular buffers are sorted in ascending order, and the current dynamic threshold is determined using the 95th percentile method. For example, for the memory load buffer, the 95th percentile value is taken as the dynamic first load threshold; for the GC time percentage buffer, the 95th percentile value is taken as the dynamic first percentage threshold. This is beneficial for adapting to fluctuations in business traffic. For example, during a major promotion, if the application's heap memory utilization generally increases to 80% due to cache preheating, while GC behavior is still normal, the dynamic threshold will automatically rise, avoiding false alarms caused by using the daily low load threshold. During the root cause analysis of performance bottlenecks, when the memory load exceeds a preset first load threshold and the GC time percentage exceeds a preset first percentage threshold, the performance bottleneck is determined to be excessive memory pressure. This means that frequent or prolonged garbage collection is caused by insufficient heap memory resources, leading to delays in service method execution. Similarly, the CPU metrics mentioned above and the I / O metrics below can be used to determine the corresponding dynamic thresholds based on the 95th percentile method to adapt to fluctuations in business traffic.

[0046] In some application examples, I / O metrics include at least one of the following: active database connection pool count, database connection pool wait count, disk read / write speed, and network bandwidth utilization. Step S400 involves performing correlation analysis based on a preset rule base, using at least one of the call chain data, CPU metrics, memory metrics, and I / O metrics to determine the root cause of performance bottlenecks, including: Based on a pre-defined rule base, the database connection bottleneck is analyzed by correlation analysis based on at least one of the following: the number of active connections in the database connection pool, the database connection pool wait count, the disk read / write rate, and the network bandwidth utilization rate, in order to determine the root cause of the performance bottleneck.

[0047] For example, I / O metrics are used to assess resource usage during the execution of the target service method, including interactions with external storage and the network. Specifically, the number of active connections in the database connection pool represents the number of database connections currently being used by the application, reflecting the intensity of concurrent usage of the database connection pool. When the number of active connections in the database connection pool approaches or reaches the maximum configured capacity of the connection pool, it indicates that the database connection resources are approaching saturation and may become a bottleneck in system throughput.

[0048] The database connection pool wait count refers to the number of database connections that need to be queued for during the execution of the target service method due to the lack of available connections. If the database connection pool wait count increases significantly (e.g., multiple waits occur in a single call), it indicates that the connection pool configuration is insufficient or the database response is slow, causing the request thread to be blocked and directly affecting the service response time.

[0049] Disk read / write speed is used to characterize the amount of data read and written to the disk per unit of time. For applications involving a large amount of local file reading and writing, log persistence, or temporary file processing, disk I / O may become a performance bottleneck. If the disk read / write speed remains high (such as approaching the disk hardware limit), it may lead to increased I / O wait times, thereby slowing down overall execution efficiency.

[0050] Network bandwidth utilization reflects the current proportion of traffic being used by a network interface. When application services involve high-frequency or large-volume remote communication (such as file upload and download, cross-service batch data synchronization, video streaming, etc.), network bandwidth may become a limiting factor. If bandwidth utilization remains close to 100% for an extended period, it may lead to TCP retransmissions, connection timeouts, or data transmission delays, indirectly affecting the execution time of service methods.

[0051] During the root cause analysis of performance bottlenecks, based on a pre-defined rule base, correlation analysis is performed on database connection bottlenecks according to at least one of the following: active connections in the database connection pool, database connection pool wait count, disk read / write speed, and network bandwidth utilization, to determine the root cause of the performance bottleneck. For example: If the number of active connections in the database connection pool is greater than or equal to a certain threshold percentage (such as 90%) of the maximum capacity of the connection pool and the database connection pool wait count is greater than zero, then the root cause of the performance bottleneck is insufficient database connection pool resources. If the disk read / write rate exceeds the preset I / O bandwidth threshold, and the target service method involves a large number of local file operations, then the root cause of the performance bottleneck is determined to be excessive disk I / O pressure. If network bandwidth utilization consistently exceeds a preset threshold, and call chain data shows large data transfer stages (such as API calls that return a large number of records), then the root cause of the performance bottleneck is determined to be limited network bandwidth.

[0052] In this embodiment, during the analysis process of determining the root cause of performance bottlenecks, automated correlation analysis is performed based on multi-dimensional indicator data such as call chain data, CPU indicator data, memory indicator data, and I / O indicator data to improve the accuracy of the analysis.

[0053] For example, in a specific scenario, the target service method is named OrderService.createOrder(). Assume the dynamic execution time threshold is 300 milliseconds, while the actual execution time is 1200 milliseconds. Clearly, the execution time exceeds the dynamic threshold. In this case, we collect the call chain data of the target service method and the corresponding system resource metrics data of the service node, as shown in the following example: The call chain data shows that the target service method contains a call to a sub-method named InventoryService, which takes 1100 milliseconds. Therefore, the call time percentage is approximately 1100 / 1200 ≈ 92%. CPU load was 25% at the start and 28% at the end; memory usage remained stable at 45% with no Full GC activity; the database connection pool had 10 active connections, while the total number of available database connections was 50.

[0054] Based on the preset rule base, since the call time accounts for approximately 92%, which is greater than the first percentage threshold (e.g., 70%), and the CPU load is less than the corresponding load threshold (e.g., 60%), and the number of active connections in the database connection pool is less than a certain threshold percentage of the total number of available database connections (e.g., 80%), then the root cause of the performance bottleneck can be determined to be the sub-method named InventoryService.

[0055] For example, in another specific scenario, suppose the dynamic execution time threshold of the target service method is 300 milliseconds, while the actual execution time is 800 milliseconds. Obviously, the execution time is longer than the dynamic execution time threshold. In this case, the call chain data of the target service method and the system resource indicator data of the corresponding service node are collected, as shown in the following example: The call chain data shows that there are only a few fast calls, with a total time of 150 milliseconds. Therefore, the call time percentage is approximately 150 / 800 ≈ 19%. CPU load was 70% at the start and 95% at the end; memory utilization was 60% at the start and 85% at the end, and multiple Young GC (Young Generation Garbage Collection) activities were detected; the number of active connections in the database connection pool was 8, while the total number of available database connections was 50.

[0056] Based on the preset rule base, if the average CPU load is greater than the corresponding load threshold (e.g., 60%), the average memory usage is greater than the preset threshold (e.g., 70%) and there is GC activity, while the call time ratio is approximately 19%, which is less than the first ratio threshold (e.g., 70%), and the number of active connections in the database connection pool is less than a certain threshold ratio of the total number of available database connections (e.g., 80%), then it is determined that the high CPU load is accompanied by a high memory usage ratio. It can be determined that the root cause of the performance bottleneck is that the target service method may be a computationally intensive task that consumes a lot of CPU resources, resulting in insufficient processing capacity, or that other processes on the same host machine consume a lot of CPU resources, resulting in insufficient processing capacity.

[0057] Based on the same technical concept as the above service method performance analysis method, please refer to Figure 2 This embodiment also provides a service method performance analysis device, including: The data acquisition module 110 is used to acquire the execution time and historical execution time data of the target service method; The first determining module 120 is used to determine the dynamic execution duration threshold based on historical execution duration data; The data acquisition module 130 is used to collect the call chain data of the target service method and the CPU, memory and I / O metrics data of the corresponding service node when the execution time exceeds the dynamic execution time threshold. The second determination module 140 is used to determine the root cause of performance bottlenecks by performing correlation analysis based on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data, according to a preset rule base.

[0058] The inventive concept of this service method performance analysis device embodiment is the same as that of the service method performance analysis method embodiment described above. Content not covered in this service method performance analysis device embodiment can be referred to in the service method performance analysis method embodiment described above, and will not be repeated here. Determining a dynamic execution duration threshold based on historical execution duration data can adaptively adapt to changes in the system performance baseline, significantly reducing false positives and false negatives. Based on a preset rule base, correlation analysis is performed using at least one of call chain data, CPU indicator data, memory indicator data, and I / O indicator data. Real-time analysis through multi-dimensional indicators can quickly pinpoint the root cause of performance bottlenecks, reducing manual troubleshooting time.

[0059] Please refer to Figure 3This embodiment also provides a server, including a processor 210 and a memory 220. The memory 220 stores a computer program, and the processor 210 executes the computer program to implement the above-described service method performance analysis method. The service method performance analysis method can be referred to above and will not be repeated here. Determining a dynamic execution time threshold based on historical execution time data can adapt to changes in the system performance baseline, significantly reducing false alarms and false negatives. Based on a preset rule base, correlation analysis is performed on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data. Real-time analysis through multi-dimensional indicators can quickly locate the root cause of performance bottlenecks and reduce manual troubleshooting time.

[0060] This embodiment also provides a storage medium storing a computer program. When the computer program is run, it implements the aforementioned service method performance analysis method. The service method performance analysis method can be referred to above and will not be repeated here. Determining a dynamic execution duration threshold based on historical execution duration data can adapt to changes in the system performance baseline, significantly reducing false positives and false negatives. Based on a preset rule base, correlation analysis is performed using at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data. Real-time analysis through multi-dimensional indicators can quickly pinpoint the root cause of performance bottlenecks, reducing manual troubleshooting time.

[0061] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. A service method performance analysis method, characterized in that, include: Obtain the execution time and historical execution time data of the target service method; Based on the historical execution duration data, determine the dynamic execution duration threshold; If the execution time exceeds the dynamic execution time threshold, the call chain data of the target service method and the CPU, memory and I / O metrics of the corresponding service node are collected. Based on a preset rule base, correlation analysis is performed on at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data to determine the root cause of the performance bottleneck.

2. The service method performance analysis method according to claim 1, characterized in that, The step of determining the dynamic execution duration threshold based on the historical execution duration data includes: Within a preset moving window, the historical execution duration data is sorted to obtain an execution duration sequence; Based on the 95th percentile method, a dynamic execution time threshold is determined from the execution time sequence.

3. The service method performance analysis method according to claim 1, characterized in that, The call chain data includes call duration. The method for determining the root cause of performance bottlenecks based on at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data, using a preset rule base, includes: The percentage of call time is determined based on the call time and the execution duration.

4. The service method performance analysis method according to claim 3, characterized in that, The CPU metric data includes at least one of system CPU utilization, process CPU utilization, and system load. The step of determining the root cause of performance bottlenecks by performing correlation analysis based on at least one of the call chain data, CPU metric data, memory metric data, and I / O metric data, according to a preset rule base, also includes: The CPU load is determined based on at least one of the system CPU utilization, the process CPU utilization, and the system load; Based on a pre-defined rule base, the downstream service bottlenecks and computing bottlenecks are correlated and analyzed according to the proportion of call time and the CPU load to determine the root cause of the performance bottleneck.

5. The service method performance analysis method according to claim 1, 3, or 4, characterized in that, The memory metrics data include at least one of JVM heap memory usage, JVM non-heap memory usage, and system memory usage, as well as JVM GC counts and JVM GC time. Based on a preset rule base, correlation analysis is performed on at least one of the call chain data, CPU metrics data, memory metrics data, and I / O metrics data to determine the root cause of performance bottlenecks, including: The memory load is determined based on at least one of the JVM heap memory usage, the JVM non-heap memory usage, and the system memory usage. If the number of JVM GCs is greater than zero, determine the GC time percentage based on the JVM GC time and the execution duration. Based on a preset rule base, the memory bottleneck is analyzed in relation to the memory load and the GC time ratio to determine the root cause of the performance bottleneck.

6. The service method performance analysis method according to claim 5, characterized in that, The system, based on a preset rule base, performs correlation analysis on memory bottlenecks according to the memory load and the GC time ratio to determine the root cause of performance bottlenecks, including: When the memory load exceeds a preset first load threshold and the GC time percentage exceeds a preset first percentage threshold, the performance bottleneck is determined to be excessive memory pressure.

7. The service method performance analysis method according to claim 1, 3, 4 or 6, characterized in that, The I / O metrics data include at least one of the following: active database connection pool count, database connection pool wait count, disk read / write speed, and network bandwidth utilization. The method of determining the root cause of performance bottlenecks based on a preset rule base and performing correlation analysis on at least one of the call chain data, CPU metrics data, memory metrics data, and I / O metrics data includes: Based on a preset rule base, the database connection bottleneck is analyzed by correlation analysis based on at least one of the active connection count of the database connection pool, the waiting count of the database connection pool, the disk read / write rate, and the network bandwidth utilization rate, so as to determine the root cause of the performance bottleneck.

8. A service method performance analysis device, characterized in that, include: The data acquisition module is used to obtain the execution time and historical execution time data of the target service method; The first determining module is used to determine a dynamic execution duration threshold based on the historical execution duration data; The data acquisition module is used to collect the call chain data of the target service method and the CPU, memory and I / O metrics data of the corresponding service nodes when the execution time exceeds the dynamic execution time threshold. The second determining module is used to determine the root cause of the performance bottleneck by performing correlation analysis based on at least one of the call chain data, CPU indicator data, memory indicator data, and I / O indicator data, according to a preset rule base.

9. A server, comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the processor runs the computer program, it is used to implement the service method performance analysis method as described in any one of claims 1 to 7.

10. A storage medium storing a computer program, characterized in that, When a computer program is run, it implements the service method performance analysis method as described in any one of claims 1 to 7.

Images