Traffic analysis-based stress test model deduction method and device, computer device, and medium

Abstract

The application relates to a traffic analysis-based pressure test model deduction method and device, computer equipment and a medium. The method comprises the following steps: acquiring a simulation traffic dataset consistent with online real traffic characteristics; determining the strong and weak dependency relationships between services according to the full-link service call information of a system; constructing an initial pressure test model according to the simulation traffic dataset and the strong and weak dependency relationships, wherein the initial pressure test model defines the basic pressure test load of each pressure test interface in the link; determining the pressure test target value of each pressure test interface according to the initial pressure test model; performing pressure test according to the initial pressure test model and the pressure test target value, collecting actual performance data in the pressure test process, comparing the actual performance data with the pressure test target value, adjusting the parameters of the initial pressure test model according to the comparison result, and obtaining a target pressure test model until the actual performance data meet a preset condition. The application can realize the integration of traffic and links and the dynamic calibration of the model, and improves the simulation degree, bottleneck positioning accuracy and model reusability of pressure test.

Description

Technical Field

[0001] This application relates to the field of software performance testing technology, and in particular to a stress testing model derivation method, apparatus, computer equipment, and medium based on traffic analysis. Background Technology

[0002] With the widespread adoption of distributed systems and microservice architectures, software system performance testing faces higher demands. As a crucial means of assessing system capacity and identifying performance bottlenecks, load testing's accuracy directly impacts the direction and effectiveness of system performance optimization.

[0003] Current load testing methods typically obtain modeling basis from two aspects: One method is to obtain online traffic characteristics through traffic replication; Secondly, the system service call relationships are obtained through link analysis.

[0004] However, these two approaches are often fragmented in practice. Traffic replication focuses only on data characteristics at the request level, while link analysis focuses only on the call topology between services; the two lack effective integration. This results in load testing models that fail to accurately simulate the flow of real traffic in complex service links, leading to insufficient model simulation and significant deviations between load testing results and actual online operation.

[0005] Furthermore, once existing load testing models are built, they typically lack a mechanism for continuous comparison and dynamic calibration with real-world online conditions. When online traffic fluctuates or business processes iterate, the existing load testing models struggle to adapt to these changes, exhibiting poor model reusability and requiring repeated rebuilding, thus reducing testing efficiency. Summary of the Invention

[0006] To address the aforementioned deficiencies or shortcomings, this application provides a method, apparatus, computer equipment, and medium for deducing a pressure testing model based on flow analysis.

[0007] This application provides a stress testing model derivation method based on flow analysis according to a first aspect, the method comprising: Obtain a simulated traffic dataset that matches the characteristics of real online traffic; Determine the strong and weak dependencies between services based on the system's end-to-end service call information; An initial load testing model is constructed based on the simulated traffic dataset and strong and weak dependencies. The initial load testing model defines the basic load testing load of each load testing interface in the link. The target values ​​for each stress test interface are determined based on the initial stress test model; The stress test is performed based on the initial stress test model and the target stress test value. During the stress test, actual performance data is collected and compared with the target stress test value. The parameters of the initial stress test model are adjusted according to the comparison results until the actual performance data meets the preset conditions, thus obtaining the target stress test model.

[0008] In some embodiments, obtaining a simulated traffic dataset that matches the characteristics of real online traffic includes: Real online traffic is replicated to the test environment using traffic mirroring. A shadow database isolated from the online database is built, and key identifiers in the replicated traffic are offset to obtain a simulated traffic dataset that is consistent with the characteristics of the online traffic and is secure.

[0009] In some embodiments, determining the strong and weak dependencies between services based on the system's end-to-end service call information includes: The call logs of each service node are collected using a link tracing tool deployed on the system; Extract call characteristic indicators from the call logs; these indicators include call frequency and the scope of fault impact. The strong and weak dependencies between services are determined based on the call characteristic indicators and the preset strong and weak dependency judgment criteria, and a strong and weak dependency table and a link call topology diagram are generated.

[0010] In some embodiments, an initial load testing model is constructed based on the simulated traffic dataset and strong / weak dependencies, including: Generate a large load testing link diagram based on the link call topology diagram and the strong and weak dependency relationship table; Determine the load testing interfaces for each service node and their load testing priorities based on the load testing link diagram; Based on the load testing priority and the actual online request frequency, the simulated traffic dataset is allocated to each load testing interface to obtain the initial load testing model.

[0011] In some embodiments, determining the target load test value for each load test interface based on the initial load test model includes: The traffic distribution characteristics of each stress test interface and link are determined based on the initial stress test model; Based on traffic distribution characteristics and business requirements, load test target values ​​and load test scenarios are generated for each load test interface. The load test target values ​​include at least one of throughput, response time, and error rate.

