Adaptive traffic playback acceleration method and system based on multi-factor perception

Abstract

The application discloses a kind of based on multi-factor perception's self-adapting flow playback acceleration method and system, belong to software testing technical field.The method includes: monitoring playback progress deviation and calculating theoretical acceleration window to generate planned sending interval;Based on transaction business attribute, use preset safety interval to carry out protective adjustment, generate first adjustment interval;Based on response time change rate, generate trend quantization factor, and according to the performance interval where current average response time is located, adjust first adjustment interval, generate second adjustment interval;Based on the comparison result of in-transit transaction quantity and high water level threshold, carry out flow control arbitration, determine final sending interval.The application constructs benchmark calculation, business protection, trend feedback and flow control arbitration Multi-level series decision chain, time catch-up demand, business correctness requirement and system stability guarantee are included in unified control framework, playback acceleration efficiency is maximized under the premise of ensuring system stability and business correctness.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, specifically to traffic replay testing technology, and particularly to an adaptive traffic replay acceleration method and system based on multi-factor perception. Background Technology

[0002] Traffic replay technology is widely used in software systems, especially in high-fidelity verification for upgrades, migrations, or stress tests of core financial business systems. To complete the replay of a large number of historical transactions within a limited time or to catch up with real-time production schedules, it is typically necessary to accelerate the replay process.

[0003] In the prior art, for example, Chinese patent application CN117640518A discloses a method for controlling business access. This method obtains key information by matching the characteristic information of access requests with a set of filtering rules, and then determines the target flow control strategy by combining this with the load information of the business server, thereby achieving differentiated flow limiting for different business scenarios. This method, to a certain extent, achieves dynamic flow control based on load feedback.

[0004] However, solutions including the aforementioned existing technologies still have the following limitations when applied to the specific scenario of traffic playback acceleration: First, there is a lack of proactive awareness of system performance change trends. Existing solutions are mostly open-loop control, or rely solely on simple threshold feedback based on absolute values ​​such as current response time and CPU utilization, failing to perceive the direction and rate of change in system performance. When the absolute value of the response time has already increased significantly, the system has often entered an overload state, at which point reducing the playback rate is too late and can easily lead to drastic fluctuations in response time.

[0005] Secondly, there is a lack of awareness of the business logic of transactions. Existing solutions employ the same flow control strategy regardless of whether the transaction type is a core accounting transaction or a regular query transaction, failing to consider business attributes as a decision factor in flow modulation. This can lead to a dense concentration of critical accounting transactions within a very short period, violating business logic constraints, generating false business anomalies, and severely interfering with the accuracy of test results.

[0006] Third, there is a lack of a unified arbitration mechanism for multi-factor collaborative decision-making. The existing solution does not incorporate the three mutually constraining objectives of "time catch-up requirements," "system stability assurance," and "business correctness requirements" into a unified control framework for collaborative decision-making, making it difficult to achieve a balance between efficiency and stability in complex testing scenarios.

[0007] Therefore, how to provide an adaptive traffic replay acceleration solution that can proactively perceive the trend of system performance changes, has business logic perception capabilities, and can make multi-factor collaborative decisions has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention provides an adaptive traffic playback acceleration method and system based on multi-factor perception.

[0009] This invention provides an adaptive traffic playback acceleration method based on multi-factor perception, comprising the following steps: Step S1, Acceleration Trigger and Baseline Interval Calculation: Monitor the deviation between the playback progress time and the real-time time. When the deviation exceeds the preset trigger threshold, trigger the adaptive dynamic acceleration mode; obtain the original time interval between the transaction to be sent and the previous transaction in the original traffic sequence, determine the theoretical acceleration window according to the preset maximum acceleration ratio and minimum acceleration ratio, and generate the planned sending interval within the theoretical acceleration window. Step S2, Protective adjustment based on transaction business attributes: Obtain the business attribute identifier of the transaction to be sent, and determine whether the current transaction belongs to a critical business transaction based on the business attribute identifier; if it belongs to a critical business transaction, obtain the preset safety interval corresponding to the business attribute identifier, use the safety interval to impose a lower limit constraint on the planned sending interval, and then use the upper limit of the theoretical acceleration window to impose an upper limit constraint to generate a first adjustment interval; if it does not belong to a critical business transaction, use the planned sending interval as the first adjustment interval. Step S3, Feedback Adjustment Based on System Performance Change Trend: Periodically collect response time samples of the tested system processing transaction requests, and calculate the average response time within the current statistical period; generate a trend quantification factor characterizing the system performance change trend based on the relative change between the current average response time and the average response time of the previous statistical period; obtain preset low load thresholds and high load thresholds, and determine the current performance range based on the comparison results between the current average response time and the low load thresholds and high load thresholds; adjust the first adjustment interval using the trend quantification factor according to the adjustment strategy corresponding to the performance range to generate a second adjustment interval; wherein, different performance ranges correspond to different adjustment strategies; Step S4, flow control arbitration based on system instantaneous load: real-time monitoring of the number of transactions in transit that have been sent but have not yet received a response in the tested system; obtaining a preset high watermark threshold, and determining whether the current number of transactions in transit is greater than or equal to the high watermark threshold; if so, pausing the sending of the current transaction, and continuously monitoring the number of transactions in transit until it drops below the high watermark threshold; if not, using the second adjustment interval as the final sending interval, executing the sending operation of the current transaction, and updating the number of transactions in transit after sending.

[0010] This invention provides an adaptive traffic playback acceleration system based on multi-factor perception, comprising: The message middleware module is used to store transaction data to be replayed and to provide the collaborative decision-making engine with a data source containing transaction messages, original time information and business attribute identifiers; A state awareness module, connected to both the collaborative decision engine module and the traffic scheduling executor module, is used to collect and maintain system state information in real time; the state awareness module includes: The performance statistics unit is used to periodically collect response time samples of the system under test in processing transaction requests and calculate the average response time within the current statistical period. The load monitoring unit is used to monitor in real time the number of transactions that have been sent but have not yet received a response in the system under test; A collaborative decision-making engine module, connected to both the message middleware module and the state awareness module, is used to perform multi-level sequential decisions based on system state information collected by the state awareness module and transaction data provided by the message middleware module, and to generate a sending interval instruction; the collaborative decision-making engine module includes: The baseline calculation unit calculates the deviation between the original transaction request time and the actual time, and is used to respond to the acceleration trigger signal, calculate the theoretical acceleration window based on the original time interval and the preset acceleration multiplier range, and generate the planned sending interval. The business protection unit, connected to the benchmark calculation unit and the message middleware module, is used to determine whether a transaction belongs to a critical business transaction based on the business attribute identifier of the transaction to be sent, and to constrain the planned sending interval using a preset security interval to generate a first adjustment interval. A trend feedback unit, connected to the performance statistics unit and the service protection unit, is used to generate a trend quantification factor based on the rate of change of the average response time, and to adjust the first adjustment interval according to the performance range in which the current average response time is located, thereby generating a second adjustment interval. The flow control arbitration unit, connected to the load monitoring unit and the trend feedback unit, is used to determine the final sending interval or generate a pause sending command based on the comparison result between the number of transactions in transit and the preset high water level threshold. The traffic scheduling executor module, connected to the collaborative decision engine module, is used to precisely schedule and execute the sending operation of transactions according to the sending interval instruction output by the collaborative decision engine module, and to provide feedback to the load monitoring unit to update the number of transactions in transit after the transaction is completed, and to provide response time data to the performance statistics unit.

[0011] Compared with existing technologies, this invention constructs a multi-level serial collaborative decision-making chain of "benchmark calculation → business protection → trend feedback → flow control arbitration," integrating time-catching requirements, business correctness requirements, and system stability assurance into a unified control framework for collaborative decision-making, achieving the following beneficial effects: First, it enables forward-looking prediction and preventative control of system performance trends, overcoming the lag defect of existing technologies based on absolute value feedback. Existing technologies and common knowledge in the field all employ flow control based on a comparison between the current absolute load value and a preset threshold. The essence of such solutions is "post-event response": when the absolute value of the response time has increased significantly, the system has often already entered an overload state. At this point, reducing the playback rate cannot prevent the overload from occurring; instead, it is likely to cause drastic fluctuations in the response time.

