Method and device for detecting performance of backup recovery data link, computer device and readable storage medium

Abstract

This application relates to a performance testing method, apparatus, computer device, and readable storage medium for a backup and recovery data link. A first speed test wrapper, positioned adjacent to the disk read / write logical object in the disk access layer, detects the first data transfer speed of data transmitted to the network transport layer via the backup and recovery data link. A second speed test wrapper, positioned at the outermost layer of the network transport layer, detects the second data transfer speed of data stored via the backup and recovery data link. The performance test result is determined based on the first and second data transfer speeds. Compared to traditional methods that indirectly infer performance through external system tools, this application improves the accuracy of performance testing by placing speed test wrappers adjacent to the disk read / write logical object and at the outermost layer of the network transport layer, detecting the data transfer speed separately through each speed test wrapper, and determining the performance test result of the backup and recovery data link based on the data transfer speed.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for performance testing of backup and recovery data links. Background Technology

[0002] In enterprise-level data backup and recovery systems, a single backup or recovery task is typically completed collaboratively by several components. In real-world production environments, the occasional excessively long processing times of backup or recovery tasks are a frequent problem encountered by operations and maintenance personnel. The cause of slow input / output performance can originate from any link in the data link. Currently, performance testing of the backup and recovery data link is usually done indirectly through external system tools, which cannot directly pinpoint the source of the slow performance, leading to reduced accuracy in performance testing.

[0003] Therefore, current methods for testing the performance of backup and recovery data links suffer from low accuracy. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for performance testing of backup and recovery data links that can improve accuracy in addressing the aforementioned technical problems.

[0005] Firstly, this application provides a performance testing method for backup and recovery data links, including:

[0006] When the disk access layer is detected to meet the first performance detection condition, the first data transfer speed corresponding to the disk access layer is detected by the first speed test wrapper; the first speed test wrapper is set adjacent to the disk read / write logical object of the disk access layer; the disk read / write logical object represents the object that implements the data transfer function of the disk access layer; the disk access layer is used to transmit data to the network transport layer through backup and recovery data link.

[0007] When the network transport layer is detected to meet the second performance detection condition, the second data transmission speed corresponding to the network transport layer is detected by the second speed test wrapper; the second speed test wrapper is set on the outermost layer of the network transport layer; the network transport layer is used to store the data transmitted by the disk access layer through the backup recovery data link.

[0008] The performance test result of the backup and recovery data link is determined based on the first data transmission speed and the second data transmission speed.

[0009] Secondly, this application also provides a performance testing device for backup and recovery data links, comprising:

[0010] The first detection module is used to detect the first data transmission speed corresponding to the disk access layer by a first speed test wrapper when the disk access layer meets the first performance detection condition. The first speed test wrapper is arranged adjacent to the disk read / write logical object of the disk access layer. The disk read / write logical object represents the object that implements the data transmission function of the disk access layer. The disk access layer is used to transmit data to the network transport layer through backup and recovery of the data link.

[0011] The second detection module is used to detect the second data transmission speed corresponding to the network transport layer by using a second speed test wrapper when the network transport layer meets the second performance detection condition; the second speed test wrapper is set on the outermost layer of the network transport layer; the network transport layer is used to store the data transmitted by the disk access layer through the backup recovery data link.

[0012] The determination module is used to determine the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed.

[0013] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0014] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0015] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0016] The aforementioned performance testing method, apparatus, computer equipment, computer-readable storage medium, and computer program product for backup and recovery data links, when a first performance testing condition is met, detects the first data transfer speed corresponding to the data transmission from the disk access layer to the network transport layer via the backup and recovery data link using a first speed test wrapper positioned adjacent to the disk read / write logical object of the disk access layer. Then, it detects the second data transfer speed of the network transport layer storing data via the backup and recovery data link using a second speed test wrapper positioned on the outermost layer of the network transport layer. Based on the first and second data transfer speeds, the performance testing result of the backup and recovery data link is determined. Compared to traditional indirect performance inference through external system tools, this application improves the accuracy of performance testing by setting speed test wrappers adjacent to the disk read / write logical object and on the outermost layer of the network transport layer, detecting the data transfer speed separately through each speed test wrapper, and determining the performance testing result of the backup and recovery data link based on the data transfer speed. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating a performance testing method for backup and recovery data links in one embodiment;

[0019] Figure 2 This is a schematic diagram of the structure of the speed monitoring core component in one embodiment;

[0020] Figure 3 This is a timing diagram of the scope timing recorder's operation in one embodiment;

[0021] Figure 4 This is a flowchart illustrating the detection steps of the speed-measuring packaging device in one embodiment;

[0022] Figure 5 This is a flowchart illustrating the adaptive log interval adjustment step in one embodiment;

[0023] Figure 6 This is a flowchart illustrating the performance testing method for backup and recovery data links in another embodiment;

[0024] Figure 7 This is a structural block diagram of a performance testing device for backup and recovery data links in one embodiment;

[0025] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0027] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0028] In related technologies, in enterprise-level data backup and recovery systems, a single backup or recovery task is typically completed collaboratively by several components. For example, at the data source layer, the raw data is provided by virtual machine disks (accessed via VMware Virtual Disk Development Kit (VDDK) or Network File System (NFS)) and the database; at the backup agent layer, the backup agent is responsible for reading data from the data source, performing compression, encryption, deduplication, and other processing, and then writing the data to the storage backend through the network transport layer (Client IO) module; at the storage backend layer, the storage service is responsible for receiving the data from the backup agent and persisting it to the backup storage medium (disk pool, object storage, etc.).

[0029] In real-world production environments, the occasional excessively long backup or restore times are a frequent problem encountered by operations and maintenance (O&M) personnel. The cause of these slow tasks can stem from any link in the chain: insufficient source disk performance, limited network bandwidth, write bottlenecks in the storage backend, or limitations in the backup agent's own processing capabilities. However, when problems occur, O&M personnel typically lack direct means to determine which link is the bottleneck and can only rely on external operating system tools for indirect inference. This diagnostic process is cumbersome and difficult to directly correlate with the backup task context.

[0030] Performance monitoring tools primarily focus on system-level resource monitoring, recording global I / O metrics for the entire machine or network interface card. They cannot accurately reflect the I / O throughput of a specific backup task. Some backup software provides an "average speed" report after task completion, but this data is only a rough estimate of the total number of bytes transferred divided by the total time taken. It cannot reflect real-time speed changes during task execution, nor is it continuously visible during task execution, thus limiting its real-time diagnostic value for slow speed issues. For example, after all backup tasks are completed, the backup software can calculate the total number of bytes transferred and the total time taken, outputting an average transfer speed value in the task completion log or report interface. The workflow is as follows: record the start time when the task starts; record the end time when the task ends and calculate the total number of bytes transferred; calculate the average speed = total number of bytes / total time taken, and write it to the log or task report. Alternatively, monitoring can be done indirectly through external tools. For example, administrators can use external tools provided by the operating system to monitor system-level I / O and network bandwidth during backup task execution to indirectly infer the backup transfer speed. The above solutions have the following problems:

[0031] The system lacks real-time monitoring of transmission performance and immediate diagnostic tools when problems occur. The approach of calculating average speed after task completion only provides data after the task is finished. When performance degradation occurs during task execution, the system cannot detect changes in actual throughput during task execution, nor can it determine at which stage of the task the slowdown occurs, thus completely lacking real-time diagnostic capabilities for slowdown issues during task execution.

[0032] Average speed masks intermittent performance fluctuations and fails to pinpoint instantaneous bottlenecks. The average speed obtained by dividing the total number of bytes in the task by the total execution time mixes data from high-speed and low-speed phases, masking short-term speed drops or periodic fluctuations during task execution. When a backup task experiences intermittent slowness due to storage contention, network congestion, or other reasons, the average speed after task completion may appear acceptable, thus concealing the actual intermittent bottleneck.

[0033] External monitoring tools are disconnected from the task context, making it difficult to accurately pinpoint the source. When monitoring using external operating system tools, system-wide I / O and network data are collected, making it impossible to precisely correlate them with a specific backup task or a specific transmission link. When multiple backup tasks are running simultaneously in the system, or when backup agents share network bandwidth with other business processes, administrators cannot determine which task the observed I / O data belongs to at any given moment, resulting in low diagnostic efficiency.

[0034] Combined read and write speed statistics fail to distinguish between read and write bottlenecks. In backup and recovery processes, the backup agent handles two independent I / O operations simultaneously: reading data from the data source and writing data to the storage backend. Calculating the total number of bytes and total time for both operations together only yields a general overall transfer speed figure, failing to reveal the actual throughput of each read and write operation during that time. When the overall speed is found to be low, administrators cannot determine whether the bottleneck originates from the read side (insufficient data source performance) or the write side (network bandwidth or storage backend write bottleneck) based solely on this figure. They must instead troubleshoot each possible link individually, which is time-consuming and labor-intensive.

[0035] Furthermore, by using the total bytes / total time calculation method, the time spent on intermediate processing steps (compression calculation, encryption calculation, deduplication hashing, etc.) is also included in the denominator. This results in the overall number being artificially suppressed due to processing time, even if the read and write IO speed itself is very high, leading to a systematic underestimation of the actual IO performance and failing to accurately reflect the true throughput capacity of each IO layer.

