An interface pressure test method, device and related equipment thereof

Abstract

The application provides an interface pressure test method, device and equipment, which infers a pressure test scene by using a vertical large model to generate a multi-dimensional scene vector such as load intensity, response delay and bottleneck identification, and then constructs an initial interface dependency graph based on a dependency matrix, calculates a weighted dependency strength by using a multi-type dependency relationship operator combined with a performance index, and performs decoupling processing on the weighted dependency strength based on a dependency type by using a relationship feature decoupling operator to suppress the interference between types, meanwhile, maps the scene vector to a node scene feature component according to the dependency strength and splices the node scene feature component with an interface basic feature to construct a node feature, and finally, based on the node feature, the decoupled dependency relationship and the weighted dependency strength, adopts an improved relationship graph convolution network to perform representation learning to obtain a weighted dependency graph, and performs call chain inference and dynamic pressure propagation path derivation based on the graph, so that more comprehensive and more fine coverage of the new interface pressure test scene is realized.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and more specifically, to an interface stress testing method, apparatus, and related equipment. Background Technology

[0002] With the increasing complexity of internet system architectures, especially the widespread application of microservices and distributed systems, the stability and performance of newly added interfaces have become key factors affecting the overall reliability of the system. Against this backdrop, stress testing, as an important means of evaluating system behavior under high concurrency and extreme loads, has become increasingly important. However, traditional stress testing methods exhibit significant limitations when faced with complex dependencies between interfaces and ever-changing business scenarios, making it difficult to meet the testing needs of rapid iteration and complex architectures.

[0003] In related technologies, stress testing of newly added interfaces mainly relies on rule-based testing tools (such as Apache JMeter and LoadRunner) and scenario generation methods based on load replay. For interface dependency modeling, call chain tracing tools (such as Jaeger and Zipkin) or service meshes (such as Istio) are typically used to identify simple call relationships; for stress propagation analysis, application performance management tools (such as New Relic and Dynatrace) are often used for static performance bottleneck localization. In addition, load generation methods based on time series prediction and some reinforcement learning techniques have also been used for scenario construction. Transfer learning has been attempted in a few optimization scenarios, but a systematic stress testing solution has not yet been formed.

[0004] However, current methods for stress testing newly added interfaces are difficult to effectively cover complex business scenarios, and lack dynamic adaptability in dependency modeling and stress propagation path analysis, resulting in insufficient test accuracy and efficiency. Summary of the Invention

[0005] This application provides an interface stress testing method, apparatus, and related equipment to address the problem that current new interface stress testing methods are unable to effectively cover complex business scenarios and lack dynamic adaptability in dependency modeling and stress propagation path analysis, resulting in insufficient testing accuracy and efficiency.

[0006] Firstly, an interface stress testing method is provided, including: A basic dataset for stress testing is constructed, which includes traffic feature vectors extracted from historical traffic data, interface feature vectors extracted from newly added interface business data, and a dependency matrix representing the dependency relationship and strength between interfaces. Based on the traffic feature vectors, the interface feature vectors and the dependency matrix, a vertical large model is used to perform stress test scenario inference to generate scenario vectors containing dimensions of load intensity, response latency and bottleneck identification. The initial interface dependency graph of the system is constructed based on the dependency matrix, and the weighted dependency strength of each dependency edge in the initial interface dependency graph is calculated using multi-type dependency relation operators based on the dependency type and associated performance indicators in the dependency matrix. Using relational feature decoupling operators, the weighted dependency strength is decoupled based on dependency type to suppress interference between different types of dependencies. The scene vector is mapped to the corresponding interface node according to the dependency strength in the dependency matrix to form scene feature components, which are then concatenated with the interface basic features extracted from the interface feature vector to construct node features. Based on the node features, the decoupled dependencies, and the corresponding weighted dependency strengths, an improved relational graph convolutional network is used to perform representation learning and updating on the initial interface dependency graph to obtain a weighted dependency graph. Based on the weighted dependency graph, call chain reasoning and dynamic pressure propagation path derivation are performed to output the key pressure propagation paths and bottleneck interfaces in the system.

[0007] Secondly, an interface stress testing device is provided, comprising: The vector generation module is used to construct a basic dataset for stress testing. The basic dataset includes traffic feature vectors extracted from historical traffic data, interface feature vectors extracted from newly added interface business data, and a dependency matrix that characterizes the dependencies and strengths between interfaces. Based on the traffic feature vectors, the interface feature vectors, and the dependency matrix, a vertical large model is used to perform stress test scenario inference to generate scenario vectors that include load intensity, response latency, and bottleneck identification dimensions. The strength calculation module is used to construct the initial interface dependency graph of the system based on the dependency matrix, and to calculate the weighted dependency strength of each dependency edge in the initial interface dependency graph based on the dependency type and associated performance index in the dependency matrix using multi-type dependency relation operators. The feature construction module is used to use relation feature decoupling operators to perform decoupling processing on the weighted dependency strength based on dependency type in order to suppress interference between different types of dependencies, and to map the scene vector to the corresponding interface node according to the dependency strength in the dependency matrix to form scene feature components, and to concatenate them with the interface basic features extracted from the interface feature vector to construct node features. The stress testing module is used to perform representation learning and updating of the initial interface dependency graph based on the node features, decoupled dependencies and corresponding weighted dependency strengths, using an improved relational graph convolutional network to obtain a weighted dependency graph. Based on the weighted dependency graph, it performs call chain reasoning and dynamic pressure propagation path derivation, and outputs the key pressure propagation paths and bottleneck interfaces in the system.

[0008] Thirdly, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the program, implements the steps of the method described in the first aspect.

[0009] Fourthly, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the steps of the method described in the first aspect.

[0010] Fifthly, a computer program product is provided, characterized in that it includes a computer program / instructions, which, when executed by a processor, follow the steps of the method described in the first aspect.

[0011] The interface stress testing method provided in this application constructs a basic dataset containing traffic feature vectors, interface feature vectors, and dependency matrices. It then uses a vertical large-scale model for stress test scenario inference to generate multi-dimensional scenario vectors, including load intensity, response latency, and bottleneck identification. Based on the dependency matrix, an initial interface dependency graph is constructed. Multi-type dependency operators combined with performance metrics are used to calculate weighted dependency strength. Relationship feature decoupling operators are then used to decouple the weighted dependency strength based on dependency type to suppress inter-type interference. Simultaneously, the scenario vectors are mapped to node scenario feature components according to dependency strength and concatenated with basic interface features to construct node features. Finally, based on node features, decoupled dependencies, and weighted dependency strength, an improved relational graph convolutional network is used for representation learning to obtain a weighted dependency graph. This graph is then used for call chain inference and dynamic pressure propagation path derivation. This achieves more comprehensive and refined coverage of newly added interface stress test scenarios, as well as more accurate and robust representation modeling of complex multi-type dependencies in the system, significantly improving the accuracy of stress testing and the effectiveness of system bottleneck identification. Attached Figure Description

[0012] Figure 1 This is a flowchart of an interface stress testing method provided by an exemplary embodiment of this application; Figure 2 This describes the overall architecture and technical process of the interface stress testing method provided in the exemplary embodiments of this application; Figure 3This is a flowchart of the complete sub-steps for constructing the basic dataset for stress testing in the interface stress testing method provided by the exemplary embodiment of this application; Figure 4 This is a flowchart of the sub-steps of stress test scenario reasoning and generation based on a vertical large model in the interface stress testing method provided by the exemplary embodiment of this application; Figure 5 This is a flowchart of the core analysis process and internal interaction mechanism of the interface stress testing method provided in the exemplary embodiment of this application, which is based on the weighted dependency graph to perform call chain reasoning and dynamic stress propagation path deduction. Figure 6 This is a schematic diagram of the structure of an interface stress testing device provided in an exemplary embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0013] The technical solutions in this application will now be described with reference to the accompanying drawings and specific embodiments. The described embodiments are some, but not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0014] The following is a description of the terms used in this application: Stress testing refers to testing a system or interface by simulating conditions such as high concurrency, high traffic, or extreme load to evaluate its performance, stability, and load-bearing capacity, and to identify potential performance bottlenecks and failure points.

[0015] In this application, "vertical large model" specifically refers to a large-scale machine learning model that is pre-trained or domain-adapted for a specific domain (here, the domain of system stress testing) to understand and reason about business scenarios and generate scenario features related to stress testing.

[0016] R-GCN (Graph Convolutional Network) is a type of neural network used to process graph-structured data, capable of modeling various types of relationships between nodes in a graph. In this scheme, it is used to model and learn the dependencies between interfaces.

[0017] Multi-type dependencies refer to different types of calls or dependencies between interfaces in a system, such as synchronous calls, asynchronous calls, RPC calls, etc. Different types of dependencies have different impact mechanisms on system performance.

[0018] Traffic feature vectors are a set of numerical features extracted from historical traffic data to characterize traffic behavior, typically including metrics such as request volume, response time, throughput, and error rate.

[0019] An interface feature vector is a set of numerical features used to describe the attributes of an interface itself, including the interface's protocol type, calling method, resource consumption parameters, and upstream and downstream interface dependency lists.

[0020] A dependency matrix is ​​a mathematical representation used to characterize the dependencies between interfaces in a system and their strength. The elements in the matrix typically represent the dependency weights and directions between interfaces.

[0021] Scenario reasoning refers to inferring the behavioral characteristics that a system may exhibit in different business scenarios, such as high or low load, response latency, and resource bottlenecks, based on historical data and system status.

[0022] Weighted dependency strength, in dependency modeling, is a quantitative value that reflects the degree of impact of dependencies on system performance by comprehensively considering multi-dimensional performance indicators such as response time, resource consumption, and error rate.

[0023] Decoupling refers to separating the influence of different types of dependencies during the modeling process to prevent one type of dependency (such as high-latency synchronous calls) from excessively affecting the representation of other types of dependencies, thereby improving the model's discriminative power and interpretability.

[0024] In a graph model, node features are the attribute vectors attached to each node (referring to the interface in this case), including the basic features of the interface itself and the scene-related features injected from the scene vector.

[0025] Transfer learning is a machine learning method that improves the learning efficiency and performance of a new task by transferring knowledge learned from one task or domain (source domain) to another related task or domain (target domain) that may have less data.

[0026] Traffic replay is a stress testing technique that records traffic data in a real environment and replays it in a test environment to simulate real user behavior and high-concurrency scenarios, thereby verifying system performance.

[0027] The critical stress propagation path refers to the dependency link in a system where stress or load is most likely to accumulate and propagate. It is usually the main path where performance bottlenecks occur, and identifying this path is of great significance for system optimization.

[0028] A bottleneck interface refers to a critical interface that, during stress testing, experiences a significant increase in response latency, a rise in error rate, or a decrease in throughput due to insufficient resources, limited processing capacity, or complex dependencies.

[0029] Edge scenarios refer to extreme or boundary conditions that are not common in normal business operations but may have a significant impact on system stability if they occur, such as sudden high concurrency or sudden failure of dependent services.

[0030] By refining the scenarios, based on the business scenarios generated from the initial reasoning, and by adjusting the weights and refining the processing of key features, more realistic and representative test scenarios are obtained.

[0031] Call chain reasoning refers to analyzing the path and logic of requests passing between interfaces based on the system's dependency graph, and inferring how pressure or load propagates and accumulates in the system.

[0032] Dynamic load adjustment, during stress testing, dynamically adjusts the intensity or mode of test traffic based on real-time system performance feedback (such as response time and throughput) to more realistically simulate the system's behavior under varying loads.

[0033] As described in the background section, although rule-based stress testing tools (such as Apache JMeter and LoadRunner), scenario generation techniques based on historical traffic replay, and interface dependency modeling schemes based on call chain tracing tools (such as Jaeger and Zipkin) and service meshes (such as Istio) already exist, these related technologies still have the following specific and profound shortcomings when dealing with complex and dynamic modern distributed systems: First, in terms of scenario reasoning and generation, related technologies generally face the problems of insufficient scenario coverage and weak modeling capabilities for extreme situations. Traditional tools rely heavily on preset rules or historical traffic patterns, making it difficult to automatically reason and generate business scenarios that exceed historical experience. In particular, they lack effective modeling methods for edge scenarios under high concurrency, sudden traffic scenarios, and extreme abnormal scenarios with multiple coupled factors, resulting in insufficient representativeness of test cases and an inability to fully expose the potential risks of the system in real and complex environments.