[0012] The difference between this invention and the prior art lies in that step S3 does not merely sense the absolute value of the current response time, but rather calculates the rate of change of the current period's average response time relative to the previous period's average response time, and generates a trend quantification factor using a nonlinear mapping method, thereby sensing the direction and rate of change in system performance. Based on this, this invention can proactively and smoothly extend the transmission interval when the absolute value of the current response time is still within an acceptable range, but the rate of change indicates that the system is accelerating, achieving "preventive deceleration." This control mechanism based on the rate of change rather than the absolute value gives this invention the ability to predict system overload risks and intervene in advance, while prior art can only respond with a lag after an overload occurs.

[0013] Second, it achieves deep integration of business logic semantics and system traffic control, overcoming the deficiency of existing technologies in lacking business awareness. While existing technologies can differentiate rate limiting for different business scenarios based on business category identifiers, their core rate limiting strategies still focus on threshold control of the number of requests, failing to consider the time interval constraints between transactions as an independent control dimension. In traffic replay acceleration scenarios, simple quantity rate limiting cannot solve the problem of critical transactions arriving in large numbers due to time interval compression. Business anomalies such as database lock conflicts and dirty data caused by this problem cannot be avoided by quantity rate limiting.

[0014] The difference between this invention and the prior art lies in the following: Step S2 identifies key business transactions through offline analysis and configures safety intervals for them. During real-time playback, an independent lower limit constraint is applied to the sending interval of key business transactions to prevent excessive compression due to overall acceleration. Furthermore, a collaborative mechanism of "safety baseline and trend flexibility" is formed between Step S2 and Step S3: the safety interval set in Step S2 serves as an insurmountable lower limit, and Step S3 makes flexible adjustments based on performance trends above this safety baseline. When the system load is low and the trend is positive, Step S3 can appropriately shorten the interval based on the safety baseline to improve efficiency; when the system load increases, Step S3 further lengthens the interval based on the safety baseline to ensure stability. This collaborative architecture of "static safety baseline + dynamic trend adjustment" achieves a win-win improvement in both business correctness assurance and accelerated efficiency enhancement, which is not available in existing technologies.

[0015] Third, a defense-in-depth system of "soft adjustment + hard flow limiting" has been constructed to overcome the shortcomings of a single flow control mechanism in dealing with sudden extreme scenarios. Existing flow control schemes typically employ a single control mechanism: either relying solely on smooth rate adjustment based on statistical windows, which results in a delayed response to sudden traffic spikes and is prone to causing instantaneous overload; or employing only binary flow limiting based on instantaneous thresholds, where flow is rejected if the threshold is exceeded, which is prone to frequent oscillations of "send-pause-send" near the threshold, causing sawtooth fluctuations in system throughput.

[0016] The difference between this invention and the aforementioned prior art lies in the following: Step S3 is responsible for proactively and smoothly adjusting the speed based on performance change trends, keeping the number of transactions in transit below a preset high-water threshold as much as possible; Step S4, as the last line of defense, initiates a hard pause when the number of transactions in transit instantaneously exceeds the high-water threshold. Steps S3 and S4 form a complementary "soft and hard" synergy: on the one hand, since Step S3 has already reduced the sending rate in advance, the probability of the number of transactions in transit exceeding the high-water threshold is significantly reduced, thus avoiding frequent triggering of Step S4; on the other hand, the existence of Step S4 allows the adjustment parameters of Step S3 to be set less aggressively, because even if Step S3's prediction is wrong, Step S4 can still provide fallback protection. This two-layer architecture of "soft adjustment as the main approach and hard flow limiting as a supplement" enables the entire control system to possess both foresight and smoothness, as well as absolute safety against extreme and sudden scenarios, achieving the dual goals of "stability" and "safety" that a single control mechanism cannot simultaneously achieve.

[0017] Fourth, through the integrated design of a multi-level serial decision chain, the inherent unity of the three mutually constraining objectives was achieved. The fundamental breakthrough of this invention lies in integrating the three mutually constraining and difficult-to-coordinate objectives of "time-catching requirements," "system stability assurance," and "business correctness requirements" into a unified control framework through a multi-level, sequential decision-making chain. Step S1 sets a theoretical acceleration window, providing "target guidance"; Step S2 embeds business safety intervals, establishing a "safety baseline"; Step S3 performs flexible adjustments based on performance trends, achieving "dynamic fine-tuning"; Step S4 sets high-water level flow limits for in-transit transactions, providing a "hard safety net." The four-level decision-making is executed in the priority order of "scope definition → baseline constraint → flexible adjustment → bottom-line protection," with the output of each level serving as the input of the next level, forming a progressive, layered defense.

[0018] The four steps described above are not a simple linear superposition of functions, but rather an emergent overall effect of "1+1+1+1>4" generated through synergistic coupling between different levels: the synergy between steps S1 and S3 achieves a balance between "goal-driven and dynamic matching"; the synergy between steps S2 and S3 achieves a win-win situation between "business security and accelerated efficiency"; and the synergy between steps S3 and S4 achieves complementarity between "smooth adjustment and hard security". This multi-factor, multi-level integrated collaborative decision-making architecture systematically solves the inherent contradiction of existing technologies in balancing efficiency, stability, and correctness in complex testing scenarios, constituting the substantial feature that distinguishes this invention from existing technologies.

[0019] In summary, this invention introduces a trend-aware mechanism based on response time change rate, a safety interval protection mechanism based on business attributes, and a hard flow control arbitration mechanism based on the number of transactions in transit. By integrating these mechanisms into a multi-level, interconnected collaborative decision-making chain, this invention maximizes replay catch-up efficiency while ensuring the stable operation of the tested system and the correctness of key business logic, achieving technical results that are significantly superior to existing technologies. Attached Figure Description

[0020] Figure 1 : Overall flowchart of the adaptive traffic replay acceleration method in Embodiment 1 of the present invention; Figure 2 : A detailed flowchart of step S2 in Embodiment 1 of the present invention; Figure 3 A detailed flowchart of step S3 in Embodiment 1 of the present invention; Figure 4 : Module architecture diagram of the adaptive traffic playback acceleration system in Embodiment 2 of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the embodiments described in this section are only for explaining the invention and are not intended to limit the scope of protection of the invention.

[0022] Before describing specific embodiments, the relevant terms involved in this invention will first be defined and explained: Traffic replay: refers to the process of resending a sequence of historical transaction requests captured in the production environment to the system under test according to the original time intervals or after acceleration / deceleration, in order to verify the functional correctness and performance of the system under test.

[0023] Critical business transactions refer to transaction types that are prone to business logic anomalies during accelerated playback due to compressed transmission intervals. These anomalies include database lock conflicts, dirty data, and deadlocks. Transaction types typically include accounting transactions and core transactions. Critical business transactions are identified through offline analysis.

[0024] Safety Interval: This refers to the minimum allowable transmission interval for critical business transactions during accelerated playback, measured in milliseconds, and denoted as T_safe in this document. The purpose of setting this parameter is to ensure that each critical transaction has sufficient processing time within the tested system, preventing business anomalies caused by a dense influx of transactions.

[0025] In-transit transactions: This refers to the number of transactions that have been sent to the system under test but for which no response has yet been received, denoted as N_inflight in this document. This parameter reflects the request load that the system under test is currently processing.

[0026] Response time change rate: This refers to the relative change in the average response time of the current statistical period compared to the average response time of the previous statistical period, denoted as R_raw in this paper. The calculation formula is: the average response time of the current period minus the average response time of the previous period, then divided by the average response time of the previous period. A positive value indicates an increase in response time, i.e., increased load, while a negative value indicates a decrease in response time, i.e., reduced load.