[0012] In some embodiments, the parameters of the initial stress test model are adjusted based on the comparison results until the actual performance data meets preset conditions, including: Analyze the deviation between the actual performance data and the target value of the pressure test to obtain the deviation analysis results, and determine the cause of the deviation based on the deviation analysis results; Adjust the interface load distribution ratio, scenario traffic fluctuation settings, or strong / weak dependency interface priority weights in the initial load testing model according to the cause of the deviation. Determine whether the deviation between the actual performance data and the target value of the load test is less than or equal to the preset deviation threshold. If not, return the steps of performing the load test based on the adjusted initial load test model and the target value of the load test. If yes, obtain the adjusted initial load test model as the target load test model.

[0013] In some embodiments, the target value of the load testing interface is set hierarchically according to the load testing priority of the load testing interface, wherein the target value of the core link interface is higher than that of the non-core link interface, and the target value of the strongly dependent interface is higher than that of the weakly dependent interface.

[0014] According to a second aspect, this application provides a stress testing model extrapolation device based on flow analysis, the device comprising: The simulated traffic data acquisition module is used to acquire a simulated traffic dataset that is consistent with the characteristics of real online traffic. The strong and weak dependency determination module is used to determine the strong and weak dependencies between services based on the system's end-to-end service call information. The initial load testing model building module is used to build an initial load testing model based on the simulation traffic dataset and strong and weak dependencies. The initial load testing model defines the basic load testing load of each load testing interface in the link. The load testing target determination module is used to determine the load testing target values ​​for each load testing interface based on the initial load testing model. The model dynamic calibration module is used to perform stress testing based on the initial stress testing model and the target stress testing value. During the stress testing process, it collects actual performance data, compares the actual performance data with the target stress testing value, and adjusts the parameters of the initial stress testing model according to the comparison results until the actual performance data meets the preset conditions, thus obtaining the target stress testing model.

[0015] According to a third aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the stress testing model derivation methods based on traffic analysis in the above embodiments.

[0016] According to a fourth aspect, this application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the load testing model derivation methods based on traffic analysis in the above embodiments.

[0017] This application integrates real online traffic characteristics with the strong and weak dependencies across the entire link and introduces a closed-loop dynamic calibration mechanism, which effectively improves the simulation accuracy, bottleneck location accuracy, and model reusability of the stress testing model.

[0018] This application firstly obtains a simulated traffic dataset consistent with real online traffic characteristics, ensuring that the basic data for load testing comprehensively reflects the traffic characteristics of the entire online scenario, avoiding model deviations caused by traffic replication distortion in traditional load testing. Secondly, by determining the strong and weak dependencies between services based on the system's full-link service call information, and combining the simulated traffic dataset and the strong and weak dependencies, an initial load testing model is constructed to define the basic load testing load of each interface. This accurately maps traffic characteristics to each node in the link, effectively solving the problem of the separation between traffic replication and link investigation in existing technologies, making the load testing scenario highly consistent with the real online flow. Thirdly, by determining the load testing target value for each load testing interface based on the initial load testing model, a clear quantitative standard can be provided for performance evaluation. Finally, by executing load testing and continuously comparing the actual performance data with the load testing target value, and repeatedly adjusting the model parameters according to the comparison results until the preset conditions are met, the load testing model can automatically adapt to dynamic fluctuations in online traffic and changes in business, without the need to repeatedly build the model, effectively improving testing efficiency and model reusability. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a stress testing model derivation method based on traffic analysis in one or more embodiments of this application; Figure 2 This is a timing diagram showing the derivation of the stress testing model in one or more embodiments of this application; Figure 3 This is a schematic diagram of the structure of a pressure testing model extrapolation device based on flow analysis in one or more embodiments of this application; Figure 4 This is a schematic diagram of the internal structure of a computer device according to one or more embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the described embodiments are merely some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0021] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0022] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0023] To address the shortcomings or defects of related technologies, this application provides a load testing model extrapolation method based on traffic analysis. This method integrates online real traffic characteristics with the strong and weak dependencies across the entire link and introduces a closed-loop dynamic calibration mechanism, which can effectively improve the simulation accuracy, bottleneck location accuracy, and model reusability of the load testing model.

[0024] In some exemplary embodiments of this application, such as Figure 1 As shown, the method includes steps S110-S150. The following example demonstrates how this method is applied to a server. Figure 2 The timing diagram of the stress testing model shown provides a detailed explanation of each step in the method.

[0025] S110: Obtain a simulated traffic dataset that matches the characteristics of real online traffic.

[0026] Simulated traffic datasets refer to test data sets generated through replication and isolation that maintain consistency with real online traffic in terms of request parameters, data format, traffic fluctuation patterns, request frequency, and other characteristics, but will not affect online business operations.

[0027] This step, by acquiring a simulated traffic dataset that matches the characteristics of real online traffic, ensures that the load testing data fully reflects the real online traffic scenario, avoiding deviations in the load testing model caused by data distortion.

[0028] S120: Determine the strong and weak dependencies between services based on the system's end-to-end service call information.