[0034] Second, in terms of dependency modeling, related technologies have significant shortcomings in handling the dynamic coupling and decoupling of multiple types of dependencies. While call chain tracing and service mesh can characterize the call relationships between interfaces, they typically simplify multiple dependency types, such as synchronous, asynchronous, and RPC, into a single link relationship, lacking the ability to model the differentiated performance impact mechanisms of different types of dependencies. More importantly, these technologies cannot dynamically capture changes in dependency strength with factors such as load and resource status, nor can they effectively decouple the mutual interference between different types of dependencies, leading to errors in the identification of critical bottleneck paths in complex dependency networks.

[0035] Third, in terms of pressure propagation analysis and optimization, existing solutions are mostly based on static or semi-static analysis strategies, which cannot achieve dynamic and accurate propagation path derivation and bottleneck location. Although mainstream APM tools and load balancing strategies can identify explicit performance bottlenecks, their analysis often lags behind real-time changes in system state and lacks the ability to quantitatively reason about the probability of pressure propagation along dependency chains, the propagation intensity, and the mutual influence between paths. This makes it difficult to proactively and accurately predict and verify the critical path of pressure transmission during testing, and optimization measures often fall into a passive situation of "treating the symptoms rather than the root cause."

[0036] Fourth, regarding testing efficiency and adaptability, the relevant technologies lack efficient knowledge transfer and adaptive capabilities when dealing with new interfaces or business changes. Although transfer learning has been applied in some scenarios, it has not yet been systematically integrated into the stress testing process. As a result, the generation of test scenarios for new interfaces often requires accumulating data and experience from scratch, which is time-consuming and results in low initial test accuracy. It is impossible to fully utilize the testing experience and performance patterns of existing interfaces in the system, making it difficult to meet the urgent need for testing efficiency in rapid business iterations.

[0037] In summary, the relevant technologies have systemic capability gaps in key aspects such as scene generation, dependency modeling, path reasoning, and adaptive optimization, which restricts the depth and effectiveness of stress testing in complex and dynamic systems.

[0038] To address the aforementioned problems in related technologies, this application provides an interface stress testing method that can systematically solve the problems of incomplete scenario coverage, inaccurate dependency modeling, imprecise path analysis, and insufficient adaptive capabilities in stress testing by constructing a multi-dimensional basic dataset, integrating the scene reasoning capabilities of a vertical large model, and improving graph neural network modeling technology. Specifically, by constructing a basic dataset containing traffic feature vectors, interface feature vectors, and dependency matrices, and using a vertical large model to fuse and infer multi-dimensional features to generate scenario vectors covering load intensity, response latency, and bottleneck identification, an initial interface dependency graph is constructed based on the dependency matrix. Weighted dependency strength is calculated using multi-type dependency relationship operators combined with performance metrics, and interference between different types of dependencies is suppressed by relationship feature decoupling operators. Simultaneously, scenario vectors are mapped to node scenario feature components based on dependency strength and concatenated with basic interface features to construct node features. Finally, based on node features, decoupled dependencies, and weighted dependency strength, an improved relational graph convolutional network is used for representation learning to obtain a weighted dependency graph. Call chain inference and dynamic pressure propagation path derivation are then performed based on this graph. These techniques work together to achieve more comprehensive and refined coverage of new interface stress testing scenarios, and more accurate and robust representation modeling of complex multi-type dependencies in the system. This enables proactive and accurate identification of key pressure propagation paths and system bottleneck interfaces, significantly improving the targeting, effectiveness, and forward-looking nature of stress testing and system risk identification.

[0039] Specifically, the specific process of the interface stress testing method provided in this application embodiment is as follows: Figure 1 As shown, it includes the following steps 110 to 140.

[0040] Step 110: Construct a basic dataset for stress testing. The basic dataset includes traffic feature vectors extracted from historical traffic data, interface feature vectors extracted from newly added interface business data, and a dependency matrix that characterizes the dependencies and strengths between interfaces. Based on the traffic feature vectors, interface feature vectors, and dependency matrix, use a vertical large model to perform stress test scenario reasoning and generate scenario vectors that include load intensity, response latency, and bottleneck identification dimensions.

[0041] Dependency Matrix It is a mathematical tool for characterizing the dependencies between interfaces and their strength. Each element in the matrix... Representative interface With Interface The strength of the dependency is denoted as [-1, 1]. Positive values ​​represent upstream dependencies (0-1 interval), and negative values ​​represent downstream dependencies (-1-0 interval). The absolute value of the value reflects the strength of the dependency, providing a quantitative basis for subsequent graph structure modeling.

[0042] In some exemplary embodiments, a base dataset for stress testing is constructed, including: Extract time series, request volume, response time, throughput, and error rate data from the request logs and performance metrics contained in historical traffic data to form a traffic feature vector; From the configuration parameters and upstream and downstream dependencies contained in the newly added interface business data, extract the protocol, call type, resource consumption and dependent interface list to form an interface feature vector; Based on upstream and downstream dependencies, a dependency matrix is ​​constructed to represent the direction and strength of dependencies between interfaces in matrix form.

[0043] In this embodiment, the construction of the basic dataset is systematically collected and organized in three sub-steps. Historical traffic data is collected by parsing system logs, extracting metrics including three core log fields: request timestamp, request volume, and response time, as well as derived performance metrics such as throughput and error rate. The collection of new interface business data is achieved through configuration parsing and dependency analysis tools, focusing on configuration parameters such as protocol type, calling method, and resource usage ratio, and determining the upstream and downstream interface sets through call chain analysis. The dependency matrix is ​​constructed with interfaces as nodes, determining edge connections by analyzing the call relationships between interfaces, and quantifying dependency strength based on metrics such as call frequency and response time.

[0044] Figure 2 The overall architecture and technical process of the interface stress testing method shown in this application embodiment include: Step 1: The dataset construction module processes the input data and outputs the traffic feature vector, interface feature vector, and dependency matrix required for subsequent processes.