[0036] The lack of layered observation capabilities across multiple I / O layers makes it impossible to accurately pinpoint the bottleneck level. In a backup task, data passes through multiple I / O layers (data source, backup agent processing, network transmission, and storage backend), and any layer can become a bottleneck. Currently, there is a lack of means to independently measure the I / O speed of each layer, making it difficult to determine which layer the bottleneck is located at even if overall transmission is slow (whether it is slow reads from the source, slow network transmission, or slow writes from the backend).

[0037] Based on this, this application sets speed test wrappers at the adjacent positions of disk read / write logical objects and at the outermost layer of the network transport layer, respectively. Each speed test wrapper detects the data transmission speed, and the performance test result of the backup and recovery data link is determined based on the data transmission speed, thereby improving the accuracy of performance testing.

[0038] Specifically, this application independently tracks the speeds of read and write operations. By precisely marking the entry and exit points of each read() or write() system call, it only accumulates the actual time and number of bytes consumed by the system call itself, completely eliminating interference from intermediate processing steps such as compression and encryption. This yields independent and accurate read and write speeds. This allows operations personnel to directly see two independent figures during backup task execution: the speed at which the data source is read and the speed at which data is written to the storage backend. This improves the ability to determine whether the bottleneck lies on the read or write side, without relying on any external tools or post-processing analysis.

[0039] In one embodiment, such as Figure 1As shown, a performance testing method for backup and recovery data links is provided. This embodiment illustrates the application of this method to a server. It is understood that this method can also be applied to terminals, and also to systems including terminals and servers, and is implemented through interaction between the terminal and the server, including the following steps S202 to S206. Wherein:

[0040] Step S202: When the disk access layer is detected to meet the first performance detection condition, the first data transmission speed corresponding to the disk access layer is detected by the first speed test wrapper; the first speed test wrapper is set adjacent to the disk read / write logical object of the disk access layer; the disk read / write logical object represents the object that implements the data transmission function of the disk access layer; the disk access layer is used to transmit data to the network transport layer through backup and recovery data link.

[0041] This application relates to a method for real-time, built-in input / output (data transfer) performance measurement and periodic diagnostic reporting of the data transfer link between the backup agent and the storage backend, and the input / output (IO) link between the backup agent and the data source (virtual machine disk, database, etc.) during backup and recovery task execution. The backup agent refers to the core process running on the protected host (or backup server) responsible for reading data from the data source and transmitting it to the storage backend.

[0042] A server can be a device used to perform performance testing on a backup and recovery data link. A backup and recovery data link can be a data link established during data backup or recovery. The first performance testing condition can be the detection of calls to data transfer functions such as `read()` and `write()` at the disk access layer. If the server detects calls to these functions, it determines that the first performance testing condition is met.

[0043] The aforementioned disk access layer can be a layer related to a data source, which can be the location used to read data during backup and recovery. The disk access layer can be used to transfer data to the network transport layer via the backup and recovery data link. The network transport layer can be used to store data to the backend via the backup and recovery data link. The aforementioned disk access layer contains disk read / write logic objects. These disk read / write logic objects can be objects that implement the data transfer functions of the disk access layer, such as code that implements the data transfer functions of the disk access layer. A first speed test wrapper can be set adjacent to the disk read / write logic objects in the disk access layer, for example, by wrapping the relevant handles of the disk read / write logic objects to form the first speed test wrapper. Thus, when the server detects that the disk access layer meets the first performance detection condition, it can use the first speed test wrapper to detect the first data transfer speed corresponding to the disk access layer. The first data transfer speed can be the speed at which data is read from the data source.

[0044] Step S204: When the network transport layer is detected to meet the second performance detection condition, the second data transmission speed corresponding to the network transport layer is detected by the second speed test wrapper; the second speed test wrapper is set on the outermost layer of the network transport layer; the network transport layer is used to store the data transmitted by the disk access layer through the backup recovery data link.

[0045] The second performance detection condition can be the detection of calls to data transfer functions such as `read()` and `write()` at the network transport layer. If the server detects such calls, it determines that the second performance detection condition is met. The aforementioned network transport layer (Client IO) can be a layer related to the storage backend. For example, the server uses the network transport layer to store data transmitted in the backup and recovery data link to the storage backend. The network transport layer can be an IO client module in the backup agent program responsible for establishing network connections and transmitting data with the storage backend (Storaged). It supports multiple transmission protocols and can be layered with compression, encryption, and speed testing processing layers. The storage backend (Storaged) can be a storage service process responsible for receiving backup data transmitted by the backup agent program and persisting it to storage media (disk pool, object storage, etc.). The second speed test wrapper can be set at the outermost layer of the aforementioned network transport layer to intercept data flow information during data reading and writing, thereby determining the transmission speed.

[0046] When the server detects that the network transport layer meets the second performance detection condition, it can use a second speed test wrapper to detect the second data transmission speed corresponding to the network transport layer. This second data transmission speed can be the speed at which the network transport layer writes data sent by the disk access layer to the storage backend.

[0047] Specifically, the server uses the decorator pattern to non-intrusively overlay the aforementioned monitoring capabilities onto the existing IO pipeline, continuously outputting phased and cumulative speeds through an independent periodic log thread; at the same time, monitoring components are built into multiple key layers of the data transmission link to achieve layered diagnosis; and mechanisms such as speed threshold alarms, adaptive log intervals, and automatic cross-layer bottleneck location are introduced to build a standardized, quantifiable, and automatically diagnostic built-in IO performance diagnostic system.

[0048] The cumulative speed represents the speed value obtained by dividing the total number of bytes transferred since the task started by the cumulative time of all I / O operations, reflecting the overall throughput level throughout the entire task lifecycle. The decorator pattern is a software design pattern that adds new functionality transparently to a target object by wrapping it in a wrapper object with the same interface, without changing the original object. Both the first speed test wrapper (Speed_Monitored_Disk_Handle) and the second speed test wrapper (Speed_Test_IO) mentioned above use this pattern.

[0049] Step S206: Determine the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed.

[0050] Once the server obtains the first data transmission speed and the second data transmission speed, it can determine the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed.

[0051] The performance test results can include whether the read and write speeds of the backup and recovery data link are normal. If the first data transfer speed is abnormal, the server determines that the read speed of the backup and recovery data link is abnormal; if the second data transfer speed is abnormal, the server determines that the write speed of the backup and recovery data link is abnormal. This allows for direct and accurate identification of the cause of slow backup and recovery speeds.

[0052] In the aforementioned performance testing method for the backup and recovery data link, when a first performance testing condition is met, a first speed test wrapper, positioned adjacent to the disk read / write logical object of the disk access layer, detects the first data transfer speed corresponding to the data transmission from the disk access layer to the network transport layer via the backup and recovery data link. A second speed test wrapper, positioned at the outermost layer of the network transport layer, detects the second data transfer speed of the data stored by the network transport layer via the backup and recovery data link. Based on the first and second data transfer speeds, the performance testing result of the backup and recovery data link is determined. Compared to traditional indirect performance inference through external system tools, this application improves the accuracy of performance testing by setting speed test wrappers adjacent to the disk read / write logical object and at the outermost layer of the network transport layer, detecting the data transfer speed separately through each speed test wrapper, and determining the performance testing result of the backup and recovery data link based on the data transfer speed.

[0053] In one embodiment, the method further includes: obtaining the original first speed test wrapper and disk handle interface corresponding to the disk access layer; the disk handle interface is used to determine the disk read / write logic object; and the disk handle interface is wrapped by the original first speed test wrapper to obtain the first speed test wrapper.

[0054] In this embodiment, the server can pre-set a first speed test wrapper at the disk access layer. The server can obtain the original first speed test wrapper and disk handle interface corresponding to the disk access layer. The original first speed test wrapper can be an unmodified speed test wrapper. The disk handle interface can be an interface used to implement disk read / write logic objects. The server can wrap the disk handle interface with the original first speed test wrapper to obtain the first speed test wrapper. Therefore, when the disk read / write logic object implements the disk transfer function, the server can detect the actual amount of data transferred and the data transfer time of the read and write functions through the first speed test wrapper.

[0055] Specifically, the first and second speed measurement wrappers include a speed monitoring core component (Speed_Monitor). The first and second speed measurement wrappers implement the following functions through the speed monitoring core component: Statistical data structure: The speed monitoring core component internally uses lock-free atomic variables (std::atomic).<uint64_t> Two sets of statistical data are maintained: Period Stats: Records the cumulative number of bytes read and written and the actual time consumed within the current log period, and is reset to zero after each log output; Total Stats: Records the total number of bytes read and written and the actual time consumed since the task started, and is not reset, continuously accumulating until the task ends. Atomic variables are a variable type in multithreaded programming whose read and write operations are guaranteed to be atomic at the hardware level. They can be used safely in a multithreaded environment without locking, avoiding the performance overhead of mutex locks.

[0056] Independent Log Thread: The speed monitoring core component creates a dedicated background log thread (Speed_Mon) upon startup (start()). This thread waits in a loop at configurable time intervals (log_interval_seconds_, supporting any value between 1 second and 3600 seconds by default). After each cycle, it calls the log output function to write the current stage speed and cumulative speed to the system log in a structured table format. When the IO (data transfer) task ends, the speed monitoring core component notifies the log thread to exit via an event signal (Manual_Event). Before exiting, the thread performs a final log output to ensure that the final data at the time of task completion is completely recorded. The stage speed represents the speed value obtained by dividing the actual number of bytes transferred within a fixed time window (log cycle) by the cumulative time of actual IO operations within that time window, reflecting the real-time throughput level within that time window.