[0029] The system's end-to-end service call information refers to a set of information reflecting characteristics such as call relationships, call frequency, response time, and fault impact range among service nodes within the system. Strong and weak dependencies refer to the types of inter-service dependencies categorized based on the degree of impact of downstream service failures on upstream services. Strong dependencies mean that a downstream service failure directly causes the upstream service to become unavailable and affects core business processes, while weak dependencies mean that a downstream service failure only affects non-core supplementary functions without affecting the core functions of the upstream service.

[0030] In this step, the server extracts the call characteristics between each service node based on the system's end-to-end service call information, and determines the strong and weak dependencies between services by combining them with preset judgment criteria.

[0031] S130: Construct an initial load testing model based on the simulated traffic dataset and strong / weak dependencies. The initial load testing model defines the basic load testing load of each load testing interface in the link.

[0032] The initial load testing model refers to a load testing model that has not yet undergone dynamic calibration and has preliminarily defined the load distribution and call relationships of each load testing interface. The load testing interface refers to the service call interface in the system chain that needs to be stress tested. The basic load testing load refers to the load testing pressure parameters set for each load testing interface, such as the initial request frequency, data volume, or concurrency.

[0033] In this step, the server distributes the simulated traffic dataset to each load testing interface according to the link structure determined by the strong and weak dependencies, sets the basic load testing load for each load testing interface, and thus builds the initial load testing model.

[0034] This step builds an initial load testing model by combining simulated traffic datasets and strong / weak dependencies, which can accurately map traffic characteristics to each node in the link, making the load testing scenario closely resemble the actual online flow.

[0035] S140: Determine the target values ​​for each load testing interface based on the initial load testing model.

[0036] The target value of a load test refers to the expected performance metric set for each load test interface, including at least one of throughput, response time, and error rate.

[0037] In this step, the server determines the target load value for each load testing interface based on the basic load and link distribution characteristics of each load testing interface in the initial load testing model.

[0038] This step, by determining the target values ​​for each stress test interface, provides a clear quantitative standard for subsequent model calibration and performance evaluation.

[0039] S150: Perform stress testing based on the initial stress testing model and the target stress testing value. During the stress testing process, collect actual performance data, compare the actual performance data with the target stress testing value, and adjust the parameters of the initial stress testing model according to the comparison results until the actual performance data meets the preset conditions, thus obtaining the target stress testing model.

[0040] Actual performance data refers to the real-time performance metrics such as response time, throughput, and error rate of each load testing interface collected during the load testing process. The target load testing model refers to the final load testing model whose actual performance data, after dynamic calibration, deviates from the target load testing value under preset conditions.

[0041] In this step, the server performs load testing according to the initial load testing model and the target load testing value, collects the actual performance data of each load testing interface in real time, continuously compares the actual performance data with the target load testing value, and repeatedly adjusts the load distribution, traffic fluctuation and other parameters of the initial load testing model according to the deviation until the deviation between the actual performance data and the target load testing value meets the preset conditions. The adjusted initial load testing model is then used as the target load testing model.

[0042] This step, through a closed-loop process of load testing execution, data collection, comparison, and parameter adjustment, enables the load testing model to adapt to dynamic fluctuations in online traffic and changes in business, eliminating the need to repeatedly build the model.

[0043] This embodiment first obtains a simulated traffic dataset consistent with the characteristics of real online traffic, ensuring that the basic data for load testing comprehensively reflects the traffic characteristics of the entire online scenario, avoiding model deviations caused by traffic replication distortion in traditional load testing. Second, by determining the strong and weak dependencies between services based on the system's full-link service call information, and combining the simulated traffic dataset and the strong and weak dependencies, an initial load testing model is constructed to define the basic load testing load of each load testing interface. This accurately maps traffic characteristics to each node in the link, effectively solving the problem of the separation between traffic replication and link investigation in existing technologies, making the load testing scenario highly consistent with the real online flow. Third, by determining the load testing target value for each load testing interface based on the initial load testing model, a clear quantitative standard can be provided for performance evaluation. Finally, by executing load testing and continuously comparing the actual performance data with the load testing target value, and repeatedly adjusting the model parameters according to the comparison results until the preset conditions are met, the load testing model can automatically adapt to dynamic fluctuations in online traffic and changes in business, without the need to repeatedly build the model, effectively improving testing efficiency and model reusability.

[0044] In some embodiments, obtaining a simulated traffic dataset consistent with the characteristics of real online traffic includes: copying real online traffic to a test environment through traffic mirroring; building a shadow library isolated from the online database; offsetting key identifiers in the copied traffic to obtain a simulated traffic dataset that is consistent with the characteristics of online traffic and secure.

[0045] Traffic mirroring refers to the technical means of completely replicating and forwarding real online business traffic to the test environment without affecting the normal operation of online business. A shadow database is a dedicated test database that is completely consistent with the online database in terms of table structure and index design, but completely isolated at the data level. A key identifier is a field in traffic data that can uniquely identify a business entity or related data record, including at least one of user ID, order ID, API call ID, and session identifier. Offset processing refers to transforming key identifiers according to a preset algorithm so that the transformed identifiers do not conflict with the real online identifiers, while maintaining the data relationships.