[0045] Next, proceed to step 2: Vertical Large Model Module (Business Scenario Inference and Scenario Generation). This module receives the output from step 1 and refines the scenario through traffic inference operators ( ) and edge case derived operators ( The data is processed to generate a scene vector S containing multi-dimensional information such as load intensity, response latency, and bottleneck identification. This scene vector will be used for node feature construction in subsequent steps.

[0046] Then, the process moves to step 3: the dependency modeling module (initial graph construction and relational graph convolutional network). This module is one of the core innovations of this method, mainly completing three tasks: first, utilizing multi-type dependency operators ( The system employs three main methods: First, it calculates weighted dependency edges based on multi-dimensional indicators such as response time and resource consumption. Second, it decouples relationships to form sub-dependency graphs of various types and decoupling weights, thus suppressing interference between different types of dependencies. Third, it constructs node features by fusing interface basic features with scene vectors according to dependency strength to form node features X. The graph representation output by the module is then fed into an improved relational graph convolutional network (R-GCN) for learning. The improvements are mainly reflected in the comprehensive utilization of weighted dependency edges, type decoupling, and training constraints to enhance the network's propagation and aggregation capabilities.

[0047] Based on the output of step 3, step 4: the path reasoning module performs call link reasoning and dynamic pressure propagation path derivation, and finally outputs the key pressure propagation path and bottleneck interface of the system.

[0048] Step 5: The transfer learning engine receives critical path and bottleneck interface information from Step 4, as well as test feedback F from subsequent steps. Its internal mechanism is based on weighted optimization and parameter updates driven by path weights and bottleneck interface priorities, which is used to continuously optimize the model.

[0049] Finally, in step 6: the traffic replay stress test (traffic replayer) module generates a test load based on the optimized model, performs high-concurrency stress testing, and outputs actual test feedback F, which includes indicators such as response time, throughput, error rate, and resource utilization. This feedback will flow back to step 5 to form a closed-loop optimization process.

[0050] Figure 3 This demonstrates the complete sub-step process for building the foundational dataset for stress testing. The process is user-triggered and comprises three main stages: Data Acquisition: Historical traffic data acquisition and new interface business data collection are performed in parallel. The former extracts historical requests and performance metrics from system logs, while the latter collects configuration parameters and dependency information for new interfaces.

[0051] Dataset construction: Integrate the two types of collected data to form a structured basic traffic dataset.

[0052] Data preprocessing: The constructed dataset is subjected to anomaly detection, cleaning, time series alignment and noise reduction to provide high-quality input for subsequent feature extraction and model inference.

[0053] For example, in some exemplary implementations, building the base dataset for stress testing includes a sub-step of acquiring historical traffic data (step 1.1). In this sub-step, historical traffic data is first acquired from the log information of the existing system. This historical traffic data mainly includes two aspects of metrics: request logs, including timestamps for each request. Request volume and system response time Performance metrics, including system throughput and error rate, and their variations over different time periods.

[0054] Specifically, for data collected within a historical time period, a historical traffic dataset is constructed according to the timestamp order. Let the timestamp set be The corresponding set of requests is The system response time set is The historical traffic dataset can then be represented as: .

[0055] Furthermore, based on the request logs, the system calculates performance metrics within a specific time period: The formula for calculating throughput is: Where TotalRequests represents the total number of requests within the statistical time window, and TimePeriod represents the length of the time window.

[0056] The formula for calculating the error rate is: Here, FailedRequests represents the number of requests that failed within the statistical time window.

[0057] Using the above method, structured historical traffic data can be extracted and constructed from the raw logs, forming the basis for subsequently constructing the traffic feature vector. The traffic feature vector is derived from this historical traffic dataset. It is formed by extracting key data indicators such as time series, request volume, response time, throughput and error rate.

[0058] In some exemplary implementations, building the base dataset for stress testing also includes a sub-step of collecting new interface business data (step 1.2). This sub-step involves collecting the business logic information, configuration parameters, and upstream and downstream dependencies of the new interfaces across the entire process, specifically including: Configuration parameter set: Collects configuration parameters such as protocol type, calling method, and resource usage ratio of newly added interfaces, denoted as . .

[0059] Upstream and downstream dependencies: Identify and collect other system interfaces that have synchronous or asynchronous call relationships with the newly added interface, including the set of upstream dependent interfaces. and downstream dependency interface set And the possible remote procedure call (RPC) relationships.

[0060] Based on the upstream and downstream dependencies, a dependency matrix is ​​constructed to characterize the dependencies and strengths between interfaces in the system. Each element in the dependency matrix Representative interface With Interface The dependency weights between them, and their values ​​range from [ 1,1]. Where: when When the value is in the range (0, 1), it indicates an interface. Depends on interface (Right now for (upstream interface); when When the value is in the range [-1, 0), it indicates an interface. Depends on interface (Right now for Downstream interface); when When, it indicates an interface. With Interface There is no direct dependency between them. Dependency matrix The general form is as follows:

[0061] As an example, suppose the system has interfaces including New_API, Auth_Service, User_Service, and Payment_Service. Their dependency matrix can be represented as follows:

[0062] Step 1.3: Construction of Basic Traffic Dataset Based on collected historical traffic data and newly added interface business data (including configuration parameters) and dependency matrix ), build a basic traffic dataset for stress testing Its definition is:

[0063] Furthermore, the construction of the base dataset for stress testing may include a sub-step of preprocessing the base traffic dataset (step 1.4). The preprocessing process may include anomaly detection and cleaning, time series alignment, and noise reduction to improve data quality and consistency, facilitating subsequent feature extraction and model inference. This preprocessing can be implemented based on existing data cleaning and preprocessing techniques in the field.

[0064] In some exemplary embodiments, using a large vertical model for stress test scenario inference includes: By using traffic inference scenario refinement operators, the key features in the scenario vector that affect load intensity, response latency and bottleneck identification dimensions are weighted and refined. By using edge case derivation operators, edge scenarios and extreme scenarios are generated based on the changing trend of load intensity in the scene vector over time.

[0065] Among them, the refined operator for traffic inference scenarios ( This is an algorithmic component that adjusts and optimizes the weights of features in stress testing scenarios. It analyzes key features that significantly impact the system during stress testing, assigns different weights to these features, and uses mathematical methods such as partial derivatives to calculate the sensitivity of scenario features to traffic features. This optimizes the accuracy of scenario inference, enabling the generated test scenarios to more accurately reflect the system's critical stress points.

[0066] Edge case derivation operator ( This is an algorithmic component used to generate extreme and edge testing scenarios. It simulates the transitional behavior of a system under extreme loads, generating scenarios of system performance under unconventional conditions through time integration, based on the patterns of scenario changes over time and the trend of load acceleration. While these scenarios are uncommon in daily operations, their occurrence can significantly impact system stability and performance.

[0067] In this embodiment, the scenario inference of the vertical large model adopts a phased processing strategy. First, the model takes traffic feature vectors, interface feature vectors, and dependency matrices as inputs, and fuses multi-source features through deep learning techniques such as attention mechanisms to generate a preliminary scenario vector containing three dimensions: load intensity, response latency, and bottleneck identification. Subsequently, the traffic inference scenario refinement operator analyzes the preliminary scenario, identifies the key features that have the greatest impact on stress testing, and improves the accuracy of these features through a weight adjustment mechanism to generate a refined scenario. At the same time, the edge case derivation operator simulates the transition behavior of the system under extreme conditions based on the dynamic characteristics of load changes over time, and generates edge and extreme scenarios through time integration and load acceleration calculations, ultimately forming a complete set of test scenarios covering normal, refined, edge, and extreme cases.

[0068] Figure 4 This demonstrates the sub-step process for stress test scenario inference and generation based on a large vertical model. The process mainly consists of three processing stages: Data Input and Preliminary Inference: The preprocessed data is input into the vertical large model for business scenario inference, generating preliminary stress test scenario feature vectors that include dimensions such as load intensity, response latency, and bottleneck identification.

[0069] Scene Refinement Processing: Based on the initially generated scene feature vectors, refined scene inference is performed. This step uses traffic inference scene refinement operators to adjust and optimize the weights of key features, generating more accurate and representative refined scenes.

[0070] Edge and extreme scenario generation: Further, operators are derived from edge cases, and reasoning is performed based on the dynamic change trend of the scenario to generate edge and extreme stress test scenarios that are not common under normal conditions but are crucial to the stability of the system.

[0071] In some exemplary implementations, using a large vertical model to perform stress test scenario inference and generate scenario vectors that include dimensions such as load intensity, response latency, and bottleneck identification may include the following specific processes: Step 2.1: Perform business scenario reasoning based on the vertical large model to generate preliminary stress test scenarios.

[0072] In this step, the vertical large model (denoted as...) The core task is to infer the load and response performance of newly added interfaces under different business scenarios, especially for predictions of extreme and edge cases. In this application, the vertical large model specifically refers to a large-scale machine learning model that has been pre-trained or fine-tuned for the field of system stress testing, with clear functional boundaries and points of application: taking historical traffic data and new interface business data as input, and outputting scenario feature vectors and preliminary stress test scenarios that can be used for subsequent dependency graph construction and stress propagation analysis.

[0073] The vertical large-scale model can employ a large-scale parameter deep neural network structure based on attention mechanisms to support effective modeling and fusion of multi-source heterogeneous features. Its training data mainly comes from request logs and performance indicators in historical traffic data, as well as configuration parameters and upstream and downstream dependencies in newly added interface business data. It can also combine historical stress test results or online observation results to form supervision signals, enabling the model to learn the mapping relationship from input features to scenario dimensions such as load intensity, response latency, and bottleneck identification.

[0074] Specifically, the model's input is a multidimensional feature matrix consisting of three parts: Flow feature vector Features extracted from historical traffic data; this vector includes request volume. Response time Throughput and error rate Metrics related to interface stress, among which, .

[0075] Interface feature vector Features extracted from newly added interface business data, including call type. (e.g., synchronous / asynchronous), upstream dependent interfaces Downstream dependent interfaces Resource consumption parameters wait, .

[0076] Dependency Matrix : A matrix representing the dependencies and strengths between interfaces.

[0077] The model takes the above features as input and generates a preliminary business scenario vector through its internal calculation and reasoning process. The process can be formally represented as:

[0078] in, These are weighting coefficients used to weight the impact of each historical traffic feature. To indicate the first A traffic feature vector for a given time period, including request volume, response time, etc. The preliminary business scenario vector... At least include load strength Response delay and bottleneck identification Three dimensions, namely:

[0079] Step 2.2: Construct edge scenes, extreme scenes, and refined scenes based on the initial scene vectors.

[0080] To further improve the accuracy of scenario reasoning and generate edge and extreme cases that can represent the system's performance under unconventional conditions, this application introduces a traffic reasoning scenario refinement operator. And edge case derivation operators. Where: Refined operators for traffic inference scenarios ( This operator is used to refine the initial business scenario vector. It calculates the partial derivatives of scenario features with respect to traffic features by analyzing key features that have a significant impact on the system during stress testing. It identifies the features that have the greatest impact on system stress and adjusts the feature weights accordingly. and the introduction of adjustment coefficients To optimize the inference accuracy of scene features, thereby generating a refined scene. The calculation process can be expressed as follows:

[0081] in, These are feature weights, representing the degree of influence of a feature on the scene. These are adjustment coefficients used to optimize the inference accuracy of scene features. It is the partial derivative of scene features with respect to traffic features, used to identify the features that have the greatest impact on system pressure.

[0082] Edge Case Derivation Operator: This operator is used to generate edge and extreme scenarios. It simulates the transitional behavior of the system under extreme loads, based on the trend of scene changes over time (by...). (Description) and the accelerated change of load under extreme conditions (by the second derivative of the load) (Capture) Generate the transformed scene through time integration. The calculation process can be expressed as follows:

[0083] in, This represents the transformed scene. The partial derivative of the scenario over time describes the continuous changes in load and response time along the time dimension. It is the second derivative of the load, capturing the accelerated change of the load under extreme conditions. It is an adjustment factor used to amplify load fluctuations in extreme scenarios.

[0084] The above operator ( These (e.g., mapping rules and algorithmic steps) are expressed in mathematical form and are used to transform input features into scene representations that are more suitable for subsequent modeling. They can be implemented as part of the vertical large-scale model inference process (end-to-end integration) or as independent post-processing steps after the model output.

[0085] Step 2.3: Generate the final set of test scenarios.

[0086] Finally, by combining the initial business scenario vectors, refined scenarios, and edge / extreme scenarios, a complete set of test scenarios is generated for subsequent steps. , This set of test scenarios will serve as one of the important input data for subsequently building the system interface dependency graph and performing dependency relationship modeling.

[0087] As can be seen, step 110 in this embodiment constitutes the data preparation and preliminary intelligent reasoning stage of the entire stress testing method. Its core objective is to provide structured, semantically rich, high-quality input for subsequent dependency modeling, path analysis, and optimization iteration. This step integrates traditionally separate historical running data, new interface configurations, and system dependencies into a unified feature representation through a systematic data collection and fusion mechanism; and further transforms these static features into dynamic, quantifiable stress testing scenario descriptions through the domain reasoning capabilities of vertical large models.

[0088] Specifically, step 110 completes the crucial transformation from raw system data to a computable scenario representation. It first unifies and abstracts historical performance logs, interface configuration documents, and dependency descriptions scattered across different sources and formats into three feature representations with clear mathematical definitions and engineering significance: traffic feature vectors, interface feature vectors, and dependency matrices. This abstraction process is not merely about standardizing data formats; more importantly, it extracts key attribute dimensions closely related to stress testing, providing high-quality input features for subsequent machine learning modeling.

[0089] Building upon this foundation, step 110 innovatively introduces a vertically optimized large-scale model for stress testing, undertaking the tasks of scenario understanding and test case design that traditional methods require human experience. This model, through deep learning technology that integrates multi-source heterogeneous features, can not only infer the performance of new interfaces under normal business models, but also proactively identify and construct edge cases and extreme scenarios that are uncommon in historical data but crucial to system stability. This process achieves a fundamental shift in stress test scenario generation from rule-based replay to intelligent reasoning.

[0090] More importantly, the output of step 110—a scenario vector containing multi-dimensional information such as load intensity, response latency, and bottleneck identification—is not an isolated static result, but rather serves as dynamic contextual information throughout all subsequent analysis steps. These scenario vectors will be used in subsequent steps to guide the adjustment of dependency weights, the construction of node features, the derivation of pressure propagation paths, and the optimization of test feedback, forming a complete analysis chain centered on the scenario and with each link tightly coupled.

[0091] This mechanism effectively addresses core issues in traditional stress testing methods, such as incomplete scenario coverage, disconnect between scenarios and system states, and lack of targeted test cases. It combines data-driven objective analysis with intelligent reasoning based on domain knowledge, providing a starting point for stress testing new interfaces in complex distributed systems that is both broadly comprehensive and deeply insightful, thus laying a solid foundation for the accuracy and effectiveness of the entire testing process.

[0092] Step 120: Construct the initial interface dependency graph of the system based on the dependency matrix, and use multi-type dependency relation operators to calculate the weighted dependency strength of each dependency edge in the initial interface dependency graph based on the dependency type and associated performance indicators in the dependency matrix.

[0093] The initial interface dependency graph is a graph structure built based on the dependency matrix, where each node represents an interface in the system (including new and existing interfaces), and each edge represents a dependency relationship between interfaces. This graph serves as the topological foundation for subsequent relational graph convolutional network (R-GCN) modeling and pressure propagation analysis.

[0094] Weighted dependency strength is a quantitative metric calculated using multiple dependency operators. It considers not only whether dependencies exist between interfaces but also integrates various performance metrics (such as response time, resource consumption, and error rate) to dynamically measure the actual impact of dependencies. The weighted dependency strength value will be used as the weight of dependent edges in the graph structure for subsequent graph neural network calculations and path analysis.

[0095] Among them, the performance metrics associated with the dependency type include at least two of the following: response time, resource consumption, and error rate.

[0096] In this implementation, when calculating the weighted dependency strength, the multi-type dependency operator needs to combine at least two different types of performance metrics to comprehensively evaluate the impact of the dependency. This differs from traditional dependency analysis methods that only consider topological connectivity or a single metric (such as call frequency).

[0097] In practice, for each dependency type (such as synchronous calls, asynchronous calls, RPC calls, etc.), the operator collects multiple performance observations associated with that dependency type. For example, for synchronous calls, the average response time of the call chain, the CPU / memory resources consumed during the call, and the error rate of call failures can be considered simultaneously. Then, by weighting and combining these multi-dimensional metrics, a comprehensive dependency strength value is formed.

[0098] This multi-metric fusion calculation method can more comprehensively reflect the actual impact of dependencies on system performance, avoiding the limitations of a single metric. For example, a certain dependency chain may not be called frequently (traditional metrics have little impact), but once called, it consumes a lot of resources and is prone to errors. By using multi-metric weighting, its importance can be accurately identified.

[0099] In some exemplary implementations, constructing an initial interface dependency graph of the system based on the dependency matrix, and using multi-type dependency operators to calculate the weighted dependency strength of each dependency edge in the initial interface dependency graph based on the dependency types in the dependency matrix and the performance metrics associated with the dependency types, may include the following specific processes: Step 3.1: Construct the system's interface dependency graph.

[0100] In this step, the interfaces and their dependencies in the system are modeled as a graph structure. , where: node set Includes all interfaces in the system, including both new and existing interfaces. edge set Includes the dependencies between interfaces, and each directed edge Interface Depends on interface Each edge also has a dependency type attribute. This is used to indicate the specific category of a dependency, such as synchronous call, asynchronous call, or remote procedure call (RPC).

[0101] The topology (i.e., the connection relationships between nodes and edges) of the interface dependency graph (i.e., the initial interface dependency graph) is based on the dependency matrix constructed in step 1. Sure.

[0102] Step 3.2: Construct node feature vectors.

[0103] The set of test scenarios output in step 2 Instead of being used directly as a single global variable, it is injected into each interface node as scene condition information, forming the node features of the graph neural network. The specific implementation method is as follows: First, construct the basic interface feature vector for each interface i in the system. . The content defined in steps 1 and 2 includes historical traffic characteristics, interface configuration parameters, resource consumption parameters, and interface call types.

[0104] Secondly, based on the dependency matrix The dependency strength between interface i and the newly added interface and its related interfaces is calculated, and the effect coefficient of the scenario on this interface is determined. One implementation involves normalizing the dependency weights of corresponding rows or columns in the dependency matrix to obtain... This is used to characterize the degree of stress impact on the interface under the current stress test scenario.

[0105] Then, the scene vectors are mapped according to the interface to obtain the scene feature components of each interface. One direct implementation method is: This results in interfaces with stronger dependencies on the newly added interfaces receiving higher intensity of scene information injection, while interfaces with weaker or irrelevant dependencies receive correspondingly lower injection intensity.

[0106] Ultimately, the feature vector of each interface node By concatenating its basic interface feature vector and scene feature components And thus formed: The feature vectors of all interface nodes constitute the node feature set. ,in This is a set of nodes. This connection method ensures that the scenario-dimensional information such as load intensity, response latency, and bottleneck identification inferred in step 2 can enter the graph structure at the interface granularity and serve as the node feature input for the subsequently improved relational graph convolutional network (R-GCN).

[0107] Step 3.3: Calculate the weighted dependency strength using multi-type dependency operators.

[0108] Considering that dependencies between interfaces can take many forms, and that different types have different mechanisms of impact on system performance (such as latency, throughput, and resource utilization), failing to differentiate between them could lead to an oversimplification of the model's representation of the dependency impact. Therefore, this application proposes a multi-type dependency operator. It is used to perform fine-grained calculations of the weights (i.e., dependency strength) of dependent edges.

[0109] This operator incorporates multi-dimensional performance metrics into the dependency strength calculation by coupling calculations across different dependency types, ensuring a comprehensive reflection of the combined impact of various dependency types on system performance. Specifically, for interfaces... and Let the dependency edges between them have a dependency type of . Related performance metrics include response time Resource consumption Error rate Request volume and transmission time And so on. The calculation formula for the multi-type dependency operator is as follows:

[0110] in: It is the calculated interface. To the interface The weighted dependency strength between them. K represents the number of sub-items or dimensions associated with this dependency type. It is an adjustment coefficient for a specific dependency type r and sub-item k, used to balance the influence weight of different performance indicators (such as the ratio of response time squared to resource consumption, the exponential decay term of error rate, and the logarithmic term of request volume and transmission time) on the final dependency strength.

[0111] Based on the above calculations, each dependency edge in the initial interface dependency graph... They were all assigned a value obtained by dynamic weighting of multi-dimensional performance indicators. This value, known as the weighted dependency strength, replaces or initializes the original weights in the dependency matrix for subsequent graph neural network message propagation and aggregation processes.

[0112] Step 130: Use the relation feature decoupling operator to perform decoupling processing on the weighted dependency strength based on the dependency type, so as to suppress the interference between different types of dependencies, and map the scene vector to the corresponding interface node according to the dependency strength in the dependency matrix to form scene feature components, and concatenate them with the interface basic features extracted from the interface feature vector to construct node features.

[0113] By introducing a relational feature decoupling operator, the key problem of multi-type dependency coupling interference is solved. At the same time, through the node-level mapping and fusion mechanism of scene features, the global business scene reasoning results are organically combined with local interface features, providing high-quality and high-information node representations for subsequent graph neural network learning.

[0114] First, addressing the inherent flaw of traditional graph modeling where different types of dependencies mask each other, a proactive decoupling mechanism is proposed. Unlike simply distinguishing dependency types, this mechanism assigns and dynamically adjusts decoupling weights to each type, proactively suppressing the suppressive effect of high-impact types on low-impact types during message aggregation in the model. This ensures that the true impact of various dependencies, such as synchronous calls, asynchronous calls, and RPC calls, on system performance can be independently and accurately modeled and evaluated. This approach is a prerequisite for accurately identifying bottleneck paths dominated by specific dependency types.

[0115] By mapping scene vectors to scene feature components of each node based on dependency strength, and concatenating them with the interface's own basic features (such as configuration and resource consumption), composite node features with both static attributes and dynamic context are formed. This allows each node to not only represent its own inherent attributes in subsequent graph learning processes, but also carry information about its role and stress state in the entire stress testing scenario, greatly enriching the learning signal of the graph model.

[0116] In some exemplary embodiments, decoupling processing is performed using relational feature decoupling operators, including: Assign independent decoupling weights to different types of dependencies; Based on decoupling weights, when performing message aggregation in the improved relational graph convolutional network, the contribution of different types of dependencies to the target node representation update is adjusted to reduce the masking effect of high-latency or high-frequency call type dependencies on the representation of other types of dependencies.

[0117] Among them, the decoupling weight is an independent adjustment parameter assigned by the relation feature decoupling operator to different types of dependencies. Its function is to quantify and adjust the relative importance of various dependencies in the model aggregation calculation, and to purposefully reduce the undue influence of strong dependency types such as high latency or high frequency calls on the representation of other dependency types, thereby achieving independent analysis and accurate characterization of the influence of different types of dependencies.

[0118] Scene feature components refer to the local scene features mapped from the global scene vector to a single interface node. Their generation mechanism calculates an influence coefficient based on the dependency strength between the interface and other interfaces in the dependency matrix. This coefficient is then multiplied by the global scene vector to obtain a feature representation that reflects only the impact of the current stress test scenario on the interface. This component is then concatenated with the interface's own basic features to form the node's complete feature vector.

[0119] By introducing decoupling weights independent of the dependency strength itself, an additional conditioning layer is established in the message-passing framework of Relational Graph Convolutional Networks (R-GCN). Specifically, for each dependency edge in the graph, in addition to the already calculated weighted dependency strength, a decoupling weight is assigned to the dependency type (such as synchronous, asynchronous, RPC) corresponding to the edge.

[0120] In the message aggregation phase of node feature updates in the improved R-GCN, information from neighboring nodes is no longer simply summed after being weighted by dependency strength. Instead, it needs to undergo further adjustment through decoupling weights. For example, for a target node, its neighbors may include nodes connected by both high-latency synchronous calls and low-latency asynchronous calls. If aggregation is only based on dependency strength, high-latency synchronous calls, due to their potentially large influence coefficient, may dominate the aggregation result, masking the impact of asynchronous calls. Through the decoupling weight mechanism, the aggregation contribution of synchronous call type edges can be proactively reduced, or the contribution of asynchronous call type edges can be relatively increased.

[0121] Its technical effect is to decouple the impact of different types of dependencies, ensuring that even if a certain type of dependency (such as high-latency synchronous calls) performs exceptionally well in a specific scenario, the model will not ignore or underestimate the real impact of other types of dependencies (such as high-throughput asynchronous calls) on system performance. This makes the model's representation of complex dependency systems more comprehensive and robust, and helps to more accurately identify complex bottlenecks formed by the interweaving of different types of dependencies.

[0122] In some exemplary implementations, using relational feature decoupling operators to perform dependency type-based decoupling processing on the weighted dependency strength to suppress interference between different types of dependencies includes: Step 3.4: Use relation feature decoupling operators to decouple dependencies.

[0123] In real-world systems, different types of dependencies (such as synchronous calls, asynchronous calls, and RPC calls) may coexist and influence each other. For example, high-latency synchronous calls may amplify or mask the impact of asynchronous calls during model learning, preventing the true performance of certain dependency types from being independently and accurately reflected. To avoid such coupling interference between different types of dependencies and to ensure that the impact of each dependency type on system performance can be analyzed and evaluated independently, this application introduces a relational feature decoupling operator.

[0124] The core idea of ​​this operator is to assign independent decoupling weights to different types of dependencies, and actively adjust the contribution of different types of dependencies based on the calculation of these weights and correlations during the dependency representation learning process, so as to prevent some dependency types from having too much influence on other types.

[0125] Specifically, the decoupling process can be formally represented as follows: Suppose there are K different types of dependencies in the system. For the k-th type of dependency, its corresponding sub-dependency graph is denoted as... The independent decoupling weights assigned to it are denoted as Furthermore, the definition This represents the correlation between the p-th type of dependency and the k-th type of dependency.

[0126] Based on the above definition, the comprehensive dependency representation after decoupling is as follows: It can be calculated using the following formula:

[0127] in: It is a comprehensive representation of dependencies obtained after decoupling, which suppresses interference between types. It is the decoupling weight of the k-th type of dependency, used to directly adjust the strength of the impact of this type of dependency on the overall system. and It is the adjustment coefficient. The denominator term. This is used to quantify the combined influence of all other types of dependencies on the k-th type of dependency. By placing this combined influence in the denominator, it is possible to effectively penalize or suppress dependency types that are strongly influenced by other types of dependencies, thereby reducing their excessive influence.

[0128] Through the decoupling operator described above, the system can achieve independent analysis of multiple types of dependencies. For example, even if synchronous calls exhibit high latency, this operator can adjust weights and related terms to ensure that the performance of other types, such as asynchronous calls, is not misled or masked by the influence of synchronous calls. This allows the model to more accurately analyze and characterize the true performance of each dependency type under stress testing scenarios. This decoupling process is a key prerequisite for the subsequent improved Relational Graph Convolutional Network (R-GCN) to accurately learn interface dependency representations and thus support precise call chain inference.

[0129] Step 140: Based on node features, decoupled dependencies, and corresponding weighted dependency strengths, the initial interface dependency graph is represented and updated using an improved relational graph convolutional network to obtain a weighted dependency graph. Then, based on the weighted dependency graph, call chain reasoning and dynamic pressure propagation path derivation are performed to output the key pressure propagation paths and bottleneck interfaces in the system.

[0130] Representation learning and updating refers to the core operation of the Improved Relational Graph Convolutional Network (R-GCN). Based on the graph's structure (nodes, edges) and attributes (node ​​features, edge weights), it learns a new, higher-level feature representation for each node in the graph through message passing and aggregation mechanisms in a multi-layer neural network. This new representation integrates the node's own information and its contextual information within the graph structure.

[0131] In some exemplary embodiments, the improved relational graph convolutional network aggregates neighbor node information weighted by weighted dependency strength during message propagation. The training process of the improved relational graph convolutional network is optimized by minimizing the loss function generated by multi-dimensional coupled scenarios.

[0132] The core improvement of the Improved Relational Graph Convolutional Network (R-GCN) in message propagation is the explicit introduction of weighted dependency strengths calculated by multi-type dependency operators as edge weights when aggregating neighbor node information. This makes message propagation no longer a simple averaging or summing of neighbor information, but a weighted aggregation based on the actual influence of dependencies (dynamically calculated from multi-dimensional performance metrics). The optimization objective of its training process is a multi-dimensional coupled scene generation loss function. This loss function is not a single objective, but a composite loss, typically including at least a scene matching loss (ensuring the generated scene is similar to the real situation), an edge scene loss (encouraging the model to cover extreme cases), and a scene diversity regularization term (avoiding overly simplistic generated scenes). By minimizing this loss, the node representations and dependencies learned by the model are not only beneficial for graph structure tasks, but also directly serve accurate stress testing scene generation and bottleneck identification.

[0133] In some exemplary embodiments, dynamic pressure propagation path derivation based on a weighted dependency graph includes: In a weighted dependency graph, the path that minimizes the sum of the products of the inverse of the weighted dependency strength of each dependency edge on the path and the load resource ratio of each interface node is identified as the critical pressure propagation path.

[0134] Inverse of weighted dependency strength ( : Indicates the difficulty or cost of establishing this dependency. The stronger the dependency ( The larger the value, the smaller its reciprocal, which means that the resistance to the transmission of pressure through this path is smaller.

[0135] Interface node load resource ratio ( The percentage (%) indicates the congestion level of the node itself. The higher the percentage, the busier the node, and the higher the cost for pressure to pass through that node.

[0136] Multiplying these two terms and summing them to find the path with the minimum total is essentially finding a path with the least resistance to pressure propagation and relatively unobstructed nodes along the way. In practice, this is often the critical pressure propagation path where pressure is most likely to accumulate and most likely to cause systemic bottlenecks.

[0137] In some exemplary embodiments, the identification of the bottleneck interface includes: In the weighted dependency graph, identify the interface node with the highest load level to resource processing capacity ratio and the strongest pressure transmission intensity to the neighbor nodes of the bottleneck interface.

[0138] The load level to resource processing capacity ratio is the ratio of the current load level of an interface (such as the number of concurrent requests, CPU utilization, etc.) to its resource processing capacity (such as the maximum number of supported concurrency, rated CPU computing power, etc.). The higher the ratio, the closer the interface is to its performance limit and the more likely it is to become a performance bottleneck.

[0139] Among them, the load level / resource processing capacity ratio is the highest among the self-stress indicators. This indicates that the resource utilization of this interface is close to saturation, and it is a potential local bottleneck.

[0140] External impact indicator: The pressure transmission intensity to its neighboring nodes is the greatest. This indicates that once a problem occurs at this interface, the transmission impact on other parts of the system is also the greatest.

[0141] An interface must simultaneously meet both conditions—being both the point of greatest internal pressure and the critical source of pressure propagation—to be identified as a system-level bottleneck interface. This identification method avoids misjudgments that focus solely on localized high loads while ignoring their network impact, and can more accurately pinpoint nodes that pose the greatest threat to the overall system stability.

[0142] Pressure propagation strength is used to quantify the degree of pressure exerted by an interface node on its downstream dependent interfaces. It depends not only on the weighted dependency strength between interfaces, but also on the load level of the source interface itself, and is a dynamic indicator that comprehensively reflects the potential for pressure to propagate along the dependency link.

[0143] In some exemplary implementations, based on the node features, decoupled dependencies, and corresponding weighted dependency strengths, an improved relational graph convolutional network is used to perform representation learning and updating on the initial interface dependency graph to obtain a weighted dependency graph, including: Step 3.5: Use an improved relational graph convolutional network for message propagation and node representation learning.

[0144] The improved relational graph convolutional network (R-GCN) is the core module of this application that enhances the standard R-GCN network. Its improvement does not lie in the reconstruction of the basic propagation formula framework, but rather in the redefinition and enhancement of the core input variables to this formula, thereby giving it stronger expressive and learning capabilities in stress testing scenarios driven by multiple types of dependencies and dynamic performance metrics.

[0145] The standard R-GCN message propagation formula can be used as a general shell and expressed as:

[0146] in, For nodes In the Layer feature representation, For a collection of dependency types, For dependency type Next and Node The set of connected neighbor nodes, These are normalization coefficients, typically found at nodes. In type The number of neighbors below, For dependency type In the The weight matrix of the layer, This is a self-connection weight matrix used for updating the node's own features. This is the activation function, such as ReLU or LeakyReLU.

[0147] The improvements made to the standard formula in this application are reflected in the following three core aspects: The first improvement is the introduction of dynamic edge weights driven by multi-dimensional performance metrics. Standard R-GCN primarily uses normalized coefficients when aggregating messages. To balance the influence of different neighbors, the edge weights are implicit or static. This application calculates the weighted dependency strength of each dependency edge using multi-type dependency operators. This intensity takes into account the response time. Resource consumption Error rate Request volume and transmission time It provides multi-dimensional performance metrics and can dynamically update them according to the scenario and load. This weighted dependency strength is explicitly introduced into the message aggregation process, forming weighted relational message aggregation. The improved aggregation process can be formally represented as:

[0148] in, This refers to the weighted dependency strength calculated in step 3.3. By introducing this dynamic weight, the model can accurately reflect the actual impact of different dependencies on the performance of the target node when aggregating neighbor information, thus injecting multidimensional performance impact into the representation learning of the graph neural network.

[0149] The second improvement is the introduction of a contribution adjustment mechanism based on relational feature decoupling operators.

[0150] While the standard R-GCN distinguishes between different relation type sets (RR), it simply adds the contributions of each type of relation during aggregation, lacking a mechanism to suppress inter-type interference (e.g., high-latency synchronous calls masking the effects of asynchronous calls). This application uses relation feature decoupling operators to assign independent decoupling weights to different types of dependencies and introduces corresponding adjustment coefficients into the message aggregation framework to suppress interference between different types of dependencies, ensuring that the impact of each dependency type can be independently and accurately represented. Essentially, this adds type-controllable decoupling weight constraints to the standard aggregation structure, achieving a more refined characterization of the impact of multi-type dependencies.

[0151] The third improvement is to adopt a multi-dimensional joint optimization objective oriented towards stress testing scenarios.

[0152] The training objective of standard R-GCN typically serves general graph learning tasks (such as node classification and link prediction). This application introduces a multi-dimensional coupled scene generation loss function, which integrates scene matching loss (measuring the difference between the generated scene and the real scene), edge scene loss (encouraging coverage of extreme and edge cases), and scene diversity regularization (avoiding overly homogenous generated scenes) into a unified framework. This loss function directly constrains and optimizes the node scene features injected in step 2, the weighted dependency edge weights calculated in step 3, and the node representations learned by R-GCN. This allows graph representation learning to directly serve the ultimate goal of improving the realism of stress test scenarios, the ability to cover extreme scenarios, and their diversity, achieving task-driven model optimization.

[0153] Through the above three-layer improvements, the improved R-GCN network can perform efficient and accurate representation learning and updating of interface dependency graphs that incorporate scene information.

[0154] Step 3.6: Generate the final weighted dependency graph.

[0155] After multi-layer propagation and learning in the improved R-GCN network, the system obtains updated node representations and optimized dependencies, ultimately forming a weighted dependency graph for subsequent path analysis. : .in, It is a set of nodes that includes newly added interfaces and their key interfaces in the system. This represents the weighted dependency edge set optimized through the above learning process, where each edge carries weight information reflecting the actual influence and dependency strength between interfaces.

[0156] In some exemplary implementations, the training process of the improved relational graph convolutional network is optimized by minimizing a multi-dimensional coupled scenario generation loss function. This loss function is specifically designed to improve the quality of stress test scenario generation, and through multi-objective joint optimization, it ensures that the graph representation learned by the model can directly serve to generate accurate, comprehensive, and diverse stress test scenarios.

[0157] Step 3.7: Define and apply the loss function for generating multi-dimensional coupled scenarios.

[0158] The multi-dimensional coupling scenario generates a loss function. It consists of three core components, which together form the total loss in a weighted sum, aiming to jointly optimize scene matching accuracy, edge scene coverage, and scene diversity:

[0159] in, It is an adjustment coefficient that controls the contribution of each part of the loss to the overall optimization objective.

[0160] 1. Scene matching loss This loss is used to measure the difference between the model-generated scenario and the real system scenario, with the goal of ensuring that the generated stress test scenario accurately reflects the system's true performance. Its calculation formula is as follows:

[0161] Where N is the number of scene samples. Let represent the response time, resource consumption, and error rate in the i-th generated scenario, respectively. These represent the response time, resource consumption, and error rate in the corresponding real-world scenarios, respectively. It is the weighting coefficient that controls the contribution of each feature to the loss.

[0162] 2. Edge scene loss This loss is used to force the optimization model to generate edge cases and extreme situations, ensuring that stress tests can cover potential risks of the system under unconventional conditions. Its calculation formula is as follows:

[0163] in, For the number of edge scenes, These are feature values ​​of edge / extreme scenarios (such as extreme values ​​of response time and resource consumption) extracted or defined from historical data.

[0164] 3. Regularization terms for scene diversity This regularization term encourages the model to generate diverse test scenarios, preventing the scenarios from being overly concentrated on a few stress modes, thereby improving the breadth of test coverage. Its calculation formula is as follows:

[0165] in, These are feature vectors from two different generation scenarios. This represents the Euclidean distance between the feature vectors of two scenes, used to measure the similarity between scenes. It is an adjustment coefficient used to control the degree of influence of differences between scenes on the loss value.

[0166] Sources of real data in the loss function: In the optimization process of generating the loss function in a multi-dimensional coupled scenario, the required real-scene data is provided by two sources: Historical observation data: during the offline training or fine-tuning phase of the model, the true value , The data primarily originates from historical traffic data and its accompanying performance metrics, such as response time, throughput, error rate, and resource utilization. Feature values ​​for edge computing scenarios. This is also obtained by extracting extreme values ​​or marginal intervals from historical data.

[0167] Actual test feedback data: During the scenario generation optimization and closed-loop iteration phase (corresponding to transfer learning optimization and feedback-driven dynamic adjustment), the true labels required for the loss function are preferably provided by the performance data actually measured during traffic replay stress testing, and are uniformly used as the actual test feedback F. At this time, The true value in the loss is based on the actual test data of real-time replay test, so as to realize the continuous correction and optimization of the model prediction. This makes the whole method able to form a trainable and optimizable closed loop through actual test feedback when facing new interfaces or changing scenarios, even if historical data is lacking.

[0168] A loss function is generated by minimizing the aforementioned multi-dimensional coupling scenario. The learning process of the improved relational graph convolutional network is directly constrained and guided. The node representations and dependency optimizations it learns not only serve graph structure tasks, but also directly address the ultimate application goal of improving the realism, extreme case coverage and diversity of stress testing scenarios.

[0169] Figure 5 This demonstrates the core analysis process and internal interaction mechanism for call chain reasoning and dynamic pressure propagation path deduction based on a weighted dependency graph. The process begins with the constructed weighted dependency graph. Based on this graph, the system first performs call chain reasoning, the core of which lies in analyzing the load distribution of nodes (interfaces) in the graph and the probability of pressure propagation on dependency edges (call relationships between interfaces). By combining the load state of the nodes themselves with the weight strength of the dependency edges, the system can infer the path and probability of pressure propagation in the dependency network.

[0170] Building upon this foundation, the process enters the dynamic pressure propagation path derivation stage. This stage employs a dynamic optimization path identification algorithm (such as the weighted shortest path algorithm), comprehensively considering the weights of dependent edges (representing traversal difficulty) and the load-resource ratios of passing nodes (representing congestion levels) to identify in real time the critical pressure propagation paths in the system with the highest load and the greatest likelihood of triggering systemic bottlenecks. Simultaneously, the system performs bottleneck interface identification in parallel, locating the critical nodes that pose the greatest threat to system stability based on the ratio of the interface's own load to its resource processing capacity and the intensity of its pressure transmission to downstream interfaces.

[0171] Ultimately, the output of the analysis process is the identified set of key pressure propagation paths and bottleneck interfaces. These results can be directly used to guide the focus of test resources and system optimization. Furthermore, they serve as important inputs to the subsequent transfer learning optimization module, used for weighted training of the scenario generation model, thereby driving the entire stress testing method to achieve accurate and adaptive closed-loop optimization.

[0172] In some exemplary implementations, the call chain reasoning and dynamic pressure propagation path derivation based on the weighted dependency graph, and the output of the key pressure propagation paths and bottleneck interfaces in the system, include the following specific processes.

[0173] Step 4.1: Perform call chain reasoning and static derivation of critical paths based on the weighted dependency graph.

[0174] Based on the obtained weighted dependency graph The system analyzes the dependencies and load characteristics between interface nodes to perform call chain reasoning, aiming to quantify the propagation path of stress within the system. The core of the reasoning process is to identify the dependency links most likely to become the main channels for stress propagation.

[0175] Among them, the probability of pressure transmission Used to quantify pressure from the interface Passed to its downstream interface The probability of [a certain value] is calculated using the following formula:

[0176] in, Indicates from the interface To the interface The probability of pressure transmission. It is an interface and The weighted dependency strength between them. and Representing interfaces respectively and its neighboring nodes The probability takes into account both the strength of the dependency and the load status of the source interface.

[0177] To identify the critical links in the system most susceptible to pressure propagation, this application employs a weighted shortest path algorithm for path derivation. The core idea is to find a path that minimizes the overall propagation cost along that path. Specifically, the critical pressure propagation path is obtained by minimizing the following path cost function:

[0178] Where P represents a path from a pressure source (such as a new interface) to any target interface in the system. It is on the path The weighted dependency strength. It refers to the node (interface) on the path. The load level. It is an interface Resource processing capabilities. This refers to the load resource ratio of the interface.

[0179] In this formula, This can be viewed as resistance through this dependency relationship; the stronger the dependency, the smaller the resistance. This represents the congestion cost of the interface node. Finding the path that minimizes the sum of their products is equivalent to finding the critical path with the smoothest pressure propagation and relatively idle nodes along the way.

[0180] Step 4.2: Dynamically optimize the pressure propagation path based on dynamic load changes.

[0181] During actual stress testing, the interface load level and resource consumption The pressure propagation hotspot changes dynamically with time t. To more accurately reflect the pressure propagation hotspot in real-time conditions, this application further proposes a dynamic optimization algorithm for the pressure propagation path. This algorithm introduces the influence of the load change rate on top of the static path cost.

[0182] Critical path of dynamic optimization The formula for calculating time t is as follows:

[0183] in, and Representing interfaces respectively Load level and resource processing capacity at time t. It is an interface The load change rate reflects how fast the load is increasing. A rapidly increasing load indicates that the interface may soon become a bottleneck. It is an adjustment coefficient used to control the intensity of the impact of the load change rate on the path cost.

[0184] By introducing a load change rate term, the algorithm can detect and avoid paths where the load is rising sharply and is about to become overloaded, thereby identifying the most stable pressure propagation path in a dynamic environment and enhancing the predictability and robustness of path identification.

[0185] Step 4.3: Identify system bottleneck interfaces.

[0186] Besides identifying pressure propagation paths, locating bottleneck interfaces in the system is also crucial. Bottleneck interfaces refer to critical nodes whose load is approaching or exceeding their processing capacity, and whose pressure easily propagates downstream. The bottleneck interface identification method proposed in this application is based on the following formula:

[0187] in, This represents the set of identified bottleneck interfaces. It is an interface The load resource ratio indicates that the higher the value, the more congested the resource itself is. The interface was quantified. For all its downstream neighbor nodes The total applied pressure transmission intensity. The larger this value, the wider the impact on the system after a problem with this interface. The formula as a whole finds its maximum value by calculating the product of the load resource ratio and the reciprocal of the pressure transmission intensity (i.e., 1 / pressure sensing intensity). This ensures that an interface identified as a bottleneck is both a pressure point with high load itself and a pressure source with a strong influence on its downstream components. Placing its pressure transmission intensity in the denominator means that even if an interface has a high load, it may not be identified as a system-level bottleneck if its impact on other parts of the system is small.

[0188] Through the above steps, the system can output the key pressure propagation paths identified in a specific stress testing scenario based on the weighted dependency graph. and bottleneck interface set These results serve as an important basis for subsequent transfer learning optimization and targeted stress testing.

[0189] In some exemplary embodiments, the method provided in this application further includes: Based on key pressure propagation paths and bottleneck interfaces, and combined with test feedback obtained from stress tests, the vertical large model is optimized through transfer learning to generate optimized stress test scenarios. Based on the optimized stress test scenario, high-concurrency stress tests are performed through traffic replay, and the node load and edge weight information in the weighted dependency graph are updated according to the new test feedback for the next round of scenario reasoning and path deduction.

[0190] By constructing a closed-loop feedback mechanism of "scenario reasoning - path analysis - test verification - model optimization", the stress testing method has achieved continuous self-evolution and accuracy iteration improvement, enabling tests for new interfaces to quickly converge to real system bottlenecks and critical paths.

[0191] In some exemplary embodiments, the vertical large model is optimized through transfer learning. The optimization objective function of transfer learning is to assign higher optimization weights to the scene generation loss located on the critical pressure propagation path and the scene generation loss involving the bottleneck interface.

[0192] Using feedback data (F) obtained from actual stress testing, combined with identified key stress propagation paths and bottleneck interface information, the initial large-scale vertical model is fine-tuned using transfer learning techniques. The key innovation in optimizing the objective function lies in weighting. It assigns higher weights to two specific components of the model training loss: Scene generation loss located on critical pressure propagation paths: Ensure that model optimization prioritizes improving scene prediction accuracy on the most vulnerable paths of the system.

[0193] Scenario generation loss involving bottleneck interfaces: Ensure that the model prioritizes improving its ability to simulate the performance of these high-risk interfaces.

[0194] This weighted mechanism guides the transfer learning process to focus limited optimization resources (such as training data and iterations) on the aspects that have the greatest impact on system stability, thereby significantly improving optimization efficiency and the relevance and effectiveness of the final test scenarios. The optimized model generates new scenarios, driving a new round of testing and feedback, forming a closed loop of continuous improvement.

[0195] In some exemplary embodiments, the method further includes transfer learning optimization and closed-loop stress testing steps. This step utilizes key stress propagation paths and bottleneck interfaces, combined with feedback from actual stress tests, to perform targeted optimization of the large vertical model and drive iterative testing processes.

[0196] Step 5.1: Overview of the goals and mechanisms of transfer learning optimization.

[0197] The transfer learning in this application aims to transfer the scenario reasoning capability of an existing interface (source domain) to a new interface (target domain). The source domain consists of the existing system interface and its historical traffic data, historical load test data, or online observation data, and has been trained to obtain a model with preliminary scenario reasoning capabilities (such as the initial state of a large vertical model). The target domain corresponds to the task of generating and optimizing load test scenarios for the new interface under the specific dependencies and load constraints of this system.

[0198] The preferred objects for migration are the model parameters and scene representation methods of the aforementioned vertical large model. This allows new interfaces to inherit and utilize the prior knowledge of performance patterns such as load intensity, response latency, and bottleneck identification from existing system interfaces, even in the absence of sufficient historical samples. In implementation, a fine-tuning method is adopted, initialized with the source model parameters.

[0199] The core driving forces for optimization come from two aspects: first, the system-level insights (critical path and bottleneck interface) obtained from step 4 analysis; and second, the real-time feedback F obtained from actual stress testing. In order to integrate system insights into the optimization process, this application introduces a path transfer operator and a bottleneck interface priority optimization mechanism to form a weighted optimization objective, guiding the transfer learning process to prioritize the parts that have the greatest impact on system stability.

[0200] Step 5.2: Migration optimization based on key pressure propagation paths.

[0201] Key pressure transmission pathways These represent the dependency chains most likely to cause performance bottlenecks in the system. To ensure that the scenarios generated after transfer learning accurately simulate the pressure propagation on these high-risk paths, this application proposes a critical path-based transfer optimization strategy. This strategy assigns weights to different critical paths. Construct a path-weighted loss term in the total loss function. :

[0202] in, It is a collection of key pressure transmission paths. This is the optimization weight assigned to path P, which can be dynamically set based on factors such as the path's average load and dependency strength. A higher weight indicates a higher requirement for the fitting accuracy of the path during the optimization process. It is a loss function that measures the accuracy of the generated scene on path P. For example, it can calculate the mean square error of the generated scene and the real (or target) scene on all interfaces on the path in terms of response time, resource consumption and other indicators.

[0203] By minimizing The transfer learning process is guided to prioritize improving the model's scene generation accuracy along key pressure propagation paths.

[0204] Step 5.3: Migration optimization based on bottleneck interface.

[0205] bottleneck interface These are critical nodes in the system where the load is approaching or exceeding their processing capacity. Optimization of these interfaces should be prioritized. This application proposes a bottleneck interface-first optimization mechanism, which adds a bottleneck interface-based loss term to the total loss function. To achieve:

[0206] in, It is the set of identified bottleneck interfaces. It is to assign priority optimization weights to the bottleneck interface (usually) This ensures that these interfaces receive more optimization attention. It is a measure of the bottleneck interface The loss function for scene generation accuracy can focus on key metrics such as response time and error rate of the interface under high load.

[0207] By minimizing The transfer learning process will focus on optimizing the accuracy of scenario simulation under high-pressure conditions for the bottleneck interface.

[0208] Step 5.4: Integrate weighted optimization objectives and iterative updates.

[0209] Combining the above two points, the overall weighted optimization objective of transfer learning can be expressed as:

[0210] in It can be based on transfer loss (such as feature distribution difference loss between the source domain and the target domain). This is its adjustment coefficient. The objective function explicitly guides the model to prioritize improving performance on the critical path and bottleneck interfaces.

[0211] In actual iterations, the feedback collected from traffic replay stress tests was incorporated. (Including measured response time, throughput, error rate, etc.), the model parameters are updated in each iteration t. One update method can be expressed as:

[0212] in For model parameters, The learning rate is used. Through this optimization mechanism that combines prior system insights (critical path, bottleneck interface) with real-time test feedback, the vertical large model can be efficiently fine-tuned, thereby generating more optimized and accurate stress test scenarios for new interfaces. The optimized scenarios will then drive the next round of stress testing, forming a closed loop of analysis-optimization-testing-feedback.

[0213] To quantify the accuracy of scenario generation for critical paths and bottleneck interfaces, a computable loss function needs to be defined. and .

[0214] 1. Scene inference loss function for critical paths: For a critical pressure propagation path P, the scene generation loss is... Defined as the sum of the differences in multidimensional performance metrics between all interfaces generated along this path and the real (or target) scene:

[0215] in, It is the critical path The number of interfaces. These represent the response time, resource consumption, and error rate in the scenario generated for the i-th interface on path P, respectively. These represent the response time, resource consumption, and error rate in the corresponding real-world scenario (or expected target value), respectively. It is a weighting coefficient that controls the degree to which each performance indicator contributes to the loss.

[0216] This loss function is used to ensure that the transfer learning process can prioritize improving the model's simulation accuracy of the system's core performance indicators on key pressure propagation paths.

[0217] 2. Generation of loss function for bottleneck interface scenarios For a bottleneck interface Its scene generation loss While focusing on general performance metrics, a specific item reflecting its overload condition has been introduced:

[0218] in: and It is the bottleneck interface in the generated scene. The response time, resource consumption, and error rate. and It corresponds to the real-world scenario (or measured / expected) value. These are the weighting coefficients for the corresponding performance indicators. It is the bottleneck interface. The actual load. It is the bottleneck interface. Resource processing capabilities. It is an adjustment factor used to balance the interface load resource ratio. The strength of its impact on the total loss. This item The aim is to ensure that, during model optimization, not only the absolute accuracy of performance metrics is considered, but also that the generated scenarios more realistically reflect the interface under high load (i.e., high...). The pressure state under the condition of ratio is used to accurately depict the bottleneck performance.

[0219] Step 5.3: Multi-round iteration and feedback-driven optimization mechanism.

[0220] The initial stage of transfer learning may not be able to fully capture all the business characteristics of newly added interfaces. To address this, this application proposes a multi-round iterative optimization mechanism that incorporates real-time test feedback to continuously improve the accuracy and adaptability of scenario generation.

[0221] In each iteration t, the system incorporates feedback information obtained from actual stress tests. (Including key performance indicators such as measured response time, throughput, error rate, and resource utilization), for the scene generation model (whose parameters or intermediate states can be represented as) The update is performed using gradient descent. One form of the update formula is as follows:

[0222] in, This represents the parameters or state of the model at the t-th iteration. It is the learning rate, which controls the step size for updating parameters. Indicates the model parameters Find the gradient. and These are the total critical path loss and the total bottleneck interface loss calculated based on the current model prediction (as mentioned above). and (As a summary) It is the loss term composed of the actual test feedback in round t, which can be directly constructed based on the difference between the measured value and the model prediction value (e.g., mean squared error). It is an adjustment coefficient used to control the weight of the actual test feedback in this update.

[0223] Through this mechanism, the model can utilize closed-loop feedback from real stress tests to continuously correct its performance predictions for critical paths and bottleneck interfaces. This allows the generated scenarios to gradually approximate and ultimately accurately reflect the real behavior of newly added interfaces under actual high-load environments, thereby achieving iterative improvements in the accuracy and coverage of scenario generation. The optimized model will then be used to generate the next round of stress test scenarios, driving continuous optimization of the entire process.

[0224] Step 6: Perform traffic replay stress tests based on the optimized scenario and collect feedback.

[0225] After obtaining the optimized stress test scenario through transfer learning, the goal of this step is to verify the accuracy of the scenario inference under a simulated real load environment through high-concurrency traffic replay testing, and to conduct an in-depth evaluation of system performance in order to discover potential bottlenecks and problems.

[0226] Step 6.1 Construct a traffic replay dataset. The traffic replay dataset consists of two parts to enhance the representativeness of the test.

[0227] Among these, historical traffic logs are extracted from the system's actual historical requests to ensure that the replayed traffic patterns reflect user behavior and business characteristics in the real environment. Optimized generated scenarios are based on the scenario inference results generated after transfer learning optimization in step 5, particularly focusing on scenario data related to key pressure propagation paths and bottleneck interfaces. This part of the scenario data defines the load patterns, concurrency levels, and abnormal conditions that need to be verified during testing.

[0228] Step 6.2 Develop and implement a replay strategy. To ensure the effectiveness and security of the test, this application proposes a conservative and intelligent replay strategy: Critical path priority replay: Based on the critical pressure propagation paths identified in steps 4 and 5, traffic involving these paths is prioritized for generation and replay. This ensures that the most vulnerable dependency chains in the system are fully validated under high concurrency conditions.

[0229] Bottleneck Interface Traffic Focus: For identified bottleneck interfaces, apply higher intensity or more complex load patterns during playback to verify the actual performance and load capacity limits of these interfaces under high pressure.

[0230] Dynamic load adjustment: During replay execution, system performance fluctuates with load. To accurately simulate real fluctuations and avoid overwhelming the system, this application proposes a dynamic load adjustment mechanism. This mechanism dynamically adjusts the traffic intensity for the next moment by monitoring the system's performance indicators in real time and comparing them with preset targets. The adjustment formula is as follows:

[0231] in: It is the playback flow intensity at the current time t. and These are the system's measured average response time and throughput at time t, respectively. and These are the preset target response time and target throughput. This is the adjustment coefficient, used to control the magnitude of load adjustment. The mechanism of this formula is: when the measured performance of the system deviates from the target (e.g., response time increases or throughput decreases), the term on the right side of the formula becomes negative, which will lead to a decrease in the flow intensity at the next moment. This reduces the load, thus automatically slowing down the growth of the load, allowing tests to continue running when the system is close to but not exceeding the collapse threshold, in order to deeply verify its stability and bottleneck performance.

[0232] Step 6.3 Generate Test Feedback: After the traffic replay test is completed, the system collects and generates a comprehensive performance indicator report as the actual test feedback F. This report includes at least the following core indicators: response time, throughput, error rate, and resource utilization (such as CPU, memory, and I / O). This measured data is the fundamental basis for subsequent model optimization and dynamic adjustment.

[0233] Step 7: Feedback-driven dynamic adjustment of the scenario and continuous optimization of the model.

[0234] The business scenarios and system dependencies of newly added interfaces may evolve over time, thus requiring the performance evaluation model to be adaptive. This application proposes a feedback-driven dynamic adjustment mechanism that enables the model to continuously optimize based on the latest system performance.

[0235] After each complete scenario reasoning-stress test cycle, the system utilizes the actual test feedback collected in step 6. The parameters of the evaluation model are dynamically adjusted. One parameter update method based on gradient descent is as follows:

[0236] in, This represents the parameters of the model after the t-th iteration. This is the learning rate. It is the mean squared error loss term between the model prediction and the measured data. and These represent performance metrics (such as response time and resource consumption) in the model generation scenario and the actual testing scenario, respectively. is the actual test feedback information from round t, which can be directly used as a loss term or incorporated into loss calculation through a specific function. is the adjustment coefficient, used to balance the impact of prediction error and direct feedback on parameter adjustment.

[0237] Through this mechanism, once a significant fluctuation or deviation in performance metrics (such as response time) is detected under high concurrency, the model parameters will be corrected in a timely manner, thereby ensuring that the evaluation model can continuously and accurately reflect the current state and performance characteristics of the system.

[0238] Finally, through transfer learning in step 5, closed-loop testing in step 6, and feedback-driven dynamic adjustment in step 7, the entire method forms a complete, self-iterably optimizing performance evaluation system. This system can continuously provide comprehensive, accurate, and adaptive performance evaluation and risk prediction for new interfaces based on scenario inference results and real-time test feedback at different stages.

[0239] The interface stress testing method provided in this application constructs a basic dataset containing traffic feature vectors, interface feature vectors, and dependency matrices. It then uses a vertical large-scale model for stress test scenario inference to generate multi-dimensional scenario vectors, including load intensity, response latency, and bottleneck identification. Based on the dependency matrix, an initial interface dependency graph is constructed. Multi-type dependency operators combined with performance metrics are used to calculate weighted dependency strength. Relationship feature decoupling operators are then used to decouple the weighted dependency strength based on dependency type to suppress inter-type interference. Simultaneously, the scenario vectors are mapped to node scenario feature components according to dependency strength and concatenated with basic interface features to construct node features. Finally, based on node features, decoupled dependencies, and weighted dependency strength, an improved relational graph convolutional network is used for representation learning to obtain a weighted dependency graph. This graph is then used for call chain inference and dynamic pressure propagation path derivation. This achieves more comprehensive and refined coverage of newly added interface stress test scenarios, as well as more accurate and robust representation modeling of complex multi-type dependencies in the system, significantly improving the accuracy of stress testing and the effectiveness of system bottleneck identification.

[0240] Figure 6 This is a schematic diagram of the structure of an interface stress testing device 600 provided in an exemplary embodiment of this application. Figure 6 As shown, the interface stress testing device 600 includes: a vector generation module 610, a strength calculation module 620, a feature construction module 630, and a stress testing module 640, wherein: The vector generation module 610 is used to construct a basic dataset for stress testing. The basic dataset includes traffic feature vectors extracted from historical traffic data, interface feature vectors extracted from newly added interface business data, and a dependency matrix that characterizes the dependency relationship and strength between interfaces. Based on the traffic feature vectors, the interface feature vectors and the dependency matrix, a vertical large model is used to perform stress test scenario reasoning to generate scenario vectors containing dimensions of load intensity, response latency and bottleneck identification. The strength calculation module 620 is used to construct an initial interface dependency graph of the system based on the dependency matrix, and to calculate the weighted dependency strength of each dependency edge in the initial interface dependency graph based on the dependency type and associated performance index in the dependency matrix using multi-type dependency relation operators. The feature construction module 630 is used to use a relation feature decoupling operator to perform decoupling processing on the weighted dependency strength based on dependency type, so as to suppress interference between different types of dependencies, and to map the scene vector to the corresponding interface node according to the dependency strength in the dependency matrix to form scene feature components, and to concatenate them with the interface basic features extracted from the interface feature vector to construct node features. The stress testing module 640 is used to perform representation learning and updating of the initial interface dependency graph based on the node features, decoupled dependency relationships and corresponding weighted dependency strengths, using an improved relational graph convolutional network to obtain a weighted dependency graph, and to perform call chain reasoning and dynamic pressure propagation path derivation based on the weighted dependency graph, outputting the key pressure propagation paths and bottleneck interfaces in the system.

[0241] The interface stress testing device provided in this application constructs a basic dataset containing traffic feature vectors, interface feature vectors, and dependency matrices. It then uses a vertical large model to perform stress test scenario inference to generate multi-dimensional scenario vectors, including load intensity, response latency, and bottleneck identification. Based on the dependency matrix, an initial interface dependency graph is constructed. Multi-type dependency operators combined with performance metrics are used to calculate weighted dependency strength. Relationship feature decoupling operators are then used to decouple the weighted dependency strength based on dependency type to suppress inter-type interference. Simultaneously, the scenario vectors are mapped to node scenario feature components according to dependency strength and concatenated with basic interface features to construct node features. Finally, based on node features, decoupled dependencies, and weighted dependency strength, an improved relational graph convolutional network is used for representation learning to obtain a weighted dependency graph. This graph is then used for call chain inference and dynamic pressure propagation path derivation. This achieves more comprehensive and refined coverage of newly added interface stress test scenarios, as well as more accurate and robust representation modeling of complex multi-type dependencies in the system, significantly improving the accuracy of stress testing and the effectiveness of system bottleneck identification.

[0242] Optionally, the device further includes an optimization module for: Based on the key pressure propagation path and the bottleneck interface, and combined with the test feedback obtained from the stress test, the vertical large model is optimized through transfer learning to generate an optimized stress test scenario. Based on the optimized stress test scenario, high-concurrency stress tests are performed through traffic replay, and the node load and edge weight information in the weighted dependency graph are updated according to the new test feedback for the next round of scenario reasoning and path derivation.

[0243] Optionally, when the vector generation module 610 performs stress test scenario inference using a vertical large model, it is specifically used for: By using traffic inference scenario refinement operators, the key features in the scenario vector that affect load intensity, response latency and bottleneck identification dimensions are weighted and refined. By using edge case derivation operators, edge scenarios and extreme scenarios are generated based on the changing trend of load intensity over time in the scenario vector.

[0244] Optionally, when constructing the base dataset for stress testing, the vector generation module 610 is specifically used for: Extract time series, request volume, response time, throughput, and error rate data from the request logs and performance metrics contained in historical traffic data to form the traffic feature vector; From the configuration parameters and upstream and downstream dependencies contained in the newly added interface business data, extract the protocol, call type, resource consumption and dependent interface list to form the interface feature vector; Based on the upstream and downstream dependencies, a dependency matrix is ​​constructed to represent the direction and strength of dependencies between interfaces in matrix form.

[0245] Optionally, the performance metrics associated with the dependency type include at least two of response time, resource consumption, and error rate.

[0246] Optionally, when the feature construction module 630 performs decoupling processing using the relation feature decoupling operator, it is specifically used for: Assign independent decoupling weights to different types of dependencies; Based on the decoupling weights, when the improved relational graph convolutional network performs message aggregation, the contribution of different types of dependencies to the target node representation update is adjusted to reduce the masking effect of high-latency or high-frequency call type dependencies on the representation of other types of dependencies.

[0247] Optionally, in the improved relational graph convolutional network, during the message propagation process, neighbor node information weighted by the weighted dependency strength is aggregated, and the training process of the improved relational graph convolutional network is optimized by minimizing the multi-dimensional coupling scenario generation loss function.

[0248] Optionally, when the stress testing module 640 performs dynamic stress propagation path derivation based on the weighted dependency graph, it is specifically used for: In the weighted dependency graph, the path that minimizes the sum of the products of the inverse of the weighted dependency strength of each dependency edge on the path and the load resource ratio of each interface node is selected as the critical pressure propagation path.

[0249] Optionally, when identifying the bottleneck interface, the stress testing module 640 is specifically used for: In the weighted dependency graph, the interface node with the highest load level to resource processing capacity ratio and the strongest pressure transmission intensity to the neighbor nodes of the bottleneck interface is identified.

[0250] Optionally, the vertical large model is optimized through transfer learning, and the optimization objective function of the transfer learning is to assign higher optimization weights to the scene generation loss located on the key pressure propagation path and the scene generation loss involving the bottleneck interface.

[0251] The interface stress testing device 600 can achieve Figures 1-5 For details of the method implementation examples, please refer to [link / reference]. Figures 1-5 The interface stress testing method shown in the embodiment will not be described in detail again.

[0252] Figure 7 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. For example... Figure 7 As shown, the device includes a memory 71 and a processor 72.

[0253] Memory 71 is used to store computer programs and can be configured to store various other data to support operation on the computing device. Examples of this data include instructions for any application or method used to operate on the computing device, contact data, phone book data, messages, images, videos, etc.

[0254] Processor 72, coupled to memory 71, is used to execute a computer program in memory 71 for: constructing a base dataset for stress testing, the base dataset including traffic feature vectors extracted from historical traffic data, interface feature vectors extracted from newly added interface service data, and a dependency matrix characterizing the dependencies and strengths between interfaces; and, based on the traffic feature vectors, the interface feature vectors, and the dependency matrix, performing stress test scenario inference using a vertical large model to generate scenario vectors containing dimensions of load intensity, response latency, and bottleneck identification; constructing an initial interface dependency graph of the system based on the dependency matrix, and using multi-type dependency operators, calculating the initial interface dependency graph based on the dependency types and associated performance metrics in the dependency matrix. The weighted dependency strength of each dependency edge in the dependency graph is determined. A relational feature decoupling operator is used to decouple the weighted dependency strength based on dependency type to suppress interference between different types of dependencies. The scene vector is mapped to the corresponding interface node according to the dependency strength in the dependency matrix, forming a scene feature component. This component is then concatenated with the interface basic features extracted from the interface feature vector to construct node features. Based on the node features, the decoupled dependency relationships, and the corresponding weighted dependency strengths, an improved relational graph convolutional network is used to perform representation learning and updating on the initial interface dependency graph to obtain a weighted dependency graph. Call chain inference and dynamic pressure propagation path derivation are then performed based on the weighted dependency graph, outputting the key pressure propagation paths and bottleneck interfaces in the system.

[0255] The electronic device provided in this application constructs a basic dataset containing traffic feature vectors, interface feature vectors, and dependency matrices. It then uses a vertical large model to perform stress test scenario inference to generate multi-dimensional scenario vectors, including load intensity, response latency, and bottleneck identification. Based on the dependency matrix, an initial interface dependency graph is constructed. Multi-type dependency operators combined with performance metrics are used to calculate weighted dependency strength. Relationship feature decoupling operators are then used to decouple the weighted dependency strength based on dependency type to suppress inter-type interference. Simultaneously, the scenario vectors are mapped to node scenario feature components according to dependency strength and concatenated with basic interface features to construct node features. Finally, based on node features, decoupled dependencies, and weighted dependency strength, an improved relational graph convolutional network is used for representation learning to obtain a weighted dependency graph. This graph is then used for call chain inference and dynamic pressure propagation path derivation. This achieves more comprehensive and refined coverage of newly added interface stress test scenarios, as well as more accurate and robust representation modeling of complex multi-type dependencies in the system, significantly improving the accuracy of stress testing and the effectiveness of system bottleneck identification.

[0256] Furthermore, such as Figure 7 As shown, the electronic device also includes other components such as a communication component 73, a display 74, a power supply component 75, and an audio component 77. Figure 7 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 7 The components shown. Additionally, depending on the implementation of the traffic playback device, Figure 7 The components within the dashed box are optional, not mandatory. For example, when an electronic device is implemented as a terminal device such as a smartphone, tablet, or desktop computer, it may include... Figure 7 The components within the dashed box; when the electronic device is implemented as a server-side device such as a conventional server, cloud server, data center, or server array, it may be excluded. Figure 7 The component within the dashed box.

[0257] The above Figure 7 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may further include a Near Field Communication (NFC) module, Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wideband (UWB) technology, Bluetooth (BT) technology, etc.

[0258] The above Figure 7 The memory in the memory can be implemented by any class of volatile or non-volatile storage devices or combinations thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0259] The above Figure 7 The display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe action, but also the duration and pressure associated with the touch or swipe operation.

[0260] The above Figure 7 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0261] The above Figure 7 The audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0262] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments.

[0263] Accordingly, this application also provides a computer program product, which stores instructions that, when executed by a computer, cause the computer to perform the steps in the method embodiments provided in this application.

[0264] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0265] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0266] 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.

[0267] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0268] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0269] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), disks, or optical discs.