[0057] Log output format: Each time a log is output, the speed monitoring core component simultaneously outputs the following in a structured format: current stage read speed (bytes / second), total read volume for this stage; current stage write speed (bytes / second), total write volume for this stage; cumulative read speed and cumulative total read volume since task startup; cumulative write speed and cumulative total write volume since task startup. The server can automatically convert data units into a readable format (KB / s, MB / s, GB / s; KB, MB, GB, etc.) for easy reading by operations and maintenance personnel.

[0058] Context identifier: The core component of speed monitoring accepts a context name string (context_name) during initialization. This name will appear in every log record, enabling operations and maintenance personnel to clearly distinguish the performance data belonging to different tasks and different disks in the logs when multiple tasks are running concurrently.

[0059] Lifecycle Management: The start() / stop() interface of the core component of speed monitoring is bound to the open() / close() lifecycle of the IO object to ensure that speed measurement starts and ends synchronously with the actual IO operation, avoiding misleading zero speed data when IO has not started.

[0060] The internal interface and thread model of the speed monitoring core component can be as follows: Figure 2 As shown, Figure 2 This is a schematic diagram of the structure of the speed monitoring core component in one embodiment.

[0061] The complete lifecycle of the speed monitoring core component begins with the call to the start function (start()) after the IO open (IO open()) operation and ends with the call to the stop function (stop()) after the IO close (IO close()) operation. The speed monitoring core component contains three core logical units. The first unit is an atomic statistical variable area marked as lock-free and directly written by the IO thread. This area is divided into two types of statistical values: one is cumulative statistics that will not be reset, including total read bytes, total read time, total write bytes, and total write time; the other is periodic statistics that are reset every cycle, including read bytes, read time, write bytes, and write time. The scoped timer recorder (Scoped_Speed_Recorder), which is constructed and destroyed every time an IO call is made, will call the update statistics function (update_stats()). The second part of the speed monitoring core component is an independent background log thread area, which writes the read and write data of a single IO operation to the atomic statistical variables above. The log thread continuously executes the following loop logic: First, it executes the operation of waiting for the stop event (stop_event_) and sets the timeout time to the printing cycle interval (timeout=interval). If the timeout flag (ETIME) is triggered during the wait, the speed log printing function (log_speed()) is executed. This function reads the periodic statistical data and resets the periodic statistical data. If a stop event signal is received during the waiting process, the speed log printing function (log_speed()) is also executed, and then the thread exits. The entire set of running logic is coherent and connected. The data generated by the IO operation is updated in real time to the atomic statistical variables through the scoped timer recorder (Scoped_Speed_Recorder). The background log thread will actively pull the periodic statistical data and output the speed log according to the set period. When the business executes the IO close (IO close()) and calls stop (stop()), the stop event will be triggered, allowing the log thread to complete the last log printing and end its operation.

[0062] The log output format can include: {Statistics type: Period, Read speed: 312MB / s, Read data volume: 1.22GB, Write speed: 308MB / s, Write data volume: 1.20GB}, {Statistics type: Total, Read speed: 287MB / s, Read data volume: 9.87GB, Write speed: 284MB / s, Write data volume: 9.76GB}.

[0063] The first and second speed measurement wrappers mentioned above can also include a scoped speed recorder (Scoped_Speed_Recorder). The scoped speed recorder (Scoped_Speed_Recorder) is a RAII auxiliary component used in conjunction with the speed monitoring core component. RAII (Resource Acquisition Is Initialization) is a C++ programming idiom that binds resource acquisition to object construction and resource release to object destruction, using C++ deterministic destruction mechanisms to ensure no resource leakage. The scoped speed recorder can achieve automatic timing through this mechanism. Its working principle is as follows: During construction: Record the current timestamp as the start time of the IO operation; Call set_bytes() (set bytes): After the actual IO operation is successfully completed, inform the recorder of the number of bytes transferred; During destruction: Calculate the time difference (microsecond precision) from construction to destruction. If the number of bytes transferred is greater than zero, automatically submit the IO time and the number of bytes transferred to the speed monitoring core component to update the statistical data. This ensures that the timing logic is tightly bound to I / O calls, eliminating the need for manual management of the start and end of the timing. It only tracks the time taken for I / O calls that actually transmit data, eliminating interference from invalid cases such as empty reads and failed calls, thus guaranteeing the accuracy of the speed data. The timing precision uses microseconds (ACE_OS::gettimeofday()), sufficient to capture millisecond-level I / O speed fluctuations.

[0064] The timing sequence of the scope timer is as follows: Figure 3 As shown, Figure 3This is a timing diagram of the scoped timer recorder's operation in one embodiment. The process flow includes upper-level calls, the scoped timer recorder (Scoped_Speed_Recorder), actual I / O, and a speed monitor (Speed_Monitor). The server begins by initiating a recorder construction operation from the upper-level call. This operation is passed to the scoped timer recorder (Scoped_Speed_Recorder), which first records the start time (start_time_). Then, the upper-level call initiates read / write I / O calls (io->read / write()) and flows to the scoped timer recorder (Scoped_Speed_Recorder). The recorder then sends the I / O execution instructions to the actual I / O module. After the actual I / O is processed, the execution result is sent back to the scoped timer recorder (Scoped_Speed_Recorder), which then returns the result to the upper-level call. The upper-level call then invokes the recorder's byte count setting interface (record). `r.set_bytes(n)` passes the byte value `n` to the scoped timer recorder (Scoped_Speed_Recorder). The recorder internally records the total number of bytes transferred (bytes_transferred). When the code scope finishes running, the upper layer calls the recorder's destructor process and passes it to the scoped timer recorder (Scoped_Speed_Recorder). The recorder internally calculates the elapsed time by subtracting the start time from the current time (elapsed=now-start_time_). Then, it calls the update statistics function (update_stats(elapsed,n)) and passes in the calculated elapsed time and the number of bytes transferred. It performs the logic of atomically accumulating read and write statistics and finally pushes the updated statistics to the speed core monitoring component (Speed_Monitor) to complete the collection and reporting of speed data (first data transfer speed / second data transfer speed) for a single IO operation.

[0065] Specifically, the first speed test wrapper is implemented at the disk access layer. For data sources that cannot uniformly use the network transport layer (ClientIO) path (such as VMware virtual machine disks accessed through the Virtual Disk Development Kit (VDDK) Application Programming Interface (API) or the Network File System RESTful interface), the server can implement a corresponding speed test wrapper (Speed_Monitored_Disk_Handle) at the disk access interface layer; this is the first speed test wrapper. The Virtual Disk Development Kit, provided by VMware, allows third-party programs to directly access the virtual disk data of VMware virtual machines and is a core technology interface for VMware backup.

[0066] The disk access layer speed test wrapper (the first speed test wrapper, Speed_Monitored_Disk_Handle) wraps an implementation of the Disk_Handle interface (disk handle interface) (which can be a VDDK handle or a RESTful disk handle). During construction, it initializes and starts the speed monitoring core component (with the disk name as the context identifier). During each read() / write() call, it uses a scoped timer to perform precise timing. During destruction, the speed monitoring core component automatically stops and outputs the final statistics.

[0067] In VMware's backup and recovery process, when IO speed testing is enabled in the task configuration, after opening each virtual disk (after the VDDK handle is created), the server wraps the original handle into a Speed_Monitored_Disk_Handle. All subsequent read and write operations on this disk go through the speed testing layer, and the upper-level calling code for disk access does not need to be aware of the existence of this wrapping.

[0068] In this embodiment, the server can use a speed test wrapper to wrap the disk handle interface, thereby enabling the reading of data transfer speed at the disk access layer and improving the accuracy of performance testing for the backup and recovery data link.

[0069] In one embodiment, detecting the first data transfer speed corresponding to the disk access layer using a first speed test wrapper includes: when a first data transfer function for the disk access layer is detected, determining a first data transfer time using the first speed test wrapper, and detecting a first data transfer amount corresponding to the first data transfer function; and determining the first data transfer speed corresponding to the disk access layer based on the first data transfer time and the first data transfer amount.

[0070] In this embodiment, the server can detect the first data transfer speed corresponding to the disk access layer using a first speed test wrapper. Specifically, the server can determine the first data transfer speed by combining the total amount of data transferred and the data transfer time using the first speed test wrapper. When the server detects a first data transfer function targeting the disk access layer, it can determine the first data transfer time using the first speed test wrapper, for example, by calculating the time spent transferring data through the first data transfer function. The server can also detect the first data transfer amount corresponding to the first data transfer function, such as the total amount of data transferred through the first data transfer function. Therefore, the server can determine the first data transfer speed corresponding to the disk access layer based on the first data transfer time and the first data transfer amount, for example, by determining the first data transfer speed based on the ratio of the first data transfer amount to the first data transfer time. The first data transfer speed can be the speed of reading data from the disk access layer or the speed of writing data through the disk access layer.