[0027] Trend quantification factor: This refers to the adjustment coefficient generated by an exponential function based on the rate of change of response time, denoted as M in this paper. It is used to non-linearly quantify the performance change trend of the tested system. M greater than 1 indicates that the system performance is showing an aggravating trend, M less than 1 indicates that the system performance is showing a recovery trend, and M equal to 1 indicates that the system performance is stable.

[0028] Theoretical acceleration window: This refers to the interval formed by the minimum and maximum allowable intervals, based on preset maximum and minimum acceleration rates. The planned transmission interval is dynamically adjusted within this interval to ensure that the acceleration rate does not exceed the preset range.

[0029] High watermark threshold: This refers to the upper limit on the number of transactions in transit, denoted as H_high in this article. When the number of transactions in transit reaches or exceeds this threshold, flow control arbitration is triggered, suspending the sending of new transactions to prevent the system under test from being overloaded. This threshold is determined through stress testing and is typically set to 90% of the critical concurrency of the system under test.

[0030] Example 1: An Example of an Adaptive Traffic Replay Acceleration Method like Figure 1 As shown, this embodiment combines a specific production parallel testing scenario of a financial core system to provide a detailed explanation of the adaptive traffic replay acceleration method based on multi-factor perception provided by the present invention.

[0031] In this scenario, testers need to first restore the test environment based on a database backup, and then use transaction replay to bring the test system's data progress back to the production system's data progress. Specifically, the current time is 9:00 AM, and the testers choose to restore the database backup from 8:00 AM, converting and loading the backup data into the test database. This process takes 4 hours. When data recovery and verification are complete, the current time is 1:00 PM, but the data status in the test database still corresponds to 8:00 AM. At this point, the test system's data progress is 5 hours behind the production system's current time.

[0032] The objective of this embodiment is to complete the replay of the 5 hours of historical transaction traffic within 2 hours, so that the data progress of the test system catches up with the data progress of the production system as soon as possible, with a difference of no more than 5 minutes, while ensuring the stable operation of the test system and suppressing non-business interference anomalies introduced by the accelerated replay as much as possible.

[0033] Step S1: Accelerate trigger and base interval calculation After the playback process starts, the system calculates the playback progress deviation: the difference between the time corresponding to the test data state and the current real-time time is 5 hours, exceeding the preset trigger tolerance threshold. According to the configuration of this invention, the default value of the trigger tolerance threshold is 5 minutes, and the recommended value range is 5 to 15 minutes. At this time, the system triggers the adaptive dynamic acceleration mode.

[0034] For each transaction to be sent, the system obtains the original time interval between it and the previous transaction in the original traffic sequence. For example, if the current transaction to be sent is a transfer transaction, the original time interval T_base between it and the previous transaction in the production environment is 200 milliseconds.

[0035] The system reads the preset acceleration multiplier parameters: maximum acceleration multiplier R_max and minimum acceleration multiplier R_min.

[0036] The method for determining R_max is as follows: Replay a fixed period of transactions at 1x speed and calculate the difference rate between the replay response and the actual production response; this is used as the baseline difference rate. Increase the replay multiplier in stages and record the difference rate at each multiplier. When the increase in the difference rate at a certain multiplier compared to the baseline difference rate first reaches 200%, that multiplier is determined as R_max. For example, in a stress test of a system under test: at 1x speed, the baseline difference rate is 0.5%; at 2x speed, the difference rate is 0.8%, an increase of 60%; at 3x speed, the difference rate is 1.2%, an increase of 140%; at 4x speed, the difference rate is 1.8%, an increase of 260%. Since the increase first reaches 200% at 4x speed, R_max is determined to be 4. It should be noted that the 200% threshold is set comprehensively based on the daily trading volume, the proportion of accelerated periods, and the baseline difference rate level, with the aim of controlling the additional differences introduced by acceleration within an acceptable range.

[0037] The method for determining R_min is as follows: Reducing the replay factor has little impact on the accuracy of the transaction results, therefore R_min can be directly set to a conservative value lower than 1. In the system of this invention, R_min is set to 0.8, which allows replay at 80% of the original speed, and is used to actively reduce the speed when the system load is too high.

[0038] It should be noted that the parameters R_max, R_min, etc., determined by the above method are all static configuration values, reflecting the performance boundaries of the system under test under typical loads. The core adaptive capability of this invention is reflected in the dynamic interval adjustment based on the rate of change of real-time response time in the subsequent step S3, rather than online self-tuning of parameters. When the environment of the system under test changes, the system supports offline updating of the parameter configuration file by re-executing the pre-test process, without modifying the core control logic. This "static calibration + dynamic speed adjustment" design achieves forward-looking adaptive flow control while ensuring system stability.

[0039] Based on the above parameters, the system calculates the theoretical acceleration window as follows: minimum allowable interval T_min = T_base / R_max; maximum allowable interval T_max = T_base / R_min.

[0040] The system initially sets the planned transmission interval T_planned to T_min, meaning it is currently at maximum speedup. Continuing with the example above, with T_base = 200 milliseconds, R_max = 4, and R_min = 0.8, then T_min = 200 / 4 = 50 milliseconds, T_max = 200 / 0.8 = 250 milliseconds, and the initial planned transmission interval is 50 milliseconds.

[0041] Step S2: Protective Adjustments Based on Transaction Business Attributes like Figure 2As shown, this step consists of two time-separated sub-stages: offline analysis to generate a security configuration and real-time protective adjustments. First, a "critical business transaction delay configuration file" is generated through offline analysis; during the playback process, this configuration file is loaded, and lightweight table lookups and interval constraints are performed on each real-time transaction. This "static-dynamic separation" design ensures extremely low latency in the real-time decision-making chain while leveraging sophisticated offline analysis capabilities.

[0042] (a) Offline analysis and configuration file generation: The offline analysis process is as follows: First, prepare the test dataset: select a representative historical production traffic segment, including various transaction types and their original time intervals.

[0043] Second, replay comparison: replay the same traffic segment at the original speed and R_max speed respectively, and record the difference rate between each transaction code and the original production response.

[0044] Third, calculate the difference sensitivity index (S-index). The formula for the S-index is: S = [(D_high - D_1x) / D_1x] / (R_high - 1). Where D_1x is the difference rate at 1x speed, D_high is the difference rate at high speed, and R_high is the corresponding high speed value. The design principle of this index is that if the increase in the difference rate mainly comes from interval compression caused by acceleration rather than a bug in the system itself, then as the multiplier increases, the difference rate will increase significantly and monotonically. If the difference rate is high at 1x speed, but does not increase significantly relative to the difference rate after acceleration, then the S value is small or negative. This index naturally excludes the interference of bugs in the system itself; only those trades with a significant increase in the difference rate relative to the benchmark are considered to have "interval dependence."

[0045] Fourth, the judgment threshold: Set an empirical threshold S_th. If S > S_th, the transaction code is judged to be a critical business transaction, which means that a security interval T_safe needs to be set for protection. The empirical threshold S_th can be set to 0.3, and can be optimized according to actual differences.

[0046] Fifth, special handling: For accounting transactions, based on the known accounting transaction list, if D_high > D_1x, that is, the difference rate increases after acceleration, then it is directly marked as a key business transaction.

[0047] Sixth, iterative update mechanism: The above offline analysis process can be automatically executed after each important version replay test, and the generated key transaction configuration files are automatically used for subsequent traffic replay acceleration tasks without manual intervention.

[0048] The basis and method for setting and determining the safety interval T_safe: T_safe represents the minimum allowed transmission interval for critical business transactions during accelerated playback. Its purpose is to ensure that each critical transaction has sufficient processing time within the tested system, preventing business anomalies such as database lock conflicts and dirty data caused by a dense influx of transactions. The determination method is as follows: (1) Benchmark Time Measurement: The end-to-end time delay is measured from the moment the system under test receives a transaction request until the core business logic processing and database operation are completed. This measurement is performed in an independent test environment at 1x speed: the start timestamp is recorded when the system receives the request, and the end timestamp is recorded when the system performs the database entry operation. The difference between the two timestamps is the pre-processing time of the transaction. The P95 quantile of the pre-processing time of all successful transactions in this batch is taken as the benchmark time.