[0270] It should be understood that the training and prediction processes of the AI ​​models involved in the various embodiments of this specification all adhere to multiple legal and compliant principles, including legal data sources, compliant data content, compliant data governance, compliant training objectives and schemes, compliant training processes, compliant training environments and tools, and compliant ethical verification of training results, and comply with the requirements of Article 5 of the Patent Law. Among them: Data Source Legality: All datasets used for AI model training were obtained through legal channels, covering three categories: publicly authorized data, data authorized by partners, and self-collected compliant data. Publicly authorized data originates from compliant data sources following open-source licenses such as Apache 2.0, with complete copyright attribution and authorization scope clearly marked, and no unauthorized open-source code or data reuse. Data authorized by partners has been subject to formal data usage agreements, clearly defining the scope, duration, and confidentiality obligations, and possessing a complete authorization chain. For self-collected data involving personal information, strict informed consent procedures have been followed, and anonymization processes (including but not limited to field masking, feature anonymization, and differential privacy technology applications) have been implemented to remove personally identifiable information, fully complying with the requirements of the "Interim Measures for the Administration of Generative Artificial Intelligence Services," the "Personal Information Protection Law," and other relevant laws and regulations.

[0271] Data Content Compliance: The AI ​​model's dataset undergoes multiple screening and cleaning processes to remove all content that may violate social morality or harm public interests. It contains no obscene, pornographic, violent, discriminatory, or information that endangers national or public safety, nor does it involve the illegal acquisition or use of genetic resources. For data in sensitive areas (such as healthcare and finance), an additional privacy-preserving computation module (including federated learning and secure multi-party computation technologies) ensures that the data is "usable but not visible," avoiding compliance risks during the original data transmission process and ensuring that the data application scenarios and uses comply with public order and good morals and industry regulatory requirements.