[0046] In this embodiment, the server first deploys a traffic replication component at the network access layer or application middleware layer of the online business system using traffic mirroring technology. This asynchronously replicates the entire online traffic and forwards it to a pre-built test environment. The online traffic comprehensively covers all traffic types across various scenarios, including normal business traffic, peak promotional traffic, and abnormal request traffic. In the test environment, the server builds a shadow database with the same structure as the online database, which is completely isolated from the online database at the physical or logical level. For the traffic data replicated to the test environment, the server identifies the key identifier fields and uses a hash offset algorithm or a random offset algorithm to offset the key identifiers. Taking the hash offset algorithm as an example, the server concatenates the original key identifier with a preset salt value, calculates a fixed-length hash value using a hash function, and replaces the original key identifier with this hash value. Taking the random offset algorithm as an example, the server adds a preset random offset to the original key identifier to obtain the offset key identifier. After offset processing, the data generated during the load test will be written to the shadow library, which will be completely isolated from the online real data at the storage level. At the same time, the request parameter structure, data format, traffic fluctuation pattern and request frequency of the original traffic data will be preserved, and finally a simulated traffic dataset that is consistent with the characteristics of online traffic and is secure will be obtained.

[0047] This embodiment replicates online traffic across all scenarios using traffic mirroring and combines it with shadow library offset isolation. This ensures that the simulated traffic dataset fully restores the characteristics of real online traffic, while completely isolating stress test data from online data, thus preventing stress testing from interfering with online business and causing data pollution.

[0048] In some embodiments, determining the strong and weak dependencies between services based on the system's end-to-end service call information includes: collecting call logs of each service node through a link tracing tool deployed on the system; extracting call feature indicators from the call logs; the call feature indicators include call frequency and fault impact range; determining the strong and weak dependencies between services based on the call feature indicators and preset strong and weak dependency judgment criteria, and generating a strong and weak dependency table and a link call topology diagram.

[0049] Link tracing tools are software components deployed in distributed systems or microservice architectures to uniquely identify, trace, and monitor the performance of request call chains across service nodes. Examples include at least one of SkyWalking and Pinpoint. Call logs are log entries automatically recorded by the link tracing tool each time an inter-service call occurs, including information such as call source, call target, call timestamp, response time, and call result. Call characteristic metrics are quantitative parameters extracted from call logs that characterize the strength and impact of inter-service call relationships. Call frequency refers to the number of calls initiated by an upstream service to a downstream service per unit of time. Fault impact scope refers to the number of requests or the percentage of business functions affected in the upstream service when a downstream service fails. Pre-defined strong / weak dependency judgment criteria are pre-configured rules for distinguishing between strong and weak dependencies. A strong / weak dependency table is a structured data table recording the type of dependency relationship between each pair of services and the judgment criteria. A link call topology graph is a directed graph with services as nodes and call relationships as edges, used to visually display the call hierarchy and dependency relationships between service nodes throughout the entire system link.

[0050] In this embodiment, the server uses a system-deployed link tracing tool to automatically embed call logs at the call entry and exit points of each service node, collecting call logs for every inter-service call. The server aggregates and analyzes the collected call logs, extracting call characteristic indicators, including call frequency and fault impact scope. Specifically, the server counts the number of calls between each pair of upstream and downstream services within a preset time window as the call frequency; the server analyzes the fault records of downstream services, retrospectively determining the number of requests that caused upstream services to return errors or timeouts due to the fault of the downstream service, thereby determining the fault impact scope. The server matches and compares the extracted call characteristic indicators with preset strong and weak dependency judgment criteria to determine the dependency relationship type between each pair of services.

[0051] The preset criteria for determining strong and weak dependencies may include: if a failure of a downstream service directly causes the upstream service to become unavailable and affects core business processes, it is determined to be a strong dependency; if a failure of a downstream service only affects non-core supplementary functions and does not affect the core functions of the upstream service, it is determined to be a weak dependency.

[0052] In specific judgments, the server can set thresholds for the scope of fault impact or call frequency as auxiliary judgment criteria. For example, when a downstream service failure causes more than a preset proportion of upstream service requests to fail, it is judged as a strong dependency relationship. Based on the judgment results, the server generates a strong and weak dependency relationship table, which records the dependency direction, dependency type, and judgment criteria for each pair of services. At the same time, the server generates a link call topology graph with service nodes as vertices and call relationships as directed edges, marking the strong and weak dependency types of each call edge in the graph and distinguishing between core links and non-core links.

[0053] This embodiment uses a link tracing tool to automatically collect call logs and extract objective indicators such as call frequency and fault impact range. Combined with preset judgment criteria, it quantifies the strong and weak dependencies, which can improve the accuracy and consistency of dependency judgment and avoid the subjectivity and omissions of manual judgment.