[0049] (2) Safety margin superposition: On the basis of the above benchmark time, a protection margin of several milliseconds is superimposed to cope with minor fluctuations such as operating system scheduling and network jitter, and to ensure that transactions will not generate lock timeout or dirty data due to time competition under normal load.

[0050] (3) Final formula: T_safe = baseline time + safety margin.

[0051] (ii) Real-time protective adjustment logic When the replay process starts, the critical business transaction delay configuration file is preloaded, generating a mapping table between transaction codes and security intervals. During real-time execution, the system obtains the business attribute identifier of the transaction to be replayed and matches it against the mapping table using the transaction code.

[0052] If the current transaction is a normal transaction, no protective adjustment will be performed, and the first adjustment interval T_current is equal to the planned sending interval T_planned.

[0053] If the current transaction is a critical business transaction, adjustments will be made according to the following rules: First, calculate the service safety interval: T_safe_current=max(T_planned,T_safe), which is to take the larger value between the planned sending interval and the safety interval to implement the lower limit constraint on the planned sending interval.

[0054] Then, apply the acceleration rate upper limit constraint: T_current=min(T_safe_current,T_max) to ensure that the adjusted interval does not exceed the upper limit of the theoretical acceleration window.

[0055] Continuing with the example above, assume the safety interval T_safe for this transfer transaction is 80 milliseconds. Then, T_safe_current = max(50, 80) = 80 milliseconds, and T_current = min(80, 250) = 80 milliseconds. Therefore, the sending interval for this transfer transaction is adjusted from the planned 50 milliseconds to 80 milliseconds, ensuring that it maintains a reasonable time interval during the acceleration process and avoiding business anomalies caused by excessively dense arrivals.

[0056] Step S3: Feedback-based adjustment based on system performance change trends like Figure 3 As shown, for the current transmission interval T_current after adjustment in step S2, the system introduces the performance change trend of the tested system as a feedback variable for secondary dynamic adjustment. The core of this step is to not only perceive the current load status of the system, but also its direction and rate of change, thereby achieving forward-looking and smooth flow control.

[0057] (a) Response time period sampling mechanism The system employs a dynamic sample collection mechanism based on time windows to periodically calculate the average response time of the tested system and compare it with the average response time of the previous period to calculate the rate of change of response time.

[0058] The specific implementation is as follows: Configuration parameters: T_feedback represents the desired feedback period in milliseconds, with a default value of 500 milliseconds. This value determines the timeliness of the speed controller's sensing of system performance changes, and is generally set to 5 to 10 times the typical response time of the tested system. N_min represents the minimum number of response samples required per period, with a default value of 50, used to ensure the representativeness of statistical data. A recommended value is max(50, expected QPS × T_feedback × 0.05).

[0059] The system maintains a time window, recording the response times of all transactions received within that window. A periodic update is triggered when both of the following conditions are met: the time since the last update has exceeded T_feedback milliseconds; and the number of response samples collected within the window is greater than or equal to N_min.

[0060] Once the conditions are met, calculate the average of all response times within the window, and record it as the average response time RT_curr for the current cycle. Simultaneously, record the value from the previous cycle as RT_prev. Then, clear the window, reset the timer, and begin the next cycle. On the first run, RT_prev equals RT_curr.

[0061] Timeout protection: If the time since the last update exceeds the timeout multiplier times T_feedback milliseconds and the number of samples is still less than N_min, then force the use of the existing samples within the window to calculate RT_curr to avoid feedback interruption. Among them, the timeout multiplier N_timeout_multiplier is recommended to be between 1.5 and 3.0, and the default value is 2.0. If the number of samples is 0, then by default RT_prev is equal to RT_curr.

[0062] (2) Original change rate of response time The system calculates the original change rate R_raw of the response time: R_raw = (RT_curr - RT_prev) / RT_prev.

[0063] Among them, R_raw > 0 indicates that the response time increases, that is, the load increases, and R_raw < 0 indicates that the response time decreases, that is, the load decreases.

[0064] (3) Calculation of trend quantization factor M The system generates the trend quantization factor M through an exponential function: M = exp(α × R_raw).

[0065] Among them, α is a trend sensitivity coefficient greater than 0 and can be configured.

[0066] When the response time increases, R_raw > 0, M > 1, and the faster the increase, the larger the M value; when the response time decreases, R_raw < 0, 0 < M < 1, and the faster the decrease, the closer the M value is to 0; when the response time is stable, R_raw = 0, M = 1.

[0067] Configuration method of trend sensitivity coefficient α: α determines the sensitivity of the speed regulation to the change of the response time. The larger α is, the more intense the speed regulation reaction. The following process is used for debugging in this system: (1) Determine the benchmark concurrency C: Through stress testing, record the concurrency at the stop as C_start, and take C = 0.6 × C_start. The method of stress testing is: according to the peak business ratio of typical transactions, increase the concurrency gradientally until the number of transactions per second no longer increases and the transaction response time increases significantly, then stop the test.

[0068] (2) Execute load step: In the test environment, increase the concurrency from C to 2C, and record the response time change rate R_raw = (RT_2c - RT_c) / RT_c. It is required that R_raw > 0.2, otherwise it is necessary to increase C and retest.

[0069] (3) Observe the stability of speed regulation: Run the playback acceleration test with the initial α = 1.0 and observe the system response time curve. If overshoot oscillation occurs, decrease α; if the response is too slow, increase α.

[0070] (4) Determine the final α: Repeat step (3) until the system can respond quickly and without violent oscillations under load step.

[0071] This invention introduces an exponential trend quantification factor M based on the rate of change of response time, which is used to proactively and non-linearly adjust the traffic playback rate.

[0072] (iv) Tiered trend regulation The system applies different adjustment strategies based on the performance range in which the current average response time RT_curr falls. The performance range is divided based on two preset thresholds: a high-load threshold Th_high and a low-load threshold Th_low.

[0073] Methods for determining Th_high and Th_low: Method for determining the high load threshold: Using load testing tools, gradually increase concurrency based on the peak business ratio of typical transactions until the number of transactions per second no longer increases and the transaction response time increases significantly. Stop the test at this point and record the response time. Take 80% of this value as Th_high. This threshold indicates that the current system is under great pressure and concurrency needs to be reduced quickly.

[0074] Method for determining the low load threshold: Use a load testing tool to gradually increase the concurrency based on the peak business ratio of typical transactions until the number of transactions per second no longer increases and the transaction response time increases significantly. Stop the test and record the median value between the initial response time and the inflection point response time as the low load threshold.

[0075] Adjustment rules: (1) High load range, i.e., RT_curr > Th_high: The adjustment formula is: T_adjusted_temp=T_current×max(M,1)×K1.

[0076] Here, K1 is a high-load penalty coefficient greater than 1, typically ranging from 1.5 to 2.0. Within this range, system stability has the highest priority. The strategy of forcing a value of max(M,1) means that even if the performance trend factor M indicates that the system is recovering, the controller will not immediately reduce the interval, thus avoiding a second load spike and oscillation caused by prematurely releasing the suppression during the system's vulnerable period. The acceleration capability of M<1 is restored only after the average response time drops below Th_high and enters the sensitive load range.

[0077] (2) Sensitive load range, i.e., Th_low <RT_curr≤Th_high: The adjustment formula is: T_adjusted_temp = T_current × M.

[0078] This strategy makes the transmission interval directly proportional to the trend factor M, enabling fine-tuning based on the trend. The interval is lengthened in advance when the response time shows an upward trend, and appropriately shortened when it shows a downward trend.

[0079] (3) Low load range, i.e., RT_curr ≤ Th_low: The adjustment formula is: T_adjusted_temp = T_current.