[0272] Data governance compliance: A complete data traceability system is established during the AI ​​model training process to automatically record the source, collection time, annotation process, cleaning rules, and permission allocation of training data, generating traceable compliance reports to ensure that the data is verifiable throughout its entire lifecycle. The dataset annotation process for AI models is completed by a professional human R&D team, clearly defining the proportion of human creative contributions, avoiding reliance on AI-generated data that has not undergone substantial human modification, and complying with the examination requirements for "human main contributions" in AI patent applications.

[0273] Training objectives and schemes are compliant: The training objectives of the AI ​​model focus on interface stress testing. The training scheme and the final output results do not violate any mandatory provisions of laws and administrative regulations, do not harm the public interest or the legitimate rights and interests of others, and do not pose any potential risks of being used for illegal activities, privacy infringement, or public safety disruption. The ethical principle of "intelligent for good" is strictly practiced.

[0274] Compliance of the training process: A closed-loop training framework is adopted to ensure compliance and controllability of the training process. The specific process is as follows: First, training samples are obtained through compliant data sources. After the aforementioned data cleaning and desensitization, they are input into the neural network model to generate preliminary training results. Second, an expert system is introduced to verify the preliminary results. Based on preset rules and human expert experience, the feasibility of the results is evaluated, and outputs that may pose ethical risks or compliance hazards are corrected (such as removing decision logic that violates public order and good morals, and adjusting model parameters that do not comply with safety regulations). Finally, the loss function weights are dynamically optimized based on the feedback from the expert system to strengthen the model's learning of compliant results, avoid overfitting errors or non-compliant labels, and form a closed-loop control of "data input - model training - expert verification - parameter optimization - result feedback" to ensure that the entire training process complies with A5 ethical review requirements.