[0071] Specifically, the disk access layer speed test wrapper (the first speed test wrapper, Speed_Monitored_Disk_Handle) wraps an implementation of the Disk_Handle interface (disk handle interface) (which can be a VDDK handle or a RESTful disk handle). During construction, it initializes and starts the speed monitoring core component (with the disk name as the context identifier). During each read() / write() (first data transfer function) call, it uses a scoped timer to perform precise timing. During destruction, the speed monitoring core component automatically stops and outputs the final statistics.

[0072] Through this embodiment, the server can determine the first data transmission speed based on the data transmission volume and data transmission time corresponding to the first data transmission function, thereby improving the accuracy of determining the data transmission speed in the backup and recovery data link.

[0073] In one embodiment, the method further includes: when the network transport layer establishes the backup recovery data link, generating an original second speed test wrapper at the outermost layer of the network transport layer using the decorator pattern; and determining the second speed test wrapper based on the resource opening function of the network transport layer and the original second speed test wrapper.

[0074] In this embodiment, the server can pre-configure a second speed test wrapper at the network transport layer. This second speed test wrapper can be configured using the decorator pattern. When the server detects the establishment of the backup / recovery data link at the network transport layer, it can generate an original second speed test wrapper at the outermost layer of the network transport layer using the decorator pattern. The server can then determine the second speed test wrapper based on the resource opening function of the network transport layer and the original second speed test wrapper. The resource opening function can be a function used to open data transmission. The original second speed test wrapper can be a speed test wrapper that has not been configured using the decorator pattern.

[0075] Specifically, this refers to the network transport layer (Client IO) speed test wrapper (Speed_Test_IO), also known as the second speed test wrapper. The second speed test wrapper uses the decorator pattern, inheriting from Pipe_IO (the base class for pipe IO). The server uses an already created Client_IO_Base object as the wrapped inner IO object. Its workflow is as follows: Assembly: When the backup task is configured with speed_test_interval > 0 (enabling task configuration parameters), during the network transport layer connection establishment process (connect()), a Speed_Test_IO instance (the second speed test wrapper) is appended to the outermost layer of the IO processing pipeline (which may already include compression, encryption, and other processing layers). Because it uses the decorator pattern, Speed_Test_IO is completely transparent to the implementation type of the inner IO layer; the inner layer can be wrapped without modification. Pipe_IO represents an infrastructure class in the network transport layer, implementing the decorator base class functionality, holding a reference to the inner IO object, and forwarding all IO operations to the inner object by default, facilitating the construction of multi-layered IO processing pipelines on top of it.

[0076] During the open phase: When Speed_Test_IO calls open() (the resource opening function), it stops and resets the speed monitoring core component (clearing any residual statistics from the previous operation), calls the inner IO's open() function, and upon success, initializes and starts the speed monitoring core component with the current path as the context name, while also starting the log thread.

[0077] During the read / write (data transfer) phase: For each read() or write() call, the server creates a scoped timer logger (specifying the read / write direction) through Speed_Test_IO (the second speed test wrapper), calls the inner IO to perform the actual transfer, and records the number of bytes transferred this time through set_bytes() (the byte setting function). When the scoped timer logger is destructed, the time and number of bytes are automatically submitted to the speed monitoring core component.

[0078] During the close phase: Speed_Test_IO stops the speed monitoring core component when it closes() (the resource close function), and the logging thread outputs the final statistics before exiting.

[0079] Among them, the second speed measurement wrapper in the decorator stack structure in the network transmission layer pipeline is as follows: Figure 4 As shown, Figure 4 This is a flowchart illustrating the detection steps of the speed-measuring packaging device in one embodiment. Figure 4 The layered architecture diagram illustrates the nested hierarchical flow of the entire IO call process. The top layer is the upper-layer business code, which initiates a read (read()) or write (write()) call request. This request first enters the second speed test wrapper (Speed_Test_IO), the outermost layer of the entire IO chain. Its function is to intercept IO calls and perform timing and performance statistics. Inside the second speed test wrapper (Speed_Test_IO) is an optional compression IO layer (Compress_IO), which in turn is an optional encryption IO layer (Encrypt_IO). The encryption IO layer (Encrypt_IO) encapsulates the actual network... The network transport layer, including implementations of Hypertext Transfer Protocol I / O (HTTP_IO) and Object Storage I / O (S3_IO), is specifically responsible for establishing communication with the storage backend. All I / O requests, after multi-layer encapsulation processing, are ultimately sent to the storage backend to complete data persistence. The overall design employs a layered approach with nested decorators. The second speed test wrapper (Speed_Test_IO) captures the entire I / O latency and transmitted bytes at the entry point for speed monitoring statistics. The compression I / O layer (Compress_IO) and encryption I / O layer (Encrypt_IO) can be enabled or disabled as needed without altering the underlying network transport logic interacting with the storage backend. The second speed test wrapper is the outermost layer, therefore its statistics reflect the actual network throughput from the business layer's perspective, excluding compression / encryption processing time, directly corresponding to the actual data transfer speed that users care about.

[0080] In this embodiment, the server can use the decorator pattern to place the second speed test wrapper on the outermost layer of the network transport layer, thereby obtaining the data transmission speed of the network transport layer and improving the accuracy of determining the data transmission speed in the backup and recovery data link.

[0081] In one embodiment, detecting the second data transmission speed corresponding to the network transport layer using a second speed test wrapper includes: when a data transmission request for the network transport layer is detected, calling the second data transmission function of the network transport layer through the second speed test wrapper to perform data transmission; determining the second data transmission time and the second data transmission amount corresponding to the second data transmission function through the second speed test wrapper; and determining the second data transmission speed corresponding to the network transport layer based on the second data transmission time and the second data transmission amount.

[0082] In this embodiment, the server can determine the second data transmission speed by combining the data transmission volume and data transmission time. Specifically, when the server detects a data transmission request for the network transport layer, it can call the second data transmission function of the network transport layer through the second speed test wrapper to perform data transmission. The second data transmission function can be a function that writes data to the storage backend. The server determines the second data transmission time and the second data transmission volume corresponding to the second data transmission function through the second speed test wrapper, thereby determining the second data transmission speed corresponding to the network transport layer based on the second data transmission time and the second data transmission volume. For example, the server determines the second data transmission speed corresponding to the network transport layer based on the ratio of the second data transmission volume to the second data transmission time.

[0083] Specifically, the second data transfer function can be included in the read / write function. During the read / write phase: for each read() or write() call, the server creates a scoped timer logger (specifying the read / write direction) using Speed_Test_IO (the second speed test wrapper), calls the inner IO layer to perform the actual transfer, and if the transfer is successful, records the number of bytes transferred using set_bytes(). When the scoped timer logger is destructed, the time taken and the number of bytes are automatically submitted to the speed monitoring core component.

[0084] Through this embodiment, the server can determine the second data transmission speed based on the data transmission volume and data transmission time corresponding to the second data transmission function, thereby improving the accuracy of determining the data transmission speed in the backup and recovery data link.

[0085] In one embodiment, determining the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed includes: acquiring a first low-speed count and a second low-speed count in multiple data transmission cycles; the first low-speed count represents the number of times the first data transmission speed is continuously less than a first speed threshold in the multiple data transmission cycles; the second low-speed count represents the number of times the second data transmission speed is continuously less than a second speed threshold in the multiple data transmission cycles; if the first low-speed count and / or the second low-speed count are greater than a preset count threshold, the performance test result of the backup and recovery data link is determined to be abnormal, and corresponding alarm information is generated based on the first low-speed count and / or the second low-speed count.

[0086] In this embodiment, the server can determine the performance test result by combining the first data transmission speed and the second data transmission speed. The server can acquire the data transmission speed in multiple data transmission cycles, thereby acquiring a first low-speed count and a second low-speed count in each of the multiple data transmission cycles. The first low-speed count represents the number of times the first data transmission speed is continuously less than a first speed threshold in the multiple data transmission cycles, and the second low-speed count represents the number of times the second data transmission speed is continuously less than a second speed threshold in the multiple data transmission cycles. The server determines whether the performance test result is abnormal (e.g., too low speed) based on the first low-speed count and the second low-speed count. If one or more of the first low-speed count and the second low-speed count exceeds a preset threshold, the server determines that the performance test result of the backup and recovery data link is abnormal and generates corresponding alarm information based on the first low-speed count and the second low-speed count. For example, if the number of times the first low speed is greater than the preset threshold, the server determines that the performance test result is an abnormal first data transmission speed and outputs an alarm message for disk access layer transmission abnormality; if the number of times the second low speed is greater than the preset threshold, the server determines that the performance test result is an abnormal second data transmission speed and outputs an alarm message for network transmission layer transmission abnormality.

[0087] Specifically, the server can be configured with a speed threshold alarm mechanism. A speed threshold alarm means that a minimum speed limit is configured in the speed monitoring component. When the actual speed falls below this limit for multiple consecutive periods, the log level is automatically raised to WARNING (fixable problem) or ERROR (system error), triggering the alarm process of the operation and maintenance monitoring system. The server configures a minimum speed threshold (min_speed_threshold) through the core speed monitoring component, such as the first and second speed thresholds mentioned above. At the output of each log period (data transmission period), the server compares the current stage speed with this threshold and maintains a continuous low-speed counter: if the read or write speed of the current period is lower than the threshold, the counter increments; if the speed recovers above the threshold, the counter is reset to zero; when the counter accumulates to exceed the configurable number of consecutive triggers (first low-speed count / second low-speed count, alert_consecutive_count), the server raises the log level of the subsequent task from INFO (feedback) to WARNING (fixable problem) or ERROR (system error).