[0080] This interval indicates that the system load is light and resources are plentiful. To prioritize catching up efficiency, no trend adjustment is introduced during this phase, and the interval remains unchanged.

[0081] (v) Acceleration rate boundary constraints To ensure that the adjusted interval is within a reasonable acceleration range, boundary clipping is performed: T_adjusted=min(max(T_adjusted_temp,T_min),T_max).

[0082] Among them, max(T_adjusted_temp,T_min) ensures that the interval is not lower than the minimum interval, and min(...,T_max) ensures that the interval does not exceed the maximum interval.

[0083] Scenario simulation: Assuming the current system is in catch-up mode, step S1 calculates T_min = 50 milliseconds and T_max = 250 milliseconds. Step S2 adjusts the sending interval of a transfer transaction to 80 milliseconds before proceeding to step S3.

[0084] At this point, the system's average response time RT_curr increases from 50 milliseconds in the previous cycle to 60 milliseconds, falling within the sensitive load range. Assuming Th_low = 40 milliseconds and Th_high = 120 milliseconds, we calculate R_raw = (60-50) / 50 = 0.2. Let α = 1.5, then M = exp(1.5 × 0.2) = exp(0.3) ≈ 1.35. T_adjusted_temp = 80 × 1.35 = 108 milliseconds. After boundary clipping, T_adjusted = 108 milliseconds.

[0085] Therefore, after sensing the upward trend in response time, the system proactively increased the transmission interval from 80 milliseconds to 108 milliseconds, achieving preventative deceleration.

[0086] Step S4: Flow control arbitration based on system instantaneous load As a final safeguard, the system monitors the number of transactions in transit, N_inflight, in real time, which is the number of transactions that have been sent but have not yet received a response.

[0087] Method for determining the high water level H_high: Using a load testing tool, gradually increase the concurrency based on the peak business ratio of typical transactions until the number of transactions per second no longer increases and the transaction response time increases significantly. Stop the test at this point, record the concurrency at this time, and set H_high to 90% of that value.

[0088] Arbitration Rules: After calculating the final sending interval by executing steps S1 to S3, the system checks the current number of transactions in transit, N_inflight.

[0089] If N_inflight is greater than or equal to H_high, the transmission of new transactions is paused, and the system enters a waiting state. The system continuously monitors N_inflight, polling it every 10 milliseconds, until it drops below H_high, at which point the current transaction is sent using the calculated interval.

[0090] If N_inflight is less than H_high, the calculated interval will be used as the final sending interval, and the transaction sending operation will be performed.

[0091] When a transaction is sent, the number of transactions in transit is incremented by 1; after receiving a system response via an asynchronous callback or after a timeout, the number of transactions in transit is decremented by 1, ensuring that the flow control mechanism does not fail due to pending requests. This step provides a rigid flow control valve to prevent excessive instantaneous pressure and is the last line of defense for system stability.

[0092] Scenario simulation: Continuing with the above scenario, suppose that after the interval is adjusted to 108 milliseconds in step S3, a momentary network jitter causes multiple requests to accumulate, and the number of transactions in transit instantly reaches 150, while H_high is set to 120. At this time, N_inflight is greater than or equal to H_high, and step S4 is triggered immediately. The system suspends sending new transactions and continuously polls for the number of transactions in transit.

[0093] Since step S3 had already extended the sending interval, the internal load pressure of the system was alleviated, and the number of transactions in transit was quickly digested and reduced to below 120. Step S4 released the pause. At this time, step S3 had maintained the trend factor M at a high level, and the first transaction released again was still sent at a softened safe speed, avoiding the problem of frequent fluctuations around the threshold in traditional hard rate limiting.

[0094] Examples of synergistic effects in multi-level decision chains: The following dynamic scenario simulation illustrates how the above four steps work together, rather than being a simple sum of the expected functions of each module.

[0095] Phase 1: Static Pre-implementation and Dynamic Activation of Business Security Bottom Lines When the playback system suddenly pushes a batch of high-density data containing a large number of accounting transactions, step S2 does not simply slow down all transactions, but identifies critical business transactions that are prone to anomalies due to interval compression. By reading the safety interval T_safe, step S2 forcibly physically lengthens the transmission interval of this type of transaction based on the baseline of step S1.

[0096] Synergistic Effect: Step S2 lays a "safety anchor" for the subsequent elastic adjustments in Step S3. Without this anchor, Step S3 would infinitely accelerate these accounting transactions when the system is under low load, greatly increasing the probability of database deadlock and causing business anomalies. The existence of Step S2 ensures that the subsequent elastic adjustments in Step S3 always operate above the physical limits of business safety.

[0097] Phase Two: "Preventative Deceleration" and "Soft Release" of Nonlinear Trend Factors As these transactions are initiated, the system response time begins to slowly increase from 50 milliseconds to 180 milliseconds. Existing technologies would be unresponsive at this stage because the system remains in its "low latency" comfort zone. However, the exponential trend factor M in step S3 of this invention keenly captures the subtle positive changes in R_raw.

[0098] Nonlinear adjustment: Since M is exp(α×R_raw), M is only slightly greater than 1 in the early stage of growth, and step S3 slightly lengthens the interval, generating "soft resistance"; if the response time increases rapidly, the value of M will increase exponentially, instantly and forcefully lengthening the interval, closely matching the superlinear decay characteristics of the system performance.

[0099] Synergistic effect: This exponential control of "the faster the growth, the stronger the inhibition" cannot be achieved by linear adjustment or absolute threshold. Step S3 plays a key role in smoothing out peaks and valleys at this stage, making the in-transit transaction count curve that is subsequently passed to step S4 very smooth, greatly reducing the probability of step S4 being triggered.

[0100] Phase Three: Zero-Delay Hard Chopping and Rapid Exit for Instantaneous Peaks Despite the efforts made by step S3 to smooth the process, if a minor network interruption occurs at this time, causing multiple requests to pile up in a very short period of time, the number of in-transit transactions N_inflight will instantly reach the high watermark H_high.

[0101] Zero-delay blocking: Step S4 completely ignores the calculations in steps S1 to S3 and directly suspends the sending thread.

[0102] Anti-shock exit mechanism: Due to the continuous slowdown adjustment performed in the background by step S3, the system's internal resistance is enhanced, and N_inflight will quickly absorb and drop below the threshold. When step S4 releases the transaction, step S3 has already maintained the adjustment factor M at a high level. The first transaction released again is no longer at the extremely fast speed of step S1, but at a safe speed softened by step S3.

[0103] Synergistic effect: Traditional hard current limiting often "sends and stops" near the threshold, producing sawtooth waveforms in throughput. In this invention, step S3 acts as a "smart buffer" for step S4, and step S4 acts as a "limit safety valve" for step S3. The coupling of the two completely solves the persistent problem of severe oscillation between on and off in traditional current limiting.

[0104] Example 2: An Example of an Adaptive Flow Playback Acceleration System Corresponding to the above method embodiments, this embodiment further provides an adaptive traffic playback acceleration system based on multi-factor perception.

[0105] System overall architecture: The system provided by this invention adopts a layered and decoupled architecture, including: a data access layer, a state awareness layer, a decision control layer, and an execution layer. The system communicates with the system under test via a network, sending replay transaction requests to the system under test and receiving responses.

[0106] like Figure 2 As shown, the system specifically includes the following modules: message middleware module, state awareness module, collaborative decision engine module, and traffic scheduling executor module. Among them, the collaborative decision engine module is the core decision-making unit of the system, which has built-in multi-level adjustment logic for steps S1 to S4.

[0107] Message middleware module: The message middleware module stores transaction data to be replayed, providing a pre-processed data source for the collaborative decision-making engine. This module can be implemented using a message queue, and the stored transaction data includes the following information: transaction message, original request time, original response time, transaction code, channel number, etc. The message middleware module supports batch reading and sequential consumption, ensuring that transactions are retrieved and processed in their original time order.