[0275] Training Environment and Tools Compliance: AI model training is implemented based on nationally licensed chips and a compliant training platform. All open-source frameworks and components used in the training process have obtained their corresponding licenses, and copyright statements and patent citation information are fully retained, with no instances of infringement or reuse. The training environment is constructed using virtual devices (containers / virtual machines) with fixed random seeds and initial parameter configurations to ensure the reproducibility of the training process. Furthermore, through access control and operation log recording, risks such as data leakage and parameter tampering during training are prevented, ensuring the security and compliance of the training process.

[0276] Training results ethical verification and compliance: After the model is trained, it undergoes additional third-party ethical compliance assessment and algorithm filing review to verify that the model output does not violate social morality or harm public interests. For potentially sensitive scenarios (such as public services and intelligent decision-making), a special result verification mechanism is established to ensure that the model always complies with Article 5 of the Patent Law and relevant laws and regulations in practical applications.

[0277] In summary, the data and training process used in the AI ​​model of this specification strictly comply with the relevant provisions of Article 5 of the Patent Law and the Patent Examination Guidelines (2023 Edition), and there are no violations of laws, social ethics, public interests, or illegal use of genetic resources. It fully meets the compliance requirements for patent authorization.

[0278] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An interface stress testing method, characterized in that, include: A basic dataset for stress testing is constructed, which includes traffic feature vectors extracted from historical traffic data, interface feature vectors extracted from newly added interface business data, and a dependency matrix representing the dependency relationship and strength between interfaces. Based on the traffic feature vectors, the interface feature vectors and the dependency matrix, a vertical large model is used to perform stress test scenario inference to generate scenario vectors containing dimensions of load intensity, response latency and bottleneck identification. The initial interface dependency graph of the system is constructed based on the dependency matrix, and the weighted dependency strength of each dependency edge in the initial interface dependency graph is calculated using multi-type dependency relation operators based on the dependency type and associated performance indicators in the dependency matrix. Using relational feature decoupling operators, the weighted dependency strength is decoupled based on dependency type to suppress interference between different types of dependencies. The scene vector is mapped to the corresponding interface node according to the dependency strength in the dependency matrix to form scene feature components, which are then concatenated with the interface basic features extracted from the interface feature vector to construct node features. Based on the node features, the decoupled dependencies, and the corresponding weighted dependency strengths, an improved relational graph convolutional network is used to perform representation learning and updating on the initial interface dependency graph to obtain a weighted dependency graph. Based on the weighted dependency graph, call chain reasoning and dynamic pressure propagation path derivation are performed to output the key pressure propagation paths and bottleneck interfaces in the system.