[0054] In some embodiments, an initial load testing model is constructed based on the simulated traffic dataset and strong / weak dependencies, including: generating a large load testing link diagram based on the link call topology diagram and the strong / weak dependency table; determining the load testing interface of each service node and the load testing priority of the load testing interface based on the large load testing link diagram; and allocating the simulated traffic dataset to each load testing interface according to the load testing priority and the actual online request frequency to obtain the initial load testing model.

[0055] The load testing pipeline graph refers to a directed graph that integrates strong and weak dependency information, core and non-core pipelines, based on the pipeline call topology graph, to form a complete load testing scope. It is used to clearly define the overall coverage and pipeline boundaries of the load testing. Load testing interfaces refer to the callable interfaces exposed by each service node in the load testing pipeline graph; they are the targets directly subjected to load testing. Load testing priority refers to the priority level of load testing execution and resource allocation assigned to each load testing interface based on the strong and weak dependency types of the pipeline to which the interface belongs and the business importance.

[0056] In this embodiment, the server first uses the link call topology graph as a basic framework, overlaying the dependency type information of each pair of services recorded in the strong and weak dependency relationship table onto the corresponding call edges of the topology graph, forming a large load testing link graph including dependency type annotations. This large load testing link graph clearly distinguishes between core links composed of strong dependencies and non-core links composed of weak dependencies, and clarifies the overall scope and link boundaries of the load testing. Next, the server decomposes the load testing link graph layer by layer from top to bottom according to the business logic hierarchy of each service node, determining the specific load testing interfaces that need to participate in the load testing for each service node.

[0057] For each load testing interface, the server sets the load testing priority based on the strong or weak dependency type of its associated link and the degree to which the interface supports the core business process. For example, the load testing target value of the load testing interface is set hierarchically according to the load testing priority of the interface, wherein the load testing priority of core link interfaces is higher than that of non-core link interfaces, and the load testing priority of strongly dependent interfaces is higher than that of weakly dependent interfaces; for interfaces within the same link layer, the priority can be further subdivided according to their actual online request frequency or business importance.

[0058] After completing interface decomposition and priority setting, the server allocates the simulated traffic dataset according to the load testing priority of each load testing interface and the actual online request frequency. During allocation, interfaces with higher load testing priorities receive simulated traffic data that matches their actual online request frequency. The server determines the basic load testing load for each interface based on the proportion of its actual online request frequency. The basic load testing load includes at least one of request frequency, data volume, and concurrency. Through this allocation, each load testing interface receives a basic load testing load proportional to the actual online scenario, thus completing the construction of the initial load testing model.

[0059] This embodiment constructs a large load testing link graph and sets interface priorities in layers based on strong and weak dependencies. This allows for precise allocation of simulated traffic to each load testing interface, ensuring that the load distribution of the initial load testing model is proportional to the actual online flow. This avoids investing too many load testing resources in non-core links, achieving focused and efficient utilization of load testing resources.

[0060] In some embodiments, determining the target values ​​for each load testing interface based on an initial load testing model includes: determining the traffic distribution characteristics of each load testing interface and link based on the initial load testing model; generating the target values ​​and load testing scenarios for each load testing interface based on the traffic distribution characteristics and business requirements, wherein the target values ​​include at least one of throughput, response time, and error rate.

[0061] Traffic distribution characteristics refer to the statistical properties of simulated traffic data on each load testing interface and link in the initial load testing model, such as request volume distribution, request frequency distribution, traffic fluctuation period, and peak traffic patterns. Load testing target values ​​refer to the expected performance indicator thresholds set for each load testing interface based on traffic distribution characteristics and business requirements, including at least one of throughput target values, response time target values, and error rate target values. Load testing scenarios refer to pre-set test situations for different load conditions, including at least one of normal load scenarios, peak load scenarios, and burst traffic load scenarios. Business requirements refer to the performance requirements of the business side for each functional module of the system, including the response time requirements of core business processes, the availability tolerance of non-core functions, and the concurrent processing capability requirements of different business modules.

[0062] In this embodiment, the server first performs statistical analysis on the traffic distribution characteristics of each load testing interface and link based on the basic load testing load distribution and link call relationships of each load testing interface in the initial load testing model. Specifically, the server calculates the total request volume, peak traffic, average request frequency, and traffic fluctuation period for each link according to the business link dimension; and calculates the request frequency distribution, data volume distribution, and concurrent connection distribution for each interface according to the load testing interface dimension.