[0088] After raising the log level, any operational alerting system connected to the backup system's log stream (such as log alerts from Elasticsearch, Logstash, Kibana (ELK), Zabbix log monitoring, etc.) can automatically capture and trigger alert notifications, eliminating the need for continuous manual log monitoring and achieving a shift from passive discovery to proactive alerting. The alert logs include: current speed, configured threshold, duration of continuous low speed, and task context name, enabling operations personnel to obtain a complete diagnostic context upon receiving the alert.

[0089] Through this embodiment, the server can combine the number of low-speed operations with the corresponding threshold to determine whether the transmission speed is abnormal, and then generate corresponding alarm information, thereby improving the accuracy of performance testing of the backup and recovery data link.

[0090] In one embodiment, after determining the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed, the method further includes: if the difference between the first data transmission speed and / or the second data transmission speed and the target data transmission speed is greater than a preset difference threshold, then increasing the detection frequency of the first data transmission speed and / or the second data transmission speed; the target data transmission speed represents the average of each first data transmission speed and / or the average of each second data transmission speed within the target window; the target window is generated based on the detection period of the first data transmission speed and / or the second data transmission speed.

[0091] In this embodiment, the server can determine the detection frequency for data transmission speed based on a first data transmission speed and a second data transmission speed. For example, the server can determine the target data transmission speed corresponding to the average of the first data transmission speed and the second data transmission speed, respectively. The target data transmission speed represents the average of all first data transmission speeds within the target window, and can also be the average of all second data transmission speeds within the target window. The target window can be generated based on the detection period of the first data transmission speed or the detection period of the second data transmission speed. If the server detects that the difference between the first data transmission speed and the target data transmission speed corresponding to the first data transmission speed is greater than a preset difference threshold, the detection frequency of the first data transmission speed is increased. If the server detects that the difference between the second data transmission speed and the target data transmission speed is greater than a preset difference threshold, the detection frequency of the second data transmission speed is increased.

[0092] Specifically, the server can be configured with adaptive log interval adjustment. Adaptive log interval refers to a mechanism that automatically adjusts the log output frequency based on real-time speed fluctuations. When the speed is stable, logs are output at a lower frequency; when the speed deviates significantly, the interval is automatically shortened to improve time resolution; and the original interval is restored once the speed stabilizes. The server maintains a sliding window through the speed monitoring core component, recording the periodic speed data (read speed and write speed) for the most recent log cycles. After each log output, the deviation ratio between the current cycle speed (first data transmission speed / second data transmission speed) and the historical average within the window (target data transmission speed) is calculated.

[0093] If the deviation exceeds the configurable threshold (preset difference threshold, such as 50% of the average), the server determines it as an abnormal speed fluctuation and temporarily shortens the log output interval (detection frequency) from the baseline value (speed_test_interval) to the encrypted mode interval (such as shortening it to one-fifth of the baseline value) to capture fluctuation details with higher time resolution. If the speed stabilizes again within several consecutive encrypted sampling periods (the deviation returns to within the preset difference threshold), the server automatically restores the log interval to the baseline value to avoid generating too many logs during normal operation.

[0094] The adaptive log interval adjustment process is as follows: Figure 5 As shown, Figure 5This is a flowchart illustrating the adaptive log interval adjustment steps in one embodiment. At the end of each log cycle, the server first outputs the current cycle's speed log, then updates the sliding window, which stores speed data from the most recent N cycles. Next, the deviation is calculated by subtracting the absolute value of the window mean from the current speed and then dividing by the window mean. The server then checks if the calculated deviation exceeds a preset threshold (preset difference threshold), for example, 50%. If the result is negative, the current log interval (detection frequency) is maintained without parameter adjustment, and the process directly reaches its endpoint. If the result is positive, the system switches to encrypted sampling mode, setting the log interval to one-fifth of the base interval. Speed ​​sampling continues in encrypted mode, and the system executes a judgment logic to confirm whether the deviation values ​​calculated for M consecutive cycles are less than the threshold. If the result is negative, the encrypted sampling state is maintained, and the process returns to the subsequent aggregation node. If the result is positive, the log interval is restored to the base interval. Both branch paths eventually converge at a unified node, ending the current round of adaptive interval adjustment.

[0095] The server can output a bottleneck analysis summary. This summary is a structured log automatically generated by the cross-layer speed comparison module at the end of the task, listing the speed data for each I / O layer and identifying the layer with the lowest speed as the bottleneck in the current task's transmission link, helping to quickly pinpoint the root cause of the problem. Specifically, within the same backup task, the speed monitoring core component instances of each I / O layer (disk access layer, network transmission layer, etc.) report their cumulative statistics (total bytes, total I / O time, average speed) to the task-level speed aggregation module at the end of the task. This module outputs a bottleneck analysis summary in the task completion log, including: the average read / write speed and cumulative transmission volume of each layer; marking the layer with the lowest speed (i.e., the current task's transmission bottleneck layer); and if a layer's speed is significantly lower than other layers (e.g., lower than a certain percentage of the highest layer's speed), adding textual explanations indicating that this layer may be the root cause of the task's slowness.

[0096] For example, if the disk access layer read speed reaches 500MB / s, but the network transport layer write speed is only 50MB / s, the summary will directly indicate that the bottleneck is in the network transport layer, and suggest checking network bandwidth or stored write performance. The log can specifically include: {Overall task summary, Task name (Task): backup-job, Duration (Duration): 00:32:17}, {Statistics type: Disk Access (DiskAccess(VDDK)), Average read speed (AvgReadSpeed): 487MB / s, Total read data (ReadTotal): 94.3GB, Average write speed (AvgWriteSpeed): No data (--), Total write data (WriteTotal): No data (--)}, {Statistics type: Network Transport Layer (NetworkTransfer(HBR)) (Network Transport Layer), Average read speed (AvgWriteSpeed): 487MB / s, Total write speed (AvgWriteSpeed): 94.3GB, Average write speed (AvgWriteSpeed): No data (--), Total write data (WriteTotal): No data (--)}, {Statistics type: Network Transport Layer (NetworkTransfer(HBR)) (Network Transport Layer), Average read speed (AvgWriteSpeed): 487MB / s, Average write ... vgReadSpeed): No data (--), Total data read (ReadTotal): No data (--), Average write speed (AvgWriteSpeed): 51MB / s (marked as bottleneck), Total data written (WriteTotal): 9.8GB}, {WARN: A performance bottleneck was detected at the network transport layer. The average write speed (AvgWriteSpeed) of 51MB / s is much lower than the average read speed (AvgReadSpeed) of 487MB / s. It is recommended to check the network bandwidth between the agent node (Agent) and the storage backend (Storaged), or to investigate the write performance of the storage backend (Storaged)}.

[0097] In this embodiment, the server uses an adaptive mechanism to maintain a low log frequency when the speed is stable (reducing log storage overhead) and automatically increase the sampling density when the speed is abnormal (without missing key fluctuation details), thus balancing the amount of logs and the accuracy of diagnosis.

[0098] In one exemplary embodiment, such as Figure 6 As shown, Figure 6This is a flowchart illustrating the performance testing method for backup and recovery data links in another embodiment. This embodiment includes the following structure: a speed monitoring core component (Speed_Monitor): an IO speed statistics module that can be embedded into any IO processing location on the data link; a scoped timer recorder (Scoped_Speed_Recorder): an auxiliary component that uses the RAII mechanism to automatically time and count bytes for a single IO operation; and a Client IO (client transmission) layer speed test wrapper (Speed_Test_IO), i.e., a second speed test wrapper: embedding Speed_Monitor into the Client between the Agent and Stored. IO pipeline; Disk access layer speed test wrapper (Speed_Monitored_Disk_Handle), i.e., the first speed test wrapper: embeds Speed_Monitor into the disk access interface between the Agent and the VM disk; Speed ​​threshold alarm mechanism: when the transmission speed is detected to be continuously lower than the configured threshold, the log alarm level is automatically increased, so that the monitoring system can automatically capture and trigger alarms; Adaptive log interval adjustment mechanism: when a significant fluctuation in speed is detected, the sampling and log output interval is automatically shortened temporarily to capture abnormal details with higher time resolution; Cross-layer speed comparison and automatic bottleneck location module: at the end of the task, the speed data of each IO layer are compared, and a bottleneck analysis summary is automatically output to directly point out the performance bottleneck layer in the transmission link; Task configuration parameter (speed_test_interval): a configuration item used to control whether to enable IO performance diagnosis and the log output baseline period.

[0099] The aforementioned architecture consists of three main layers: the data source layer, the backup agent layer (Agent layer), and the storage layer (Storaged layer). After the task starts, it first reads data from the data source layer. The data source layer supports multiple data sources, including Virtual Machine Disk Development Kit (VM Disk VDDK), Network File System (NFS), and databases. The data is then sent to the agent layer via the read function (read()). Once in the agent layer, the data is first passed to the first speed test wrapper module (Speed_Monitored_Disk_Handle) with speed monitoring. This module integrates the core speed monitoring component (Speed_Monitor) specifically responsible for collecting disk read performance data, corresponding to the first step of the process: disk access layer speed testing. After collecting the disk read performance data, the data flows down to the compression, encryption, and deduplication module for preprocessing. The data will enter the second speed test wrapper (Speed_Test_IO) module, which also carries the core speed monitoring component (Speed_Monitor) for collecting network write performance. This corresponds to the second step of the process, network transport layer speed test. The data from the network speed test module will be output to the storage layer (Storaged layer) through the write function (write()). The storage layer (Storaged layer) includes two types of storage carriers: disk pool and object storage. The speed data collected by the disk speed test module and the network speed test module in the proxy layer will be summarized by dotted lines to the task completion stage. After the entire backup or recovery task is completed, the system will perform cross-layer comparison calculations on the speed indicators collected from the disk access layer and the network transport layer, and finally output a summary of the performance bottleneck analysis of the entire task.