[0108] State awareness module: The status awareness module is used to collect and maintain system status information in real time. It does not directly interact with the system under test, but only calculates corresponding indicators through internal data. This module includes the following units: Performance Statistics Unit: This unit periodically collects response time samples of the tested system's transaction request processing and calculates the average response time within the current statistical period. Internally, this unit maintains a dynamic sample collector based on a time window, advancing periodically according to the configured feedback period T_feedback and minimum sample size N_min. This unit also stores the average response time of the previous period and the average response time of the current period for trend calculation.

[0109] Load monitoring unit: Used for real-time monitoring of the number of transactions sent but not yet responded to in the system under test. This unit maintains an atomic counter, which is notified by the traffic scheduler to perform an atomic increment operation when a transaction is sent, and an atomic decrement operation is performed when the transaction is completed. This unit also provides a query interface for the collaborative decision engine to obtain the current number of transactions in transit in real time.

[0110] Collaborative Decision Engine Module: The collaborative decision-making engine module is the core decision-making unit of the system. It connects to both the message middleware module and the state awareness module. It receives transaction data from the message middleware module and system state information collected by the state awareness module, executes multi-level adjustment logic sequentially, and finally outputs a sending interval command. This module includes the following units: The baseline calculation unit calculates the deviation between the original transaction request time and the actual time. In response to the acceleration trigger signal, it calculates the theoretical acceleration window based on the original time interval and a preset acceleration multiplier range, and generates the planned sending interval. This unit internally stores static configuration parameters R_max and R_min, which are loaded from the configuration file during system startup. This unit is also responsible for maintaining the calculation logic for the original time interval of the current transaction and the original time interval of the previous transaction.

[0111] Business Protection Unit: Connected to the baseline calculation unit and message middleware module, this unit determines whether a transaction is a critical business transaction based on its business attribute identifier and constrains the planned transmission interval using a preset security interval, generating a first adjustment interval. This unit loads the critical business transaction delay configuration file at system startup, generating a mapping table from transaction codes to security intervals. During real-time operation, it performs matching queries based on transaction codes.

[0112] Trend Feedback Unit: Connected to the Performance Statistics Unit and Business Protection Unit, this unit generates a trend quantification factor based on the rate of change of the average response time and adjusts the first adjustment interval according to the performance range in which the current average response time falls, generating a second adjustment interval. This unit internally stores static configuration parameters, which are loaded from the configuration file upon system startup. The unit executes interval adjustments according to hierarchical control rules and performs boundary trimming after adjustment.

[0113] Flow control arbitration unit: Connected to the load monitoring unit and trend feedback unit, it determines the final sending interval or generates a pause sending command based on the comparison between the number of transactions in transit and a preset high-water mark threshold. This unit internally stores the static configuration parameter H_high and the flow control arbitration polling interval. When the number of transactions in transit reaches the high-water mark threshold, this unit puts the currently executing thread into a waiting state and periodically checks the number of transactions in transit at the configured polling interval until the condition is met, at which point sending resumes.

[0114] Traffic scheduling executor module: The traffic scheduling executor module connects to the collaborative decision engine module and is used to precisely schedule and execute transaction sending operations according to the sending interval instructions output by the collaborative decision engine. Internally, this module maintains the actual sending timestamp of the previous transaction, calculates the true time of the current sending based on the final sending interval, and achieves precise waiting through a high-precision timer. After a transaction is sent, this module writes the sending timestamp to the transaction object and notifies the load monitoring unit of the status awareness module to update the number of transactions in transit. When a response is received from the system under test or a timeout occurs, this module records the response time through an asynchronous callback mechanism, pushes the response time data to the performance statistics unit for calculating the average response time in the next cycle, and notifies the load monitoring unit to perform an atomic decrement operation on the number of transactions in transit.

[0115] The following describes a complete decision-making cycle of the system using specific data structures.