[0063] Next, based on the aforementioned traffic distribution characteristics and the business requirements provided by the client, the server sets tiered load testing target values ​​for each load testing interface. For interfaces with strong dependencies supporting core business processes in the core chain, the server sets higher load testing target values, such as a response time target of no more than 500 milliseconds, an error rate target of no more than 0.1%, and a throughput target of no less than 1000 operations per second. For interfaces with weak dependencies in the non-core chain, the server sets relatively lenient load testing target values, such as a response time target of no more than 1000 milliseconds, an error rate target of no more than 0.5%, and a throughput target of no less than 500 operations per second. Simultaneously, the server defines corresponding load testing scenarios for each load testing interface based on the peak traffic and fluctuation periods in the traffic distribution characteristics. Normal load scenarios correspond to daily online traffic levels, peak load scenarios correspond to traffic levels during promotional activities or peak business periods, and sudden traffic load scenarios correspond to extreme situations of rapid traffic surges within a short period. Each load testing scenario has a corresponding traffic injection curve and duration set to ensure that the load testing scenarios can realistically reproduce various online load conditions.

[0064] This embodiment generates hierarchical load testing target values ​​and multiple load testing scenarios based on the traffic distribution characteristics and business requirements of the initial load testing model. This allows the performance evaluation standards to align with real online business conditions, providing a clear and verifiable quantitative benchmark for subsequent load testing execution and model calibration.

[0065] In some embodiments, the parameters of the initial load testing model are adjusted according to the comparison results until the actual performance data meets the preset conditions. This includes: analyzing the deviation between the actual performance data and the target load test value, obtaining the deviation analysis results, and determining the cause of the deviation based on the deviation analysis results; adjusting the interface load allocation ratio, scenario traffic fluctuation settings, or strong / weak dependency interface priority weights in the initial load testing model according to the cause of the deviation; determining whether the deviation between the actual performance data and the target load test value is less than or equal to a preset deviation threshold; if not, then based on the adjusted initial load testing model, returning to the step of performing load testing according to the initial load testing model and the target load test value; if yes, then obtaining the adjusted initial load testing model as the target load testing model.

[0066] Actual performance data refers to the real-time operational metrics such as response time, throughput, error rate, and concurrent processing count of each load testing interface, collected in real time by monitoring tools during load testing. Deviation analysis results refer to the difference report obtained after quantitatively comparing the actual performance data with the corresponding load testing target value, including analytical conclusions such as deviation direction, deviation magnitude, and deviation duration. Deviation causes refer to the fundamental factors causing the difference between the actual performance data and the load testing target value, including at least one of the following: unreasonable traffic allocation, deviation in determining strong / weak dependencies, improper interface load testing settings, and link call latency. Interface load allocation ratio refers to the weighted proportion of simulated traffic data among each load testing interface. Scenario traffic fluctuation settings refer to the curve shape and amplitude parameters of the simulated traffic fluctuation over time in the load testing scenario. Strong / weak dependency interface priority weight refers to the weight coefficient set for each load testing interface based on strong / weak dependencies, affecting its resource allocation and verification sorting. Preset deviation threshold refers to the pre-set critical value used to determine whether the deviation between the actual performance data and the load testing target value is acceptable, for example, setting the deviation to not exceed 10%.

[0067] In this embodiment, after each load test is completed, the server compares the actual performance data of each load test interface with the corresponding load test target value item by item, calculating the deviation of each indicator. Then, the server generates a deviation analysis result based on the positive or negative direction and absolute value of the deviation. For example, when the actual response time of a certain load test interface continuously exceeds the load test target value and the excess exceeds a preset deviation threshold, the deviation analysis result shows that the interface has a response time exceeding the standard. Then, the cause of the deviation is determined based on the deviation analysis result. The logic for locating the cause of the deviation may include: If multiple load testing interfaces simultaneously exceed performance limits and are concentrated on a certain link, the deviation may be due to a mismatch between the traffic allocation ratio and the actual carrying capacity of that link. If only weakly dependent interfaces experience performance issues while core interfaces function normally, the deviation may be due to improper priority settings for strong and weakly dependent interfaces, causing non-core interfaces to consume excessive resources. If the performance exceedance only occurs during peak load scenarios or sudden traffic load scenarios, the deviation may be due to a mismatch between the scenario traffic fluctuation settings and the system's actual capacity limit.

[0068] Based on the identified causes of deviation, the server makes targeted adjustments to the parameters of the initial load testing model. Specifically, when the deviation is due to unreasonable traffic allocation, the server adjusts the interface load distribution ratio, reducing the load ratio of interfaces exceeding performance limits and correspondingly increasing the load ratio of interfaces with sufficient performance margin. When the deviation is due to improper scenario traffic fluctuation settings leading to excessively high peak pressure, the server adjusts the peak traffic amplitude or peak duration in the scenario traffic fluctuation settings. When the deviation is due to improper priority weight settings for strong and weak dependency interfaces causing core link resources to be squeezed, the server can increase the priority weight of strong dependency interfaces or decrease the priority weight of weak dependency interfaces. After completing the parameter adjustments, the server determines whether the deviation between the actual performance data of each load testing interface and the target load test value is less than or equal to a preset deviation threshold. If any indicator deviation of any load testing interface exceeds the preset deviation threshold, the server uses the adjusted initial load testing model as the new initial load testing model, returns to the steps of executing the load test based on the initial load testing model and the target load test value, and repeats the next round of load testing execution, performance data collection, comparative analysis, and parameter adjustment operations. If the deviations of all performance indicators of all load testing interfaces are less than or equal to the preset deviation threshold, the server determines that the model calibration is complete and outputs the current adjusted initial load testing model as the target load testing model.