[0100] The current method, which divides the total number of bytes transmitted by the total wallclock time from start to finish after the task is completed to obtain an average speed, has two insurmountable drawbacks:

[0101] First, read and write speeds are mixed together. Backup agents need to read data from the data source and write data to the storage backend; these are two opposing I / O operations with completely different performance impacts. Mixed statistics mean that when this number is low, you can't tell whether the slowdown is due to the read or write side. Second, non-I / O time is included in the denominator. Compression, encryption, deduplication, and hashing operations occur between reading and writing data. These computational times don't belong to any I / O operation but are included in the total time, causing the calculated speed to be systematically lower than the actual throughput of the I / O layer, creating a misleading result.

[0102] For example, suppose the read speed is 500MB / s and the write speed is also 500MB / s, but the compression algorithm is slow, and the backup agent takes 9 seconds to compress every 1GB of data read. Using the current solution, the overall speed is only about 50MB / s. When operations personnel see this number, they are likely to check the disk, network, and stored storage, only to find no problems – because the real bottleneck is in CPU compression processing, not the I / O stage.

[0103] This application implements speed detection through system call boundary marking. Specifically, the scope timer logger records a timestamp at the entry moment of each `read()` or `write()` system call and calculates the time consumed at the exit moment, accumulating only the number of bytes actually completed within that time period. The timing for `read()`, from the start of the call to its return, only involves waiting for the data source response and data being transferred to memory, with no other interference. Similarly, the timing for `write()`, from the start of the call to its return, only involves the time for data to be written to the network buffer (or storage device), also without other interference. Read and write statistics are accumulated separately in independent atomic variables, without interference between them.

[0104] The read speed obtained in this way accurately reflects how quickly the data source can actually deliver data to the backup agent; the write speed reflects how quickly the network and storage backend can actually receive and write data to disk. The two numbers are independent of each other, each corresponding to completely different physical links in the chain.

[0105] In some embodiments, the bottleneck is the network or storage backend. A backup task completes at approximately 50MB / s. The speed monitoring core component output in the logs, viewed by the operations and maintenance personnel, includes: Disk access layer monitoring (hard-disk-1): {Type: Periodic statistics, Read speed: 486MB / s, Read data volume: 9.5GB, Write speed: None, Write data volume: None}; {Type: Cumulative statistics, Read speed: 491MB / s, Read data volume: 38.2GB, Write speed: None, Write data volume: None}. Network transport layer monitoring (storage service address): {Type: Periodic statistics, Read speed: None, Read data volume: None, Write speed: 51MB / s, Write data volume: 1.0GB}; {Type: Cumulative statistics, Read speed: None, Read data volume: None, Write speed: 52MB / s, Write data volume: 8.1GB}.

[0106] As shown above, the VM disk read speed reached 491MB / s, with no abnormalities observed; the write speed to Stored was only 52MB / s, consistent with the overall task speed, indicating that the bottleneck lies in the network transport layer or the write side of the storage backend. Operations personnel can directly check the network bandwidth between the backup agent and the storage backend, or whether the write queue of the storage backend service is fully loaded, without wasting time on VM disk configuration.

[0107] In some embodiments, the data source is taken as the bottleneck. The overall speed of a backup task is approximately 10MB / s. Logs show: Disk access layer monitoring (hard-disk-1): {Type: Periodic statistics, Read speed: 9MB / s, Read data volume: 180MB, Write speed: None, Write data volume: None}; {Type: Cumulative statistics, Read speed: 11MB / s, Read data volume: 3.6GB, Write speed: None, Write data volume: None}. Network transport layer monitoring (storage service address): {Type: Periodic statistics, Read speed: None, Read data volume: None, Write speed: 380MB / s, Write data volume: 70MB}; {Type: Cumulative statistics, Read speed: None, Read data volume: None, Write speed: 390MB / s, Write data volume: 1.3GB}.

[0108] As shown above, the write speed is as high as 390MB / s, indicating that there are no abnormalities in the network and storage backend; while the disk read speed is only 11MB / s. The problem lies on the data source side, and the operation and maintenance personnel can immediately check the following: whether the VDDK transfer mode has degraded to the low-speed Network Block Device (NBD) network mode, whether there is contention for the source storage resources, or whether the ESXi host IO queue where the VM disk is located is busy.

[0109] In some embodiments, assuming that IO itself is not the bottleneck, but the bottleneck lies in the processing stage, the read and write speeds are both high, but the overall task is still slow. The log output is as follows: Disk access layer speed monitoring: {Type: Cumulative statistics, Read speed: 480MB / s, Read data volume: 40.0GB, Write speed: None, Write data volume: None}. Network transmission layer speed monitoring: {Type: Cumulative statistics, Read speed: None, Read data volume: None, Write speed: 460MB / s, Write data volume: 38.8GB}. Both read and write speeds are close to 500MB / s, and there are no anomalies in the IO layer, but the overall task time is still relatively long. Combining the cumulative data volume of the two layers (40GB read, 38.8GB written, compression ratio approximately 0.97, close to 1:1), it can be inferred that the CPU resources of the backup agent are insufficient (compression / encryption / deduplication consume too much), rather than the IO bottleneck. This conclusion comes from independent statistics of read and write speeds. It is precisely because of independent and accurate IO layer speeds that the IO problem can be quickly confirmed through the process of elimination, and attention can be turned to the CPU.

[0110] Specifically,

[0111] This refers to the Speed_Test_IO wrapper (second speed test wrapper) for the network transport layer (Client IO). The second speed test wrapper uses the decorator pattern, inheriting from Pipe_IO (the base class for piped IO). The server uses an already created Client_IO_Base object as the wrapped inner IO object. Its workflow is as follows: Assembly: When the backup task is configured with speed_test_interval > 0 (enabling task configuration parameters), during the network transport layer connection establishment process (connect()), a Speed_Test_IO instance (the second speed test wrapper) is appended to the outermost layer of the IO processing pipeline (which may already include compression, encryption, etc.). Because it uses the decorator pattern, Speed_Test_IO is completely transparent to the implementation type of the inner IO layer; the inner layer can be wrapped without modification.

[0112] During the open phase: When Speed_Test_IO calls open() (the resource opening function), it stops and resets the speed monitoring core component (clearing any residual statistics from the previous operation), calls the inner IO's open() function, and upon success, initializes and starts the speed monitoring core component with the current path as the context name, while also starting the log thread.

[0113] During the read / write (data transfer) phase: For each read() or write() call, the server creates a scoped timer logger (specifying the read / write direction) through Speed_Test_IO (the second speed test wrapper), calls the inner IO to perform the actual transfer, and records the number of bytes transferred this time through set_bytes() (the byte setting function). When the scoped timer logger is destructed, the time and number of bytes are automatically submitted to the speed monitoring core component.

[0114] During the close phase: Speed_Test_IO stops the speed monitoring core component when it closes() (the resource close function), and the logging thread outputs the final statistics before exiting.

[0115] The first speed test wrapper is for the disk access layer. For data sources that cannot use a unified network transport layer (Client IO) path (such as VMware virtual machine disks accessed through the Virtual Disk Development Kit (VDDK) Application Programming Interface (API) or the Network File System RESTful interface), the server can implement a corresponding speed test wrapper (Speed_Monitored_Disk_Handle) at the disk access interface layer; this is the first speed test wrapper. The Virtual Disk Development Kit, provided by VMware, allows third-party programs to directly access the virtual disk data of VMware virtual machines and is the core technology interface for VMware backup.

[0116] Specifically, Speed_Monitored_Disk_Handle wraps an implementation of the Disk_Handle interface (disk handle interface) (which can be a VDDK handle or a RESTful disk handle). During construction, it initializes and starts the speed monitoring core component (with the disk name as the context identifier). During each read() / write() call, it uses a scoped timer to perform precise timing. During destruction, the speed monitoring core component automatically stops and outputs the final statistics.

[0117] In VMware's backup and recovery process, when IO speed testing is enabled in the task configuration, after opening each virtual disk (after the VDDK handle is created), the server wraps the original handle into a Speed_Monitored_Disk_Handle. All subsequent read and write operations on this disk go through the speed testing layer, and the upper-level calling code for disk access does not need to be aware of the existence of this wrapping.

[0118] The server implements tiered diagnostic capabilities through a speed test wrapper. Specifically, the server integrates speed test components (speed test wrappers) at both the network transport layer (Client IO) (backup agent, storage backend network transmission) and the disk access layer (backup agent reading data sources). The system logs simultaneously display two types of speed data: data source read speed (first data transfer speed): reflecting the speed at which the backup agent reads raw data from the VM disk or database, affected by source storage performance and VDDK transmission mode (SAN / HotAdd / NBD, etc.); and data write speed (second data transfer speed / network transmission speed): reflecting the speed at which the backup agent writes processed data to the storage backend over the network, affected by network bandwidth, storage backend write performance, compression ratio, etc.