2. The method according to claim 1, characterized in that, The method further includes: Based on the key pressure propagation path and the bottleneck interface, and combined with the test feedback obtained from the stress test, the vertical large model is optimized through transfer learning to generate an optimized stress test scenario. Based on the optimized stress test scenario, high-concurrency stress tests are performed through traffic replay, and the node load and edge weight information in the weighted dependency graph are updated according to the new test feedback for the next round of scenario reasoning and path derivation.

3. The method according to claim 1, characterized in that, The method of using a large vertical model for stress test scenario inference includes: By using traffic inference scenario refinement operators, the key features in the scenario vector that affect load intensity, response latency and bottleneck identification dimensions are weighted and refined. By using edge case derivation operators, edge scenarios and extreme scenarios are generated based on the changing trend of load intensity over time in the scenario vector.

4. The method according to claim 1, characterized in that, The foundational dataset used for stress testing includes: Extract time series, request volume, response time, throughput, and error rate data from the request logs and performance metrics contained in historical traffic data to form the traffic feature vector; From the configuration parameters and upstream and downstream dependencies contained in the newly added interface business data, extract the protocol, call type, resource consumption and dependent interface list to form the interface feature vector; Based on the upstream and downstream dependencies, a dependency matrix is ​​constructed to represent the direction and strength of dependencies between interfaces in matrix form.