[0069] This embodiment performs closed-loop analysis on the deviation between actual performance data and target values ​​of load testing, and makes targeted adjustments to interface load allocation ratio, scenario traffic fluctuation settings, and priority weights of strong and weak dependency interfaces based on the causes of deviation. This allows the load testing model to gradually approach the actual online operation through repeated iterations, achieving adaptive calibration of the load testing model and avoiding distortion of load testing results or the need for manual model reconstruction due to model deviation.

[0070] It should be noted that, regarding the various steps included in the load testing model extrapolation method based on traffic analysis provided in any of the above embodiments, unless explicitly stated herein, there is no strict order restriction on the execution of these steps; they can be executed in other orders. Furthermore, at least some of these steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is also not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0071] Based on the same inventive concept, this application also provides a stress testing model extrapolation device based on flow analysis. In some embodiments, such as Figure 3 As shown, the stress testing model simulation device based on flow analysis includes the following modules: The simulated traffic data acquisition module 110 is used to acquire a simulated traffic dataset that is consistent with the characteristics of real online traffic. The strong and weak dependency determination module 120 is used to determine the strong and weak dependencies between services based on the system's end-to-end service call information. The initial stress test model construction module 130 is used to construct an initial stress test model based on the simulation traffic dataset and strong and weak dependencies. The initial stress test model defines the basic stress test load of each stress test interface in the link. The load test target determination module 140 is used to determine the load test target value of each load test interface based on the initial load test model; The model dynamic calibration module 150 is used to perform stress testing based on the initial stress testing model and the target stress testing value. During the stress testing process, it collects actual performance data, compares the actual performance data with the target stress testing value, and adjusts the parameters of the initial stress testing model according to the comparison results until the actual performance data meets the preset conditions, thus obtaining the target stress testing model.

[0072] In some embodiments, the step of obtaining a simulated traffic dataset consistent with the characteristics of real online traffic includes: copying real online traffic to a test environment through traffic mirroring; building a shadow library isolated from the online database; offsetting key identifiers in the copied traffic to obtain a simulated traffic dataset that is consistent with the characteristics of online traffic and secure.

[0073] In some embodiments, the step of determining the strong and weak dependencies between services based on the system's end-to-end service call information includes: collecting call logs of each service node through a link tracing tool deployed on the system; extracting call feature indicators from the call logs; the call feature indicators include call frequency and fault impact range; determining the strong and weak dependencies between services based on the call feature indicators and preset strong and weak dependency judgment criteria, and generating a strong and weak dependency table and a link call topology diagram.

[0074] In some embodiments, the step of constructing an initial load testing model based on a simulated traffic dataset and strong / weak dependencies includes: generating a large load testing link diagram based on the link call topology diagram and the strong / weak dependency table; determining the load testing interface of each service node and the load testing priority of the load testing interface based on the large load testing link diagram; and allocating the simulated traffic dataset to each load testing interface according to the load testing priority and the actual online request frequency to obtain the initial load testing model.

[0075] In some embodiments, determining the target values ​​for each load testing interface based on an initial load testing model includes: determining the traffic distribution characteristics of each load testing interface and link based on the initial load testing model; generating the target values ​​and load testing scenarios for each load testing interface based on the traffic distribution characteristics and business requirements, wherein the target values ​​include at least one of throughput, response time, and error rate.

[0076] In some embodiments, the parameters of the initial load testing model are adjusted according to the comparison results until the actual performance data meets the preset conditions. This includes: analyzing the deviation between the actual performance data and the target load test value, obtaining the deviation analysis results, and determining the cause of the deviation based on the deviation analysis results; adjusting the interface load allocation ratio, scenario traffic fluctuation settings, or strong / weak dependency interface priority weights in the initial load testing model according to the cause of the deviation; determining whether the deviation between the actual performance data and the target load test value is less than or equal to a preset deviation threshold; if not, then based on the adjusted initial load testing model, returning to the step of performing load testing according to the initial load testing model and the target load test value; if yes, then obtaining the adjusted initial load testing model as the target load testing model.

[0077] In some embodiments, the target value of the load testing interface is set hierarchically according to the load testing priority of the load testing interface, wherein the target value of the core link interface is higher than that of the non-core link interface, and the target value of the strongly dependent interface is higher than that of the weakly dependent interface.

[0078] Specific limitations regarding the load testing model extrapolation device based on flow analysis can be found in the limitations of the load testing model extrapolation method based on flow analysis described above, and will not be repeated here. Each module in the aforementioned load testing model extrapolation device based on flow analysis can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0079] This application also provides a computer device. In some embodiments, the computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement the load testing model deduction method based on traffic analysis provided in any of the above embodiments.