[0119] By comparing the speed data from these two layers, the server can quickly determine the source of the overall slowness: if the read speed is high but the write speed is low, the bottleneck is in the network or storage backend; if the read speed is inherently low, the bottleneck is in the data source or the transmission protocol layer.

[0120] The aforementioned speed test wrapper also includes an extensible monitoring framework. The server designs the core speed monitoring components (Speed_Monitor and Scoped_Speed_Recorder) as general-purpose, reusable modules independent of specific IO protocols (encapsulated in a separate scrt public library). Any new data source or new transport protocol requiring IO performance monitoring can achieve the same speed test capabilities simply by using Scoped_Speed_Recorder to record data at its IO read / write interface call and introducing Speed_Monitor to manage statistics and logs, without needing to repeatedly implement the monitoring logic.

[0121] In some embodiments, optional enabling and configuration are also included. The IO performance diagnostic function is controlled by the task configuration parameter `speed_test_interval` (whether to determine the first data transfer rate / second data transfer rate): a value of 0 (default) disables IO speed testing; the relevant wrapper layer exists but runs idle, having no performance impact on the IO path; a value greater than 0 enables IO speed testing, and the value of `speed_test_interval` is the log output time interval (in seconds). A more frequent (e.g., 5 seconds) or sparser (e.g., 60 seconds) log output frequency can be selected as needed. This ensures that when diagnostics are not needed, the function has zero performance overhead (no thread creation, no atomic operation accumulation), and does not affect the efficiency of normal backup tasks.

[0122] The server can be configured with a speed threshold alarm mechanism. The server configures a minimum speed threshold (min_speed_threshold) through the speed monitoring core component, such as the first and second speed thresholds mentioned above. At the start of each log cycle (data transmission cycle), the server compares the current periodic speed with this threshold and maintains a continuous low-speed counter: if the read or write speed of the current cycle is lower than the threshold, the counter increments; if the speed recovers above the threshold, the counter is reset to zero; when the counter accumulates to more than the configurable number of consecutive triggers (first low-speed count / second low-speed count, alert_consecutive_count), the server raises the log level of the subsequent task from INFO (feedback) to WARNING (fixable problem) or ERROR (system error).

[0123] After raising the log level, any operational alerting system connected to the backup system's log stream (such as log alerts from Elasticsearch, Logstash, Kibana (ELK), Zabbix log monitoring, etc.) can automatically capture and trigger alert notifications, eliminating the need for continuous manual log monitoring and achieving a shift from passive discovery to proactive alerting. The alert logs include: current speed, configured threshold, duration of continuous low speed, and task context name, enabling operations personnel to obtain a complete diagnostic context upon receiving the alert.

[0124] The server can be configured to adjust the adaptive log interval. Specifically, the server maintains a sliding window through its speed monitoring core component, recording periodic speed data (read and write speeds) for several recent log cycles. After each log output, the deviation ratio between the current cycle speed (first data transfer speed / second data transfer speed) and the historical average within the window (target data transfer speed) is calculated.

[0125] If the deviation exceeds the configurable threshold (preset difference threshold, such as 50% of the average), the server determines it as an abnormal speed fluctuation and temporarily shortens the log output interval (detection frequency) from the baseline value (speed_test_interval) to the encrypted mode interval (such as shortening it to one-fifth of the baseline value) to capture fluctuation details with higher time resolution. If the speed stabilizes again within several consecutive encrypted sampling periods (the deviation returns to within the preset difference threshold), the server automatically restores the log interval to the baseline value to avoid generating too many logs during normal operation.

[0126] Within the same backup task, each instance of the speed monitoring core component for each IO layer (disk access layer, network transmission layer, etc.) reports its cumulative statistics (total bytes, total IO time, average speed) to the task-level speed aggregation module at the end of the task. This module outputs a bottleneck analysis summary in the task completion log, including: the average read / write speed and cumulative transfer volume of each layer; marking the layer with the lowest speed (i.e., the current task's transmission bottleneck layer); if the speed of a certain layer is significantly lower than other layers (e.g., lower than a certain percentage of the highest layer's speed), additional text descriptions are provided indicating that this layer may be the root cause of the task's slowness.

[0127] For example, if the disk access layer read speed reaches 500MB / s, but the network transport layer write speed is only 50MB / s, the summary will directly indicate that the bottleneck is in the network transport layer, and suggest checking network bandwidth or stored write performance. The log can specifically include: {Overall task summary, Task name (Task): backup-job, Duration (Duration): 00:32:17}, {Statistics type: Disk Access (DiskAccess(VDDK)), Average read speed (AvgReadSpeed): 487MB / s, Total read data (ReadTotal): 94.3GB, Average write speed (AvgWriteSpeed): No data (--), Total write data (WriteTotal): No data (--)}, {Statistics type: Network Transport Layer (NetworkTransfer(HBR)) (Network Transport Layer), Average read speed (AvgWriteSpeed): 487MB / s, Total write speed (AvgWriteSpeed): 94.3GB, Average write speed (AvgWriteSpeed): No data (--), Total write data (WriteTotal): No data (--)}, {Statistics type: Network Transport Layer (NetworkTransfer(HBR)) (Network Transport Layer), Average read speed (AvgWriteSpeed): 487MB / s, Average write ... vgReadSpeed): No data (--), Total Read Data (ReadTotal): No data (--), Average Write Speed ​​(AvgWriteSpeed): 51MB / s (marked as bottleneck), Total Write Data (WriteTotal): 9.8GB}, {WARN: A performance bottleneck was detected at the network transport layer. The average write speed (AvgWriteSpeed) of 51MB / s is significantly lower than the average read speed (AvgReadSpeed) of 487MB / s. It is recommended to check the network bandwidth between the agent node and the storage backend, or investigate the write performance of the storage backend}. Therefore, a direct diagnostic conclusion can be obtained upon task completion without manually comparing multiple sets of log data.

[0128] Through the above embodiments, the server improves the accuracy of performance testing by setting speed test wrappers at the adjacent positions of disk read / write logical objects and at the outermost layer of the network transport layer, respectively, and by detecting the data transmission speed through each speed test wrapper. Based on the data transmission speed, the performance test result of the backup and recovery data link is determined.

[0129] It also achieved the following technical effects:

[0130] Read and write speeds are independently visible, making bottlenecks readily apparent. By timing each read() and write() system call independently, the true throughput of read and write operations is determined separately, overcoming the limitation of overall numbers failing to provide clear information. No external tools are needed; the bottleneck can be determined directly from the task logs: fast reads and slow writes indicate a bottleneck in the network or storage backend; slow reads and fast writes indicate a bottleneck in the data source; and fast reads and fast writes indicate a bottleneck outside the I / O layer (introduce investigations into CPU or memory). This reduces troubleshooting time.

[0131] By excluding non-IO time consumption, the speed data is accurate and reliable. System call boundary markers only count the time consumed by the read() / write() calls themselves; the time spent on intermediate steps such as compression calculations, encryption processing, and deduplication hashing is completely excluded from the speed metrics. This ensures that read and write speed data accurately reflects the true throughput capacity of the corresponding IO layer, unaffected by the processing capabilities of backup proxy programs, and avoids the distortion problem of systematically underestimating IO performance due to the inclusion of processing time.

[0132] Real-time visibility. Through continuous output from periodic log threads, operations personnel can view the current read / write speed at any time during task execution without waiting for the task to complete. This transforms post-event analysis into real-time awareness, shortening the time to discover slow-moving issues.

[0133] The system simultaneously displays both interim and cumulative speeds. The server outputs both interim and cumulative speeds (reflecting the current real-time status) and cumulative speeds (reflecting the overall performance of the entire task), allowing operations personnel to identify intermittent performance fluctuations as well as grasp the overall performance level; the two complement each other.

[0134] Task context binding. Speed ​​data appears directly in the backup task's own runtime log, and the data is accurately identified by context name (task ID, backup path, disk name, etc.), which solves the problem that external monitoring tools cannot associate IO data with specific tasks, and is especially important in multi-task concurrent scenarios.

[0135] Non-intrusive, zero-cost architectural compatibility. The server utilizes the decorator pattern to ensure that the speed test function does not alter the original I / O interfaces and logic. It incurs zero performance overhead for tasks where speed testing is not enabled, and takes effect without modification to existing I / O backends. This reduces the technical risks of introducing new features and provides excellent maintainability and scalability.

[0136] Layered diagnostics pinpoints bottlenecks precisely. By independently measuring the speed of servers at multiple key levels of the data transmission link, operations and maintenance personnel can quickly distinguish different root causes such as slow source reads, slow network transmissions, and slow backend writes. This simplifies the complex diagnostic process that originally required cross-comparison using multiple tools to directly compare speed data at different levels in the same task log.

[0137] From passive discovery to proactive alerting. The server uses a speed threshold alerting mechanism to automatically issue high-priority logs when the transmission speed is consistently abnormal. The operations and maintenance alerting platform can directly subscribe to and push notifications, eliminating the need for operations and maintenance personnel to continuously monitor the logs. This upgrades the problem discovery mode from manual polling to proactive system push, significantly shortening the time window from problem occurrence to operations and maintenance response.