5. The method according to claim 1, characterized in that, The performance metrics associated with the dependency type include at least two of the following: response time, resource consumption, and error rate.

6. The method according to claim 1 or 5, characterized in that, The decoupling process using relational feature decoupling operators includes: Assign independent decoupling weights to different types of dependencies; Based on the decoupling weights, when the improved relational graph convolutional network performs message aggregation, the contribution of different types of dependencies to the target node representation update is adjusted to reduce the masking effect of high-latency or high-frequency call type dependencies on the representation of other types of dependencies.

7. The method according to claim 1, characterized in that, The improved relational graph convolutional network aggregates neighbor node information weighted by the weighted dependency strength during message propagation. The training process of the improved relational graph convolutional network is optimized by minimizing the multi-dimensional coupled scenario generation loss function.

8. The method according to claim 1, characterized in that, The dynamic pressure propagation path derivation based on the weighted dependency graph includes: In the weighted dependency graph, the path that minimizes the sum of the products of the inverse of the weighted dependency strength of each dependency edge on the path and the load resource ratio of each interface node is selected as the critical pressure propagation path.

9. The method according to claim 2, characterized in that, The identification of the bottleneck interface includes: In the weighted dependency graph, the interface node with the highest load level to resource processing capacity ratio and the strongest pressure transmission intensity to the neighbor nodes of the bottleneck interface is identified.

10. The method according to claim 2, characterized in that, The vertical large model is optimized through transfer learning, and the optimization objective function of the transfer learning is to assign higher optimization weights to the scene generation loss located on the key pressure propagation path and the scene generation loss involving the bottleneck interface.

Images