[0080] In some embodiments, the internal structure diagram of a computer device may be as follows: Figure 4 As shown. The computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores simulated traffic datasets, target values ​​for each load testing interface, and other data; the specific data stored can also be found in the limitations described in the above method embodiments. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a load testing model derivation method based on traffic analysis.

[0081] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0082] This application also provides a computer-readable storage medium, in some embodiments of which a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the load testing model extrapolation method based on traffic analysis provided in any of the above embodiments.

[0083] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0084] Those skilled in the art will understand that all or part of the processes in the above method embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), memory bus, direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

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

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

Claims

1. A method for extrapolating a stress testing model based on flow analysis, characterized in that, The method includes: Obtain a simulated traffic dataset that matches the characteristics of real online traffic; Determine the strong and weak dependencies between services based on the system's end-to-end service call information; An initial load testing model is constructed based on the simulated traffic dataset and the strong and weak dependencies. The initial load testing model defines the basic load testing load of each load testing interface in the link. The target values ​​for each of the stress testing interfaces are determined based on the initial stress testing model. The initial stress test model and the target stress test value are used to perform stress test. During the stress test, actual performance data is collected and compared with the target stress test value. The parameters of the initial stress test model are adjusted according to the comparison result until the actual performance data meets the preset conditions, and the target stress test model is obtained.

2. The method according to claim 1, characterized in that, The acquisition of a simulated traffic dataset that matches the characteristics of real online traffic includes: Real online traffic is replicated to the test environment using traffic mirroring. A shadow database isolated from the online database is built, and key identifiers in the replicated traffic are offset to obtain a simulated traffic dataset that is consistent with the characteristics of the online traffic and is secure.

3. The method according to claim 1, characterized in that, The process of determining strong and weak dependencies between services based on the system's end-to-end service call information includes: The call logs of each service node are collected using a link tracing tool deployed on the system; Extract call characteristic indicators from the call logs; the call characteristic indicators include call frequency and the scope of fault impact. The strong and weak dependency relationships between services are determined based on the call characteristic indicators and the preset strong and weak dependency judgment criteria, and a strong and weak dependency relationship table and a link call topology diagram are generated.

4. The method according to claim 3, characterized in that, The step of constructing the initial load testing model based on the simulated traffic dataset and the strong and weak dependencies includes: Based on the link call topology diagram and the strong and weak dependency relationship table, a large stress test link diagram is generated; The load testing interface of each service node and the load testing priority of the load testing interface are determined based on the load testing link diagram. According to the load testing priority and the actual online request frequency, the simulated traffic dataset is allocated to each of the load testing interfaces to obtain the initial load testing model.

5. The method according to claim 1, characterized in that, The step of determining the target stress test value for each stress test interface based on the initial stress test model includes: The traffic distribution characteristics of each stress test interface and link are determined based on the initial stress test model; Based on the traffic distribution characteristics and business requirements, load test target values ​​and load test scenarios are generated for each load test interface. The load test target values ​​include at least one of throughput, response time, and error rate.

6. The method according to claim 1, characterized in that, The step of adjusting the parameters of the initial stress test model based on the comparison results until the actual performance data meets the preset conditions includes: Analyze the deviation between the actual performance data and the target pressure test value to obtain the deviation analysis results, and determine the cause of the deviation based on the deviation analysis results; Adjust the interface load distribution ratio, scenario traffic fluctuation settings, or strong / weak dependency interface priority weights in the initial stress test model according to the reasons for the deviation. Determine whether the deviation between the actual performance data and the target stress test value is less than or equal to a preset deviation threshold. If not, return to the step of performing stress test based on the adjusted initial stress test model and the target stress test value. If yes, obtain the adjusted initial stress test model as the target stress test model.

7. The method according to claim 4, characterized in that, The target values ​​for the load testing interfaces are set hierarchically according to the load testing priorities of the interfaces. Specifically, the target values ​​for core link interfaces are higher than those for non-core link interfaces, and the target values ​​for strongly dependent interfaces are higher than those for weakly dependent interfaces.

8. A pressure testing model extrapolation device based on flow analysis, characterized in that, The device includes: The simulated traffic data acquisition module is used to acquire a simulated traffic dataset that is consistent with the characteristics of real online traffic. The strong and weak dependency determination module is used to determine the strong and weak dependencies between services based on the system's end-to-end service call information. The initial stress test model construction module is used to construct an initial stress test model based on the simulated traffic dataset and the strong and weak dependencies. The initial stress test model defines the basic stress test load of each stress test interface in the link. The load testing target determination module is used to determine the load testing target value of each load testing interface based on the initial load testing model; The model dynamic calibration module is used to perform stress testing based on the initial stress testing model and the target stress testing value. During the stress testing process, actual performance data is collected, the actual performance data is compared with the target stress testing value, and the parameters of the initial stress testing model are adjusted according to the comparison result until the actual performance data meets the preset conditions to obtain the target stress testing model.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 7.

Images