[0138] Automatic balance between diagnostic accuracy and log overhead. The server uses an adaptive log interval adjustment mechanism to maintain a low log output frequency when the speed is stable, reducing log storage and IO overhead; when abnormal speed fluctuations occur, it automatically increases the sampling density to ensure that data in critical anomaly phases is not masked by sparse sampling, thus balancing long-term resource efficiency with diagnostic accuracy in anomaly scenarios.

[0139] Structured diagnostic conclusions are obtained upon task completion. The server, through cross-layer speed comparison and automatic bottleneck location mechanisms, outputs summary logs containing speed comparisons and bottleneck annotations for each layer upon task completion. This allows operations personnel to obtain structured diagnostic conclusions at the same moment the task is completed, rather than having to infer from large amounts of raw data, thus shortening diagnostic time.

[0140] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0141] Based on the same inventive concept, this application also provides a backup and recovery data link performance testing device for implementing the backup and recovery data link performance testing method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more backup and recovery data link performance testing device embodiments provided below can be found in the limitations of the backup and recovery data link performance testing method described above, and will not be repeated here.

[0142] In one exemplary embodiment, such as Figure 7 As shown, a performance testing device for backup and recovery data links is provided, comprising: a first testing module 500, a second testing module 502, and a determination module 504, wherein:

[0143] The first detection module 500 is used to detect the first data transmission speed corresponding to the disk access layer by using a first speed test wrapper when the disk access layer meets the first performance detection condition. The first speed test wrapper is arranged adjacent to the disk read / write logical object of the disk access layer. The disk read / write logical object represents the object that implements the data transmission function of the disk access layer. The disk access layer is used to transmit data to the network transport layer through backup and recovery of the data link.

[0144] The second detection module 502 is used to detect the second data transmission speed corresponding to the network transmission layer by means of the second speed test wrapper when the network transmission layer meets the second performance detection conditions; the second speed test wrapper is set on the outermost layer of the network transmission layer; the network transmission layer is used to store the data transmitted by the disk access layer through the backup recovery data link.

[0145] The determination module 504 is used to determine the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed.

[0146] In one embodiment, the above apparatus further includes: a first setting module, configured to obtain the original first speed test wrapper and disk handle interface corresponding to the disk access layer; the disk handle interface is used to determine the disk read / write logical object; and the disk handle interface is wrapped by the original first speed test wrapper to obtain the first speed test wrapper.

[0147] In one embodiment, the first detection module 500 is configured to, when detecting a first data transfer function for the disk access layer, determine a first data transfer time using the first speed test wrapper and detect a first data transfer amount corresponding to the first data transfer function; and determine a first data transfer speed corresponding to the disk access layer based on the first data transfer time and the first data transfer amount.

[0148] In one embodiment, the apparatus further includes: a second setting module, configured to, when the network transport layer establishes the backup recovery data link, generate an original second speed test wrapper at the outermost layer of the network transport layer using a decorator pattern; and determine the second speed test wrapper based on the resource opening function of the network transport layer and the original second speed test wrapper.

[0149] In one embodiment, the second detection module 502 is configured to, when detecting a data transmission request for the network transport layer, call the second data transmission function of the network transport layer through the second speed test wrapper to perform data transmission; determine the second data transmission time and the second data transmission amount corresponding to the second data transmission function through the second speed test wrapper; and determine the second data transmission speed corresponding to the network transport layer based on the second data transmission time and the second data transmission amount.

[0150] In one embodiment, the determining module 504 is configured to acquire a first low-speed count and a second low-speed count in multiple data transmission cycles, respectively; the first low-speed count represents the number of times the first data transmission speed is continuously less than a first speed threshold in the multiple data transmission cycles; the second low-speed count represents the number of times the second data transmission speed is continuously less than a second speed threshold in the multiple data transmission cycles; if the first low-speed count and / or the second low-speed count are greater than a preset count threshold, the performance detection result of the backup and recovery data link is determined to be abnormal, and corresponding alarm information is generated based on the first low-speed count and / or the second low-speed count.

[0151] In one embodiment, the apparatus further includes: an adjustment module, configured to increase the detection frequency of the first data transmission speed and / or the second data transmission speed if the difference between the first data transmission speed and / or the second data transmission speed and the target data transmission speed is greater than a preset difference threshold; the target data transmission speed represents the average of each first data transmission speed and / or the average of each second data transmission speed within a target window; the target window is generated based on the detection cycle of the first data transmission speed and / or the second data transmission speed.

[0152] Each module in the aforementioned performance testing device for backup and recovery data links 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, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0153] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores backup data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a performance testing method for a backup and recovery data link.

[0154] Those skilled in the art will understand that Figure 8 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.

[0155] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the performance testing method for the backup and recovery data link described above.

[0156] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the performance testing method for the backup and recovery data link described above.

[0157] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the performance testing method for the backup and recovery data link described above.

[0158] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0159] Those skilled in the art will understand that all or part of the processes in the methods of the above 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, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0160] 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 application.

[0161] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. 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 application should be determined by the appended claims.

Claims

1. A method for detecting performance of a backup-recovery data link, characterized by, The method includes: When the disk access layer is detected to meet the first performance detection condition, the first data transfer speed corresponding to the disk access layer is detected by the first speed test wrapper; the first speed test wrapper is set adjacent to the disk read / write logical object of the disk access layer; the disk read / write logical object represents the object that implements the data transfer function of the disk access layer; the disk access layer is used to transmit data to the network transport layer through backup and recovery data link. When the network transport layer is detected to meet the second performance detection condition, the second data transmission speed corresponding to the network transport layer is detected by the second speed test wrapper; the second speed test wrapper is set on the outermost layer of the network transport layer; the network transport layer is used to store the data transmitted by the disk access layer through the backup recovery data link. The performance test result of the backup and recovery data link is determined based on the first data transmission speed and the second data transmission speed.

2. The method of claim 1, wherein, The method further includes: Obtain the original first speed test wrapper and disk handle interface corresponding to the disk access layer; the disk handle interface is used to determine the disk read / write logic object; The disk handle interface is packaged using the original first speed test wrapper to obtain the first speed test wrapper.

3. The method of claim 1, wherein, The step of detecting the first data transfer speed corresponding to the disk access layer through the first speed measurement wrapper includes: When a first data transfer function for the disk access layer is detected, the first data transfer time is determined by the first speed measurement wrapper, and the first data transfer amount corresponding to the first data transfer function is detected. Based on the first data transmission time and the first data transmission amount, the first data transmission speed corresponding to the disk access layer is determined.

4. The method of claim 1, wherein, The method further includes: When the network transport layer detects that the backup recovery data link has been established, the original second speed test wrapper is generated on the outermost layer of the network transport layer using the decorator pattern. The second speed test wrapper is determined based on the resource opening function of the network transport layer and the original second speed test wrapper.

5. The method of claim 1, wherein, The step of detecting the second data transmission speed corresponding to the network transport layer through the second speed measurement package includes: When a data transmission request for the network transport layer is detected, the second data transmission function of the network transport layer is invoked through the second speed measurement wrapper to perform data transmission. The second data transmission time and the second data transmission amount corresponding to the second data transmission function are determined by the second speed measuring packaging device; The second data transmission speed corresponding to the network transport layer is determined based on the second data transmission time and the second data transmission amount.

6. The method according to claim 1, characterized in that, The step of determining the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed includes: In multiple data transmission cycles, a first low-speed count and a second low-speed count are obtained respectively; the first low-speed count represents the number of times the first data transmission speed is continuously less than a first speed threshold in the multiple data transmission cycles; the second low-speed count represents the number of times the second data transmission speed is continuously less than a second speed threshold in the multiple data transmission cycles. If the first low-speed count and / or the second low-speed count are greater than a preset threshold, the performance test result of the backup and recovery data link is determined to be abnormal, and corresponding alarm information is generated based on the first low-speed count and / or the second low-speed count.

7. The method according to any one of claims 1 to 6, characterized in that, After determining the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed, the method further includes: If the difference between the first data transmission speed and / or the second data transmission speed and the target data transmission speed is greater than a preset difference threshold, then the detection frequency of the first data transmission speed and / or the second data transmission speed is increased. The target data transmission speed represents the average of each first data transmission speed and / or the average of each second data transmission speed within the target window; the target window is generated based on the detection period of the first data transmission speed and / or the second data transmission speed.

8. A performance testing device for backup and recovery data links, characterized in that, The device includes: The first detection module is used to detect the first data transmission speed corresponding to the disk access layer by a first speed test wrapper when the disk access layer meets the first performance detection condition. The first speed test wrapper is arranged adjacent to the disk read / write logical object of the disk access layer. The disk read / write logical object represents the object that implements the data transmission function of the disk access layer. The disk access layer is used to transmit data to the network transport layer through backup and recovery of the data link. The second detection module is used to detect the second data transmission speed corresponding to the network transport layer by using a second speed test wrapper when the network transport layer meets the second performance detection condition; the second speed test wrapper is set on the outermost layer of the network transport layer; the network transport layer is used to store the data transmitted by the disk access layer through the backup recovery data link. The determination module is used to determine the performance test result of the backup and recovery data link based on the first data transmission speed and the second data transmission speed.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. 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 steps of the method according to any one of claims 1 to 7.

Images