[0116] Data structure definition: The PlaybackMessage data structure, which stores transaction information in the system, contains the following fields: Global Transaction Number (string type); Transaction Code (string type, used to match the corresponding security interval in the critical business transaction delay configuration file mapping table in the system's static configuration information); Original Transaction Request Sending Time (string type); Request Message (string type); Response Message (string type, used to store the response message received during playback); Playback Sending Time (string type, initially empty); Received Response Time (string type, initially empty); and the original time interval between this message and the previous message (long integer type).

[0117] The system's data structure for storing static configuration information includes the following fields: Acceleration trigger tolerance threshold (an integer in minutes, ranging from 5 to 15 minutes, with a default value of 5 minutes); Critical business transaction delay configuration file mapping table (initialized by reading the critical business transaction delay configuration file when the playback service starts, where the key is the transaction code, corresponding to the transaction code field in PlaybackMessage, and the value is the safety interval); Acceleration multiplier upper limit (a floating-point number); Acceleration multiplier lower limit (a floating-point number); High load threshold (an integer). The following parameters are specified: Low load threshold (in milliseconds); Feedback period (in milliseconds); Minimum number of statistics (in milliseconds); Trend sensitivity coefficient (floating-point); High watermark for in-transit transactions (in integer); High load penalty coefficient (floating-point, typically 1.5 to 2.0); Flow control arbitration polling interval (in milliseconds, recommended value is one-fifth to one-tenth of the average response time of the tested system under normal load); and Feedback period timeout multiple (floating-point).

[0118] The data structure storing the system's status awareness information includes the following fields: the number of transactions currently in transit (an atomic integer); the average response time of the previous period (a floating-point number); the average response time of the current period (a floating-point number); the original request time of the last sent transaction (a string); the actual replay timestamp of the last transaction (a string); and the final sending interval of the current transaction after all four steps of calculation (a long integer).

[0119] The system executes the decision cycle in the following order: The first step is initialization and message retrieval. A transaction data entry is retrieved from the message queue and deserialized into a transaction information data structure. The original time interval is calculated using the original transaction request sending time of the current transaction data and the original start time of the previous message stored in the state awareness information. This interval is written into the corresponding field of the transaction information data structure, and the transaction information data structure is then passed to the next step.

[0120] The second step is to calculate the baseline interval. This involves reading the original time interval from the transaction information data structure, and the upper and lower limits of the acceleration multiplier from the system static configuration information. The minimum allowable interval is calculated by dividing the original time interval by the upper acceleration multiplier; the maximum allowable interval is calculated by dividing the original time interval by the lower acceleration multiplier. The planned transmission interval is initially set to the minimum allowable interval. The minimum allowable interval, maximum allowable interval, and planned transmission interval are then passed as intermediate variables along with the transaction information data structure to the next step.

[0121] The third step involves protective adjustments based on the transaction's business attributes. This involves reading the transaction code from the transaction information data structure, the critical business transaction delay configuration file mapping table from the system's static configuration information, and the planned sending interval and maximum allowed interval passed in the previous step. The current sending interval is set to the planned sending interval. If the current transaction code is present in the critical business transaction delay configuration file mapping table, the current transaction is determined to be a critical business transaction. The interval value constrained by the safety interval is calculated; this value is the larger of the planned sending interval and the safety interval. The current sending interval is then updated to the smaller of this constrained interval value and the maximum allowed interval. The intermediate variable, the current sending interval, is updated and passed to the next step along with the transaction information data structure.

[0122] The fourth step is feedback-based adjustment based on performance change trends. This involves reading the current cycle's average response time and the previous cycle's average response time from the status awareness information, reading the low load threshold, high load threshold, and trend sensitivity coefficient from the system's static configuration information, and reading the current transmission interval, minimum allowed interval, and maximum allowed interval transmitted in the previous step.

[0123] First, calculate the trend quantification factor, which is equal to the value of an exponential function with the natural constant as the base and the trend sensitivity coefficient multiplied by the response time change rate as the exponent. The response time change rate is equal to the difference between the average response time of the current period and the average response time of the previous period divided by the average response time of the previous period.

[0124] Then, the temporary adjustment interval is calculated according to the hierarchical control rules: if the current cycle average response time is greater than the high load threshold, the temporary adjustment interval is equal to the current transmission interval multiplied by the larger of the trend quantization factor and the value 1, and then multiplied by the high load penalty coefficient; otherwise, if the current cycle average response time is greater than the low load threshold, the temporary adjustment interval is equal to the current transmission interval multiplied by the trend quantization factor; otherwise, the temporary adjustment interval is equal to the current transmission interval.

[0125] Finally, boundary constraints are applied, setting the adjusted transmission interval as a limit between the minimum and maximum allowable intervals for the temporary adjustment interval. Specifically, the larger of the temporary adjustment interval and the minimum allowable interval is taken, followed by the smaller of the larger value and the maximum allowable interval. The intermediate variable, the adjusted transmission interval, is then updated and passed to the next step along with the transaction information data structure.

[0126] Step 5: Flow control arbitration based on system instantaneous load. Read the current number of transactions in transit from the state awareness information, the high watermark of transactions in transit from the system static configuration information, and the adjusted sending interval passed in the previous step. Enter a loop for checking: if the current number of transactions in transit is greater than or equal to the high watermark, pause the current execution thread and wait for the time specified by the flow control arbitration polling interval before rereading the current number of transactions in transit. When the number of transactions in transit is less than the high watermark, exit the loop, write the adjusted sending interval into the current transaction final sending interval field in the state awareness information, and perform an atomic increment operation on the current number of transactions in transit. Finally, pass the transaction information data structure and the final sending interval to the flow scheduler executor.

[0127] Step 6: Final Execution and Status Write-back. The traffic scheduler executor reads the actual replay sending timestamp of the previous transaction and the final sending interval of the current transaction from the status awareness information. It calculates the actual sending time, which equals the actual replay sending timestamp of the previous transaction plus the final sending interval of the current transaction. The scheduler waits precisely until this time point before sending the transaction data. The current timestamp is written as the sending time into the replay sending time field of the transaction information data structure, and the actual replay sending timestamp of the previous transaction in the status awareness information is updated.

[0128] Step 7: Asynchronous Callback Processing. An asynchronous callback is triggered when a response is received from the system under test or when a timeout occurs. The current time is written to the "Receive Response Time" field in the transaction information data structure. The response time is calculated; this response time equals the received response time minus the replay sending time. This response time is then pushed into the performance statistics module for calculating the average response time in the next period. Simultaneously, an atomic decrement operation is performed on the number of currently en route transactions in the status awareness information.

[0129] Anomaly Handling: If any of the above steps fails, such as missing response time data, a security degradation strategy will be adopted, setting the adjusted sending interval to the maximum allowed interval, i.e., using the lowest acceleration rate, and an alarm log will be recorded.

[0130] Example 3: Application Case in Upgrade Testing of Core Financial Systems This embodiment uses a comparison test of the old and new core systems of a large commercial bank as a background to illustrate the specific application effect of the present invention.

[0131] Test environment and scenario: The tested system includes a new core system and an old core system. The test employs a parallel replay comparison mode for both systems: first, the databases of both the new and old core systems are restored to the same baseline time, i.e., a full backup state at 3:00 AM on the current day. This time point represents the stable data state after the batch processing at the end of the previous accounting day. The traffic to be replayed consists of all production transaction data from 3:00 AM to 11:00 PM in the production environment, totaling 20 hours of transaction volume, approximately 60 million transactions, including various transaction types such as transfers, payments, inquiries, account openings, account closings, and purchases of financial products. The technical objective of this embodiment is to complete the replay of the aforementioned 20 hours of transaction volume within 6 hours and perform a consistency comparison of the response messages and database states of the new and old systems.

[0132] The traditional fixed-rate acceleration scheme has the following problems: If a fixed acceleration of 3.5x is used, the estimated completion time is approximately 20 hours / 3.5 ≈ 5.71 hours, within a 6-hour window. However, during actual playback, when entering peak business periods, the tested system experienced numerous database deadlocks and lock timeout anomalies due to a significant increase in transaction density. Analysis shows that this is because the fixed high-rate acceleration compresses the time intervals of accounting transactions, leading to dense arrivals and database lock conflicts. If a conservative acceleration of 1.5x is used, the theoretical playback completion time is approximately 20 / 1.5 ≈ 13.33 hours, far exceeding the 6-hour test window and failing to meet the test time limit requirements.

[0133] Implementation process of the present invention: The testers first calibrated the parameters according to the method of this invention: (1) R_max is determined by step-by-step pressurization: the baseline difference rate is 0.5% at 1x speed; the difference rate is 0.8% at 2x speed, with an increase of 60%; the difference rate is 1.2% at 3x speed, with an increase of 140%; and the difference rate is 1.8% at 4x speed, with an increase of 260%. Since the increase first reaches 200% at 4x speed, R_max = 4.

[0134] (2) Identification of key business transactions through offline analysis: The difference sensitivity S value of accounting transactions is greater than 0.3, and the difference rate after acceleration is significantly increased compared with 1x speed, so they are marked as key business transactions. The time consumption measurement determines that the transfer transaction T_safe=120 milliseconds and the payment transaction T_safe=100 milliseconds.

[0135] (3) Determine the performance thresholds through stress testing: Th_high=150 milliseconds, Th_low=50 milliseconds, H_high=120 records, α=1.2.

[0136] Test results: Playback tests conducted using the method of this invention yielded the following results: (1) Playback efficiency: The actual playback completion time was 5 hours and 42 minutes, with an average acceleration ratio of about 3.51 times. Efficiency was maximized while meeting the requirement of completion within 6 hours.

[0137] (2) System stability: During the playback, the tested system did not experience any service interruptions due to overload. The response time remained between 50 and 180 milliseconds throughout the process, without any severe fluctuations. The highest CPU utilization was 78%, which did not exceed the 80% alarm threshold.

[0138] (3) Business accuracy: No deadlocks or dirty data anomalies occurred in accounting transactions due to acceleration. The overall difference rate was controlled within 1.9%, and after manual investigation, it was confirmed that within the confirmed difference range, all differences were attributed to logical defects or known defects in the development process of the new system, and no interference differences attributable to this acceleration method were found.

[0139] (4) Comparative data: Compared with the fixed 3.5x speed scheme, the difference rate of the present invention is reduced by 63%, and the number of deadlocks is reduced to zero; compared with the fixed 1.5x speed scheme, the completion time of the present invention is shortened by 57%.

[0140] Example 4: Security Degradation Mechanism in Abnormal Scenarios This embodiment illustrates the security degradation handling mechanism of the present invention under abnormal scenarios, ensuring the robustness of the system.

[0141] Scenario 1: Performance statistics are missing Suppose that due to a network outage or a brief unavailability of the tested system, the performance statistics unit fails to collect enough response time samples within a complete feedback cycle. According to the timeout protection mechanism of this invention, the system no longer waits, but instead maintains RT_curr equal to RT_prev, i.e., the trend quantization factor M equals 1. At this time, step S3 does not perform trend adjustment, and the sending interval is determined by steps S1 and S2. Simultaneously, the system records an alarm log: "Performance statistics data missing, downgraded to no-trend-adjustment mode." When normal sampling resumes in subsequent cycles, the system automatically restores the trend adjustment function.

[0142] Scenario 2: Failure to load critical business transaction configuration files Suppose that the critical business transaction delay configuration file is corrupted or missing when the replay service starts. After detecting the loading failure, the system initializes `codeSleepMap` to an empty mapping. At this point, in step S2, any matching of business attributes for any transaction returns false, meaning all transactions are treated as ordinary transactions and are not subject to security interval constraints. The system logs an alarm "Critical business configuration file loading failed, downgraded to no business protection mode," while continuing to execute the replay task. Testers can promptly correct the configuration file and dynamically refresh the mapping table based on the alarm log without restarting the replay service.

[0143] Scenario 3: Overflow in step S3 calculation Suppose that the rate of change of response time, R_raw, reaches an extreme value, causing the calculated result of exp(α×R_raw) to exceed the floating-point representation range. Before calculating M, the system performs a limiting operation on R_raw: if R_raw is greater than 5, then R_raw takes the value 5; if R_raw is less than -5, then R_raw takes the value -5. The value of M after the limiting operation always falls between exp(-5α) and exp(5α), ensuring calculation stability. Simultaneously, the system records an alarm log: "The rate of change of response time exceeds the limiting threshold; limiting operation has been performed."

[0144] Scenario 4: Abnormal Hanging of Flow Control Arbitration Suppose that after a transaction is sent, the asynchronous callback is never triggered due to a system crash or network interruption. The number of transactions in transit, N_inflight, cannot be atomically decremented through the normal process, potentially causing all subsequent transactions to be permanently blocked. To address this, this invention implements a timeout protection mechanism: a timestamp is recorded when each transaction is sent. If no response is received within a preset timeout threshold, timeout processing logic is triggered, forcibly treating the transaction as complete, performing an atomic decrement operation on the number of transactions in transit, and recording an alarm log: "Transaction response timed out, flow control count forcibly released."

[0145] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. It should be specifically noted that the scope of protection claimed by the appended claims is defined by the appended claims, and not limited to the specific implementations described in the above embodiments.

[0146] Those skilled in the art should understand that, without departing from the basic principles of the present invention, modifications, equivalent substitutions, or improvements can be made to the technical solutions described in the above embodiments, or the technical features disclosed in the present invention can be combined with other prior art. As long as these modifications, substitutions, improvements, or combinations do not exceed the inventive concept of the present invention, they should all fall within the protection scope of the present invention.

[0147] In particular, the specific values ​​of various parameters disclosed in this invention are only illustrative examples. Those skilled in the art can determine the applicable parameter values ​​based on the performance characteristics and testing requirements of the actual system under test, using the stress test calibration method disclosed in this invention or conventional testing methods. The specific selection of these parameter values ​​should not be construed as a limitation on the scope of protection of this invention.

[0148] Furthermore, the execution order of "steps S1 to S4" described in this invention is based on the priority logic of "baseline calculation → business protection → trend feedback → flow control arbitration". Any variant execution method that substantially follows this priority logic does not depart from the inventive concept of this invention.

[0149] The scope of protection of this invention shall be determined by the actual description in the claims. The specification and drawings are for interpreting the claims only and shall not be used to limit the claims.

Claims

1. An adaptive traffic playback acceleration method based on multi-factor perception, characterized in that, Includes the following steps: Step S1: Monitor the deviation between the playback progress time and the real-time time. When the deviation exceeds the preset trigger threshold, trigger the adaptive dynamic acceleration mode, and calculate the theoretical acceleration window based on the original time interval and the preset acceleration multiplier range to generate the planned sending interval. Step S2: Obtain the business attribute identifier of the transaction to be sent, determine whether the current transaction belongs to a critical business transaction, if it does, use the preset security interval corresponding to the business attribute identifier to impose a lower limit constraint on the planned sending interval to generate a first adjustment interval, if it does not belong to the critical business transaction, use the planned sending interval as the first adjustment interval. Step S3: Periodically collect response time samples of the system under test for processing transaction requests, calculate the average response time in the current statistical period, generate a trend quantification factor based on the relative change between the current average response time and the average response time in the previous statistical period, determine the current performance range based on the comparison results between the current average response time and preset low load thresholds and high load thresholds, and adjust the first adjustment interval using the trend quantification factor according to the adjustment strategy corresponding to the performance range to generate a second adjustment interval; Step S4: Monitor the number of transactions in transit that have been sent but have not yet received a response in the system under test in real time, and determine whether the current number of transactions in transit is greater than or equal to the preset high water level threshold. If so, pause the sending of the current transaction and continue to monitor the number of transactions in transit until it drops below the high water level threshold. If not, use the second adjustment interval as the final sending interval and execute the sending operation of the current transaction.

2. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 1, characterized in that, In step S1, the theoretical acceleration window consists of a minimum allowed interval and a maximum allowed interval, and the planned transmission interval is initially set to the minimum allowed interval. The minimum allowed interval is determined based on the ratio of the original time interval to the maximum acceleration ratio, and the maximum allowed interval is determined based on the ratio of the original time interval to the minimum acceleration ratio.

3. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 1, characterized in that, In step S2, the critical business transactions and their corresponding security intervals are determined through offline analysis: historical transaction traffic is replayed at different acceleration rates, the difference sensitivity index of each transaction type is calculated, transaction types with difference sensitivity greater than a preset threshold are marked as critical business transactions, and the baseline consumption time of the transaction type in an independent test environment is measured. A protection margin is added on the baseline consumption time as the security interval.

4. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 1, characterized in that, In step S3, the trend quantification factor is generated by an exponential function, and the specific calculation formula is: M=exp(α×R_raw), where M is the trend quantification factor, α is the preset trend sensitivity coefficient, and R_raw is the rate of change of the average response time of the current statistical period relative to the average response time of the previous statistical period.

5. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 4, characterized in that, In step S3, the performance range includes a high load range, a sensitive load range, and a low load range. When the current average response time is greater than the high load threshold, the adjustment strategy is: second adjustment interval = first adjustment interval × max(M,1) × high load penalty coefficient. When the current average response time is between the low load threshold and the high load threshold, the adjustment strategy is: second adjustment interval = first adjustment interval × M. When the current average response time is less than or equal to the low load threshold, the adjustment strategy is: second adjustment interval = first adjustment interval.

6. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 1, characterized in that, In step S2, the lower limit constraint on the planned transmission interval using the preset safety interval is specifically: taking the larger value between the planned transmission interval and the safety interval as the constrained interval, and then using the upper limit of the theoretical acceleration window to constrain the constrained interval to generate the first adjustment interval.

7. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 1, characterized in that, In step S3, after adjusting the first adjustment interval, a boundary trimming step is also included: limiting the adjusted interval to between the minimum allowable interval and the maximum allowable interval of the theoretical acceleration window.

8. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 1, characterized in that, In step S4, the high water level threshold is determined by stress testing, specifically by gradually increasing the concurrent load until the number of transactions per second of the tested system no longer increases and the response time increases significantly, recording the number of concurrent transactions at this time, and setting the high water level threshold to 90% of the number of concurrent transactions.

9. The adaptive traffic playback acceleration method based on multi-factor perception according to claim 1, characterized in that, In step S3, the performance statistics cycle is configured with a timeout protection mechanism: if the time since the last update has exceeded the preset timeout multiple multiplied by the feedback cycle duration, but the number of collected response time samples has not yet reached the minimum sample number requirement, then the existing samples are used to calculate the average response time of the current cycle. If the sample size is zero, then the average response time of the current period is kept equal to the average response time of the previous period.

10. An adaptive traffic playback acceleration system based on multi-factor perception, characterized in that, The system is used to perform the method of claim 1, the system comprising: The message middleware module, connected to the collaborative decision-making engine module, is used to store transaction data to be replayed, providing a data source containing transaction messages, original time information, and business attribute identifiers; The collaborative decision engine module is connected to the message middleware module, the state awareness module, and the traffic scheduling executor module, respectively. It is used to perform multi-level serial decision-making based on system state information and transaction data, and generate sending interval instructions. It includes a baseline calculation unit for executing step S1, a service protection unit for executing step S2, a trend feedback unit for executing step S3, and a flow control arbitration unit for executing step S4. The status awareness module is connected to the collaborative decision engine module and the traffic scheduling executor module respectively, and is used to collect and maintain system status information in real time, including a performance statistics unit for periodically calculating the average response time and a load monitoring unit for real-time monitoring of the number of transactions in transit. The traffic scheduling executor module is connected to the collaborative decision engine module and the state awareness module respectively. It is used to precisely schedule and execute the sending operation of the transaction according to the sending interval instruction, and to feed back to the state awareness module to update the system state information after the transaction is completed.

Images