Disk I / O performance test method, device, equipment and storage medium

Abstract

The application discloses a kind of magnetic disk I / O performance test method, device, equipment and storage medium, is related to magnetic disk performance test technical field, comprising: response user's test instruction and configure initial test parameter is tested before the test disk and carries out test front inspection;According to test instruction and inspection result, determine test mode and test parameter;The I / O read-write test of the disk to be tested is executed, and the test start and end time stamp is obtained by calling multi-level high-precision time interface;In adaptive mode, the average performance index is calculated using the iteration round, and the performance ratio is obtained by comparing with the target ratio.

Description

Technical Field

[0001] This invention relates to the field of disk performance testing technology, and in particular to a disk I / O performance testing method, apparatus, device, and storage medium. Background Technology

[0002] With the rapid development of information technology, storage devices such as hard disks have become core components of computer systems, and their I / O (Input / Output) performance directly affects the overall operational efficiency of applications such as big data, cloud computing, and artificial intelligence. Accurately and comprehensively evaluating the performance of storage devices has become an important issue for management and development personnel.

[0003] Traditional disk performance testing tools, such as dd, fio, and commercial / open-source testing tools, are relatively fragmented, making it difficult to balance functionality, configuration complexity, cost, and adaptability, and lacking intuitive result presentation methods. Furthermore, with the development of emerging technologies such as containerization, cloud-native computing, edge computing, and the Internet of Things, traditional testing tools face even greater challenges in new scenarios such as resource constraints, network instability, and distributed storage. Especially when dealing with testing tasks of varying scale and complexity, a single testing tool cannot meet the needs of comprehensive performance evaluation of modern storage systems, and setting fixed timeout rules can easily lead to test failures or wasted resources. Summary of the Invention

[0004] This invention provides a disk I / O performance testing method, apparatus, device, and storage medium to solve the technical problem that the unreasonable configuration of traditional testing tools makes it difficult to adapt to testing tasks of different scales and complexities.

[0005] In a first aspect, embodiments of the present invention provide a disk I / O performance testing method, including: S101, responding to the user's test mode selection command and configuring the corresponding initial test parameters, performs a pre-test check on the disk to be tested and generates test check results; S102, determine the test mode to be executed based on the test mode selection instruction and test check results, dynamically adjust the corresponding test parameters, and generate the target test parameter configuration; S103, according to the target test parameters, execute the corresponding I / O read and write test on the disk to be tested, and during the test, call the multi-level high-precision time interface to obtain the test start and end timestamps, and calculate the benchmark performance data of the current iteration round in combination with the corresponding test transmission data volume; S104. If the current test mode is adaptive mode, extract the baseline performance data of the previously completed iteration rounds to calculate the average performance index, compare it with the preset target performance index to obtain the current performance ratio, and then compare it with the preset performance ratio to dynamically adjust the test timeout duration of the next iteration round, and execute the next iteration round until the preset total number of iterations is reached. S105. After all iteration rounds are completed, the baseline performance data of each iteration round is averaged and statistically analyzed over multiple rounds to generate a comprehensive performance index test report.

[0006] Secondly, embodiments of the present invention provide a disk I / O performance testing apparatus, comprising: The test preparation module is used to respond to the user's test mode selection command and configure the corresponding initial test parameters, and to perform pre-test checks on the disk to be tested to generate test check results. The parameter configuration module is used to determine the test mode to be executed based on the test mode selection instructions and test check results, and dynamically adjust the corresponding test parameters to generate the target test parameter configuration. The test execution module is used to perform corresponding I / O read and write tests on the disk to be tested according to the target test parameters, and during the test, it calls the multi-level high-precision time interface to obtain the test start and end timestamps, and calculates the benchmark performance data of the current iteration round in combination with the corresponding test transmission data volume; The adaptive testing module is used to extract the baseline performance data of the previously completed iterations to calculate the average performance index when the current testing mode is adaptive. It then compares the average performance index with the preset target performance index to obtain the current performance ratio, and compares the current performance ratio with the preset performance ratio to dynamically adjust the test timeout duration of the next iteration. The next iteration is then executed until the preset total number of iterations is reached. The report generation module is used to perform multi-round averaging statistics on the benchmark performance data of each iteration after all iteration rounds are completed, and generate a comprehensive performance index test report.

[0007] Thirdly, embodiments of the present invention provide an electronic device, including: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the disk I / O performance testing method described above.

[0008] Fourthly, embodiments of the present invention provide a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the aforementioned disk I / O performance testing method.

[0009] This invention provides a disk I / O performance testing method, apparatus, device, and storage medium. The method dynamically generates target test parameter configurations by responding to user commands and configuring initial test parameters, combined with pre-test disk and dependent tool environment checks. During various I / O read / write tests, it calls multi-level high-precision time interfaces to obtain start and end timestamps and calculates baseline performance data. By extracting the average performance metrics from historical iterations and comparing them with target metrics in adaptive mode, it dynamically adjusts the test timeout duration for the next round, and performs multi-round average statistics to generate a comprehensive report after all iterations are completed. By dynamically generating target configurations in conjunction with environment checks, test interruptions caused by hardware and software environments are avoided, improving the test success rate. The introduction of high-precision time interfaces effectively reduces errors when dealing with high-speed solid-state drives, improving the accuracy of raw performance data. The dynamic timeout adjustment mechanism in adaptive mode and multi-round average statistics avoid the time waste or insufficient data samples caused by traditional fixed timeouts, effectively improving test efficiency, adapting to different performance disk tests, and avoiding erroneous adjustments due to single performance fluctuations, thus improving the test success rate and enhancing the confidence of the comprehensive test report. Attached Figure Description

[0010] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a flowchart of a disk I / O performance testing method according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of a disk I / O performance testing method according to Embodiment 2 of the present invention; Figure 3 This is a flowchart of a disk I / O performance testing method according to Embodiment 3 of the present invention; Figure 4 This is a schematic diagram of the structure of a disk I / O performance testing device according to Embodiment 4 of the present invention; Figure 5 This is a structural diagram of the electronic device described in Embodiment 5 of the present invention. Detailed Implementation

[0011] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0012] Example 1 Figure 1This is a flowchart of a disk I / O performance testing method according to Embodiment 1 of the present invention. By introducing adaptive parameter adjustment for different test modes, a dynamic timeout adjustment mechanism, and high-precision time measurement test data, adaptive performance testing with precise quantification of test results is performed on different disks. Specifically, it includes the following steps: S101 responds to the user's test mode selection command and configures the corresponding initial test parameters, performs a pre-test check on the disk to be tested, and generates test check results.

[0013] Users can initiate disk performance tests via command line (CLI), graphical user interface (GUI) interaction, or configuration file (script) execution. Responding to user-inputted test mode selection commands, the system parses the test modes specified in the commands, including normal mode, stress mode, stability mode, and adaptive mode. It then configures the corresponding initial test parameters, such as file size, block size, and test duration, according to preset rules for each test mode specified in the command. To ensure successful testing, a pre-test check is performed on the disk to be tested, including checking the disk environment (e.g., remaining disk space), whether the tools required for the test are installed or available, and the current status of available system resources. If the check fails, a test check result containing error information is generated, and the process terminates to avoid invalid tests due to environmental issues, thereby improving the success rate and efficiency of the test.

[0014] S102: Based on the test mode selection instruction and test check results, determine the test mode to be executed and dynamically adjust the corresponding test parameters to generate the target test parameter configuration.

[0015] After the pre-test check is passed, the initial test parameters are dynamically adjusted based on the parsed test mode and the hardware resource availability from the pre-test check results. Different test intensities and durations are adapted to different test modes to generate target test parameter configurations. For example, if the user selects stress mode, the number of concurrent threads can be increased, the test file size can be increased, or the test duration can be extended to apply a greater load to the disk; if the system is found to support NUMA architecture, the process binding strategy can be optimized to reduce cross-node access latency. This ensures that the test parameters can adaptively adapt to the current test requirements and hardware environment, guaranteeing the rationality of the test parameters.

[0016] S103, according to the target test parameters, execute the corresponding I / O read and write tests on the disk to be tested, and during the test, call the multi-level high-precision time interface to obtain the test start and end timestamps, and calculate the benchmark performance data of the current iteration round in combination with the corresponding test transmission data volume.

[0017] Based on the generated target test parameter configuration, the system begins executing disk I / O read / write tests. These tests include sequential write, sequential read, random write, random read, and mixed read / write modes to comprehensively evaluate disk performance. During test execution, to avoid insufficient measurement accuracy, the system obtains test start and end timestamps by calling its multi-level high-precision time interface. For example, this interface first attempts to call the operating system's nanosecond-level time interface; if unsupported, the precision is progressively reduced until a second-level time interface is called. This multi-level fallback mechanism ensures that the highest possible accuracy in time statistics can be obtained across different operating systems. This allows for the calculation of test duration, and combined with the amount of data transferred during the test, the baseline performance data for the current test iteration can be accurately calculated, such as bandwidth and read / write operations per second (IOPS). This is particularly effective on high-speed storage disks (such as NVMe SSDs) in reducing performance evaluation bias caused by time measurement errors.

[0018] S104. If the current test mode is adaptive mode, extract the baseline performance data of the previously completed iteration rounds to calculate the average performance index, compare it with the preset target performance index to obtain the current performance ratio, and then compare it with the preset performance ratio to dynamically adjust the test timeout duration of the next iteration round, and execute the next iteration until the preset total number of iterations is reached.

[0019] When the user selects adaptive test mode based on their test mode selection command, fixed-duration tests are no longer performed. Instead, a dynamic timeout adjustment mechanism is introduced. After each iteration, the baseline performance data from all previous iterations is extracted and its average value is calculated as the average performance metric. This average performance metric is then compared to a preset target performance metric to calculate the current performance ratio. This ratio is then compared to the preset performance ratio to reflect the difference between the current performance and the expected target. Based on whether the performance ratio exceeds the upper or lower limits of the preset performance ratio, the test timeout for the next iteration is dynamically adjusted, such as doubling or halving it to obtain more stable test data. Extreme values ​​for the test timeout are also set, such as 30 to 300 seconds, to avoid extreme testing. This dynamic adjustment based on performance feedback better adapts to disks with different performance levels, avoiding test timeouts that lead to failure and unnecessary waiting time, thus improving test efficiency. The dynamically adjusted test timeout is used in the next iteration, and so on, until the preset total number of iterations is reached, ensuring the statistical reliability of the test results. For example, the dynamic timeout adjustment mechanism is initiated through the `adaptive_rand_write_test()` function. In this case, the initial test parameters for adaptive mode are configured as follows: `current_duration=$DURATION` # Initial test duration (e.g., 60 seconds); `min_duration=30` Minimum duration; `max_duration=300` Maximum duration; `target_iops=1000` Target IOPS value; `total_iops`: Records the cumulative IOPS value of all successful tests; `successful_iterations`: Records how many tests completed successfully. If an iteration fails (e.g., due to a disk error), it will not affect the calculation of the final average, because failed iterations are not counted in `successful_iterations`. After each iteration, the duration of the next test is dynamically adjusted based on the current performance. First, the current average IOPS is calculated: avg_iops = total_iops / successful_iterations. Then, the ratio of the target to the actual IOPS is calculated: ratio = target_iops / avg_iops. The duration is then adjusted based on this ratio: if ratio > 1.5 (actual performance is too low), the duration is multiplied by 2; if ratio < 0.5 (actual performance is too high), the duration is divided by 2; otherwise, it remains unchanged. A limit of 30s ≤ duration ≤ 300s is set. This increases test time when performance is low to obtain more stable performance data, and reduces test time when performance is high to improve testing efficiency. Boundary limits prevent test times from being too short (inaccurate data) or too long (wasted time).This adaptive mechanism allows the test to automatically adjust according to the actual disk performance, ensuring both the accuracy of the test results and optimizing test efficiency.

[0020] S105. After all iteration rounds are completed, the baseline performance data of each iteration round is averaged and statistically analyzed over multiple rounds to generate a comprehensive performance index test report.

[0021] Once all iterations are complete, baseline performance data from each iteration is collected. To eliminate potential random errors from a single test, a multi-iteration averaging algorithm is used. By executing the same I / O test multiple times, the results of each test are summed and the arithmetic mean is calculated to obtain more stable and accurate performance test results, forming a comprehensive performance indicator test report. The report includes the final test results, test parameter configurations, anomalies during the test, test latency statistics, etc., for user reference and analysis, enabling users to fully understand the disk's performance under various load scenarios.

[0022] This embodiment dynamically generates target test parameter configurations by responding to user commands and configuring initial test parameters, combined with pre-test disk and dependent tool environment checks. During various I / O read / write tests, it calls multi-level high-precision time interfaces to obtain start and end timestamps and calculate benchmark performance data. By extracting the average performance metrics from historical iterations and comparing them with the target metrics in adaptive mode, it dynamically adjusts the test timeout duration for the next round, and performs multi-round average statistics to generate a comprehensive report after all iterations are completed. By dynamically generating target configurations in conjunction with environment checks, it avoids test interruptions caused by hardware and software environments, thus improving the test success rate. By introducing high-precision time interfaces, it effectively reduces errors and improves the accuracy of raw performance data when dealing with high-speed solid-state drives. Through the dynamic timeout adjustment mechanism and multi-round average statistics in adaptive mode, it avoids the time waste or insufficient data samples caused by traditional fixed timeouts, effectively improving test efficiency, adapting to tests of disks with different performance levels, and avoiding erroneous adjustments caused by single performance fluctuations, thereby improving the test success rate and enhancing the confidence of the comprehensive test report.

[0023] Example 2 Figure 2 This is a flowchart of a disk I / O performance testing method according to Embodiment 2 of the present invention. This embodiment is based on the above embodiment and optimized. In this embodiment, S103 is specifically optimized as follows: Based on the target test parameter configuration, sequential write, sequential read, random write, random read, and mixed read / write tests are performed on the disk to be tested in sequence. During test execution, the operating system's nanosecond-level time interface is called to obtain the nanosecond-level test start and end timestamps; If the current operating system does not support nanosecond-level time interfaces, then the microsecond-level time interface will be triggered to obtain microsecond-level test start and end timestamps. If the current operating system does not support the microsecond-level time interface, then further downgrade to trigger the second-level time interface to obtain the second-level test start and end timestamps.

[0024] Accordingly, the disk I / O performance testing method provided in this embodiment specifically includes: S201 responds to the user's test mode selection command and configures the corresponding initial test parameters, performs a pre-test check on the disk to be tested, and generates test check results.

[0025] Specifically, the system receives and parses the user's input test mode selection command to obtain the target test mode and basic test parameters, and configures the initial test parameters. The target test modes include normal mode, stress mode, stability mode, and adaptive mode.

[0026] User-input commands can take the form of command-line arguments, configuration files, or graphical interface signals. The target test mode is determined by parsing and identifying mode identifiers (such as `-m stress` or `--mode normal`) within the command. The normal mode is suitable for routine performance evaluation, using default parameters when initializing, directly employing the parsed basic test parameters. The stress mode is used for high-intensity load testing, increasing the test intensity based on the default parameters. The stability mode is used for long-term runtime testing, increasing the test duration based on the default parameters to verify device reliability. The adaptive mode enables a dynamic timeout adjustment mechanism, intelligently optimizing the test duration. User-input test mode selection commands may also include other test parameters, such as `-s` specifying file size, `-b` specifying block size, `-d` specifying test duration, `-n` specifying the number of threads, `-q` specifying queue depth, `-c` specifying the CPU affinity list, `-N` specifying NUMA nodes, `-D` enabling direct I / O, `-i` specifying the number of iterations, and `-f` specifying the configuration file path. After parsing, these can be combined with default values ​​to form the initial test parameters.

[0027] Perform environment checks and test dependency tool checks on the disk to be tested, and generate test check results.

[0028] To ensure the validity of the test results, an environment check and a test dependency tool check are required on the disk to be tested before testing. The `mkdir -p` command is used to ensure the existence of the test directory. The remaining space on the partition containing the test directory is checked by calling the file system interface (or the `df` command) to determine if it is sufficient to accommodate test files of the preset size. If space is insufficient, an error message is generated and the process terminates to prevent test failure due to disk overload. The dependency tool check verifies whether the critical tools required for the test are installed and executable using system commands. For example, the `command -v` command sequentially checks whether tools such as `dd`, `fio`, `numactl`, `taskset`, `lscpu`, `bc`, and `jq` are executable, and records the existence status of each tool. For instance, sequential read / write tests rely on the `dd` tool, which is usually included with the operating system, while random read / write and mixed read / write tests rely on the `fio` tool. If the `fio` tool is detected as missing, the system will record this exception in the test check results and skip related test items or prompt the user to install it in subsequent processes. The inspection process can also be extended to verify the availability of auxiliary tools such as CPU information acquisition tools and high-precision calculation tools. For example, the total number of CPU cores and NUMA node topology information can be obtained through lscpu, and the validity of user-specified NUMA nodes can be verified through numactl --hardware. This ensures the integrity of the test environment, avoids test interruptions due to environmental defects, and improves the robustness of the test process.

[0029] S202 determines the test mode to be executed based on the test mode selection instruction and test check results, dynamically adjusts the corresponding test parameters, and generates the target test parameter configuration.

[0030] An optional implementation of this embodiment is to extract the hardware resource topology status from the test and inspection results to obtain CPU core distribution information and NUMA node topology information.

[0031] The hardware resource topology status can be extracted from the test results obtained from environment checks and test dependency tool checks. This can be achieved by calling system information query interfaces, such as parsing the output of the `lscpu` command or reading the ` / sys` file system, to obtain the current total number of physical CPU cores, the distribution of logical cores, and the node topology information (number of nodes, memory access distance between nodes) for Non-Uniform Memory Access (NUMA) architecture. In a NUMA architecture server, different CPU cores may belong to different NUMA nodes, and each node has local memory to obtain the physical connection relationships of the underlying hardware.

[0032] Based on the test mode selection instructions and CPU core distribution information, the concurrent thread count parameter in the test parameters is dynamically adjusted.

[0033] By adjusting the number of concurrent threads, the hardware processing capacity and test load requirements can be matched. For example, when the target test mode is stress mode, the number of concurrent threads can be automatically adjusted to half or all of the number of CPU cores based on the acquired CPU core distribution information. This maximizes the parallel computing power of the multi-core processor, applies high concurrency pressure to the disk, and ensures full utilization of CPU resources without excessive contention. In normal mode, the number of threads remains at the default value to simulate a single-task scenario. Dynamically adjusting the concurrent thread count parameter based on the number of CPU cores avoids insufficient pressure due to setting the number of threads too low, or excessive CPU scheduling overhead due to setting it too high, ensuring the effectiveness of stress testing and the rational utilization of system resources.

[0034] Based on the test mode selection instructions and NUMA node topology information, the process core binding parameters in the test parameters are dynamically adjusted.

[0035] Modern servers mostly adopt NUMA architecture. Cross-node memory access can cause significant latency issues. To optimize memory access paths, the process-core binding parameter, which describes the binding relationship between the test process and a specific CPU core, is dynamically adjusted. In a NUMA architecture, if a test process runs on a CPU core but accesses memory located on another NUMA node, cross-node access latency occurs, severely impacting the accuracy of I / O performance testing. Therefore, the system uses process binding tools (such as numactl or taskset) to bind the test process to a specific set of CPU cores or NUMA nodes based on the extracted NUMA node topology information. For example, if the user specifies a NUMA node using the -N parameter, then `numactl --cpunodebind=N --membind=N` binds the test process to the CPU core and memory of that node, ensuring that the test process preferentially accesses local memory and reducing latency jitter caused by cross-node communication. If the user specifies a CPU affinity list (using the -c parameter), then `taskset -c` binds the test process to a specified core.

[0036] Based on the test mode selection command, if the target test mode is stress mode, the file size parameter will be increased; if the target test mode is stability mode, the test duration will be increased; if the target test mode is normal mode, the initial test parameters will be used; if the target test mode is adaptive mode, the initial test duration and the corresponding number of iterations will be configured.

[0037] Different test parameters are optimized for different test modes. For example, in stress mode, increasing the file size (e.g., from the default 1GB to 4GB) can extend the continuous read / write time, more fully exposing the disk's performance bottleneck under full load. In stability mode, increasing the test duration (e.g., setting it to 3600 seconds or even longer) can cover a longer time window, capturing fluctuations or degradation in disk performance over time. In normal mode, the initial parameters are kept unchanged to quickly obtain benchmark performance data. In adaptive mode, the initial test duration is set to 60 seconds, the number of iterations is set to 5, and dynamic timeout adjustment is enabled. Parameter adjustments driven by test modes can effectively improve the rationality of test parameters.

[0038] Finally, based on all dynamically adjusted test parameters, including file size, block size, test duration, number of threads, queue depth, number of iterations, CPU binding, NUMA binding, direct I / O flag, etc., a target test parameter configuration is generated for subsequent I / O read and write test processes.

[0039] S203, according to the target test parameter configuration, sequentially performs sequential write, sequential read, random write, random read, and mixed read / write tests on the disk to be tested.

[0040] This test sequence comprehensively covers typical disk I / O operation scenarios. The sequential read / write test uses the dd tool, which mainly evaluates the disk's throughput when processing consecutive data blocks, reflecting the disk's performance when processing large files (such as video editing and database backup). Before and after the test execution, a high-precision timing function is called to calculate the write / read bandwidth. The random read / write test uses the FIO tool, which focuses on evaluating the disk's response speed when processing discrete data blocks. IOPS is the core indicator, reflecting the disk's performance when processing small files or fragmented data (such as operating system startup and database transactions). The output is in JSON format, from which IOPS and bandwidth can be extracted. The mixed read / write test sets rw=rw and rwmixread=70, i.e., 70% read and 30% write, simulating the concurrent read / write operation scenario in real-world applications, and can more realistically reflect the disk's overall load capacity.

[0041] During test execution, the operating system's nanosecond-level time interface is called to obtain the nanosecond-level test start and end timestamps.

[0042] The accuracy of time measurements during testing directly determines the accuracy of performance calculations, especially when evaluating high-speed storage devices. Prioritizing calls to the operating system's nanosecond-level time interfaces, such as the `clock_gettime` system call or the `date +%s.%N` command in Linux, is crucial. For high-speed storage devices like NVMe SSDs, where a single I / O operation may take only microseconds or even nanoseconds, nanosecond-level time precision can capture extremely small time differences, thus accurately calculating the transfer rate.

[0043] If the current operating system does not support nanosecond-level time interfaces, then a microsecond-level time interface will be triggered to obtain microsecond-level test start and end timestamps. If the current operating system does not support microsecond-level time interfaces, then a second-level time interface will be triggered to obtain second-level test start and end timestamps.

[0044] Considering the potential differences in interface support across different operating system versions or hardware platforms, a multi-level fallback mechanism is implemented to ensure broad compatibility of the testing tools. When the system detects a nanosecond-level interface call failure or error, it automatically triggers fallback logic, switching to a microsecond-level time interface. While microsecond-level precision is lower than nanosecond-level precision, it still provides sufficient accuracy for performance testing of most mid-range storage devices. If the operating environment is extremely limited and does not support microsecond-level interfaces, the system will ultimately fall back to second-level time interfaces, ensuring that the test program can still run and produce results in extreme environments, rather than directly reporting an error and exiting, thus improving the environmental adaptability of the testing method. After obtaining the start and end timestamps, the system uses the `bc` tool (supporting floating-point numbers) to calculate the time difference and, combined with the number of bytes output by `dd` or the total data volume output by `fio`, calculates the bandwidth (MB / s) and IOPS. For FIO testing, the system prioritizes using the performance data in the FIO's own JSON output (which uses high-precision timing internally), and can use external timing as a backup if JSON parsing fails.

[0045] S204. If the current test mode is adaptive mode, extract the baseline performance data of the previously completed iteration rounds to calculate the average performance index, compare it with the preset target performance index to obtain the current performance ratio, and then compare it with the preset performance ratio to dynamically adjust the test timeout duration of the next iteration round, and execute the next iteration until the preset total number of iterations is reached.

[0046] S205: After all iteration rounds are completed, the baseline performance data of each iteration round is averaged and statistically analyzed over multiple rounds to generate a comprehensive performance index test report.

[0047] This embodiment receives and parses user-inputted test mode selection commands, dynamically allocates test parameters in the early stages of test preparation and execution, detects the CPU core distribution and NUMA node topology information of the system, and dynamically adjusts the number of concurrent threads and file size according to the hardware topology status and the specific test mode selected by the user. It also forces the distribution of process core binding parameters and constructs a progressively decreasing time call logic when acquiring test start and end timestamps, sequentially attempting system interfaces at the nanosecond, microsecond, and second levels. This allows test processes to bind to the CPU cores and local memory of the same NUMA node, avoiding cross-node memory access latency, reducing the variability of test results, and improving the consistency and comparability of test results. Adaptive configuration of parameters such as the number of threads and file size based on different test modes ensures that each test can fully evaluate disk I / O performance under the same conditions, avoiding horizontal comparison bias caused by missing test items or inconsistent order, and improving test adaptability. The multi-level rollback time sampling mechanism can obtain accurate test results on high-performance disks while maintaining backward compatibility with older kernels or resource-constrained environments.

[0048] Example 3 Figure 3 This is a flowchart of a disk I / O performance testing method according to Embodiment 3 of the present invention. This embodiment is based on the above embodiment and optimized. In this embodiment, S104 is specifically optimized as follows: If the current test mode is normal mode, the initial test parameters will not be adjusted; If the current test mode is stress mode, then increase the test duration, number of concurrent threads, queue depth, and number of iterations parameters in the test parameters; If the current test mode is stability mode, then add the test duration and iteration count parameters to the test parameters; If the current test mode is adaptive mode, extract the number of I / O operations per second (IOPS) from the baseline performance data of the previously completed iterations, calculate the average IOPS value, compare it with the preset target IOPS value to obtain the current performance ratio, and then compare it with the preset performance ratio. If it exceeds the upper limit of the preset performance ratio, double the test timeout for the next iteration; if it is lower than the lower limit of the preset performance ratio, halve the test timeout for the next iteration.

[0049] Accordingly, the disk I / O performance testing method provided in this embodiment specifically includes: S301 responds to the user's test mode selection command and configures the corresponding initial test parameters, performs a pre-test check on the disk to be tested, and generates test check results.

[0050] S302 determines the test mode to be executed based on the test mode selection instruction and test check results, dynamically adjusts the corresponding test parameters, and generates the target test parameter configuration.

[0051] S303 executes corresponding I / O read / write tests on the disk under test according to the target test parameters, and calls the multi-level high-precision time interface to obtain the test start and end timestamps during the test, and calculates the benchmark performance data of the current iteration round in combination with the corresponding test transmission data volume.

[0052] S304. If the current test mode is normal, the initial test parameters will not be adjusted. Normal mode aims to provide a fast and standard means of evaluating disk performance, so user-defined or default initial parameters can be used without adjustment, such as the default test duration of 30 seconds and single-threaded operation. It is suitable for scenarios where the test accuracy requirements are not high or only benchmark performance data needs to be obtained.

[0053] If the current test mode is stress mode, increase the test duration, number of concurrent threads, queue depth, and number of iterations parameters. The purpose of stress mode is to probe the disk's performance limits or stability issues under high load. In this mode, the test time can be extended, for example, to 300 seconds; the number of concurrent threads can be increased according to the number of CPU cores, such as setting it to half or all of the CPU cores; the queue depth parameter should also be increased accordingly, such as from the default 16 to 64, to simulate high-concurrency business scenarios, ensuring the disk is under full load and thus exposing its performance bottlenecks.

[0054] If the current test mode is stability mode, increase the test duration and iteration count parameters in the test parameters. Stability mode focuses on examining the performance consistency of the disk under long-term operation. In this case, the test duration can be significantly increased, such as setting it to 3600 seconds or even longer, and the number of iterations can be increased, such as setting it to 5 times. Long-term continuous read and write operations can effectively detect whether the disk has problems such as overheating and frequency throttling, performance jitter, etc., which only appear under long-term operation.

[0055] If the current test mode is adaptive, extract the number of I / O operations per second (IOPS) from the baseline performance data of the previously completed iterations, calculate the average IOPS value, compare it with the preset target IOPS value to obtain the current performance ratio, and then compare it with the preset performance ratio. If it exceeds the upper limit of the preset performance ratio, double the test timeout for the next iteration; if it is lower than the lower limit of the preset performance ratio, halve the test timeout for the next iteration.

[0056] In adaptive mode, the system no longer passively executes tests of fixed duration. Instead, it dynamically adjusts the test duration through a closed-loop timeout control mechanism based on performance feedback. For example, IOPS (Input / Output Operations Per Second) can be used as a key metric for disk performance. A target IOPS value, representing a moderate performance level (e.g., 1000), is preset. Upper and lower limits for the preset performance ratio are used to determine whether the current performance is significantly lower or higher than expected (e.g., an upper limit of 1.5 and a lower limit of 0.5). IOPS values ​​are extracted from the benchmark performance data of all previously completed iterations, and the average IOPS value for each iteration is calculated. This average is then compared to the preset target IOPS value to obtain the performance ratio for the current iteration. The test timeout is then compared with the performance ratio to check if it exceeds the upper or lower limit. If it exceeds the upper limit, it indicates that the disk performance is low. Maintaining the original short test duration may not be able to collect enough data samples, or may even cause the test to time out. In this case, the test timeout duration for the next iteration is doubled to obtain more stable and accurate performance data. Conversely, if it is below the lower limit, it indicates that the disk performance is extremely high. An excessively long test duration would waste time and resources. In this case, the test timeout duration for the next iteration is halved, thereby significantly shortening the test time while ensuring data validity. At the same time, to prevent the system from becoming unstable due to excessive adjustments, the test timeout duration is usually limited to a reasonable range, such as between 30 seconds and 300 seconds. For example, if the preset target IOPS is 1000, and the average IOPS in the first few iterations of a test is only 300, then the current performance ratio is approximately 1000 / 300 = 3.33, exceeding the preset performance ratio limit of 1.5. In this case, the device performance is considered low, and the test duration for the next round is doubled from 60 seconds to 120 seconds. If the average IOPS increases to 500 after the next test, and the performance ratio drops to 2.0 but remains above 1.5, the duration is doubled again to 240 seconds until the performance ratio falls into the normal range or reaches the maximum duration limit. Conversely, if a high-performance NVMe SSD measures an average IOPS as high as 2500, the performance ratio is only 0.4, below the lower limit of 0.5. The test duration can be halved to complete the test quickly. Dynamically adjusted test durations allow the disk testing process to adapt to disk performance, avoiding test failures on low-performance devices and resource waste on high-performance devices.

[0057] Optionally, determine whether the current iteration is the first iteration. If so, use the initial test duration in the initial test parameters as the test timeout duration for the next iteration. Otherwise, dynamically adjust the test timeout duration for the next iteration based on the average performance index of the previously completed iterations.

[0058] Since the adaptive algorithm relies on feedback from historical data, and historical performance data is unavailable during the first iteration, making it impossible to calculate the average and performance ratio, the first iteration uses a preset initial test duration (e.g., 60 seconds). Starting from the second iteration, the average performance metric is calculated based on the baseline performance data from the previous iteration, and dynamic timeout adjustment logic is enabled to ensure a smooth start to the testing process and avoid logical errors caused by a lack of data.

[0059] S305: After all iteration rounds are completed, the baseline performance data of each iteration round is averaged and statistically analyzed over multiple rounds to generate a comprehensive performance index test report.

[0060] Specifically, benchmark performance data from all iterations is collected, and the benchmark performance data from each iteration is statistically analyzed using a multi-iteration averaging algorithm to obtain the final test results.

[0061] During testing, each iteration generates a set of benchmark performance data, such as bandwidth for sequential read / write, IOPS for random read / write, and latency data for mixed read / write. The benchmark performance data from all iterations is collected as the statistical basis. Then, a multi-iteration averaging algorithm is used to statistically analyze the benchmark performance data from each iteration. Calculating the mean effectively reduces errors caused by system fluctuations in a single test, forming the final test result. For example, disk performance is often affected by various instantaneous factors such as operating system scheduling, background process interference, and cache status, which can lead to significant randomness in the results of a single test. Therefore, by executing multiple identical I / O test iterations (e.g., averaging 3 iterations in normal mode, automatically using 3 iterations in stress mode, 5 iterations in adaptive mode combined with dynamic timeout adjustment, or more), and calculating the average of these iteration results, these random fluctuations can be effectively smoothed out, resulting in a value that better reflects the true steady-state performance of the storage device. Furthermore, the standard deviation or coefficient of variation can be calculated. For example, controlling the coefficient of variation within 5% provides a quantitative indicator of the reliability of the results, further indicating unstable test environments or abnormal device performance, allowing for a comprehensive evaluation of the test results.

[0062] The comprehensive performance index test report includes: target test parameter configuration, final test results, test inspection results, test anomaly records, and test delay statistics.

[0063] The final comprehensive performance test report can be a structured and detailed document, mainly including the target test parameter configuration, recording the specific parameters used during test execution, such as test file size, block size, number of concurrent threads, queue depth, test mode (stress, stability, etc.), whether direct I / O is enabled, and CPU and NUMA binding strategies, describing the test conditions under which the performance data was measured, clearly indicating the load intensity under which the test was conducted, facilitating horizontal comparisons between different test scenarios; it also includes the final test results, recording the values ​​of various performance indicators after multiple rounds of averaging, typically including sequential read / write bandwidth (MB / s), random read / write IOPS, throughput under mixed read / write, and the time consumed for each test, intuitively reflecting the disk's performance level under different workloads, serving as the main basis for evaluating whether the disk meets the requirements; it also includes... This includes recording test anomalies, documenting various unexpected events that occur during the testing process, such as timeouts due to excessive system load, FIO tool version incompatibility errors, and test skipping due to insufficient permissions. The records detail the occurrence time, specific description, and handling method (e.g., skip, retry, or termination) of these anomalies for fault diagnosis, distinguishing whether performance degradation is due to hardware bottlenecks in the disk itself or external interference or software errors during the testing process, thus avoiding misjudgments. It also includes test latency statistics, typically including average latency, maximum latency, and different percentile latency (e.g., 95%, 99%, 99.9% latency). For random read / write and mixed read / write tests, simple IOPS or bandwidth values ​​may not fully reflect the user experience, especially in response-time-sensitive scenarios such as databases, reflecting storage service quality under extreme conditions. The comprehensive final report ensures the accuracy, reliability, and complete contextual information of the test results, providing users with a holistic analytical perspective.

[0064] This embodiment implements different parameter adjustment strategies based on the current test mode. In adaptive mode, a cold start mechanism using the initial test duration is set for the first iteration. In subsequent iterations, the historical average IOPS is extracted and the target IOPS is calculated. When the ratio is greater than the upper limit of the preset performance ratio, the timeout duration of the next iteration is doubled; when it is lower than the lower limit, the timeout duration of the next iteration is halved. Finally, the baseline performance data of all multiple iterations are summarized, and after multiple iterations and averaging statistical algorithms, a comprehensive test report is generated that includes test parameter configuration, test results, anomaly records, and latency quantile data. By introducing a dynamic timeout adjustment mechanism in adaptive mode, while using fixed enhancement parameters in stress and stability modes, this approach ensures both improved adaptive efficiency for daily rapid testing and meets the needs of stress and stability testing for fixed high loads or long-term operation, achieving optimal parameter configuration for different testing scenarios. Furthermore, by differentiating between the first and subsequent iterations, it avoids the problem of missing historical data in the first iteration of adaptive mode, ensuring test process stability. A mechanism that doubles or halves the test duration for the next round based on the performance ratio of the average IOPS ratio of completed iterations compared to a preset performance ratio, combined with boundary control, ensures suitable test times for various disks with wide performance ranges. This effectively avoids drastic fluctuations in duration caused by single performance jitters, achieving smooth and gradual test parameter adjustments, guaranteeing test process stability, and avoiding waste of computing power and waiting time without sacrificing data sample stability. The final multi-dimensional comprehensive test report presents the overall performance of the tested disk from multiple perspectives, providing testers with complete and traceable information from the test environment to the test results.

[0065] Example 4 Figure 4 This is a schematic diagram of a disk I / O performance testing device according to Embodiment 4 of the present invention. In this embodiment, the disk I / O performance testing device includes: The test preparation module 810 is used to respond to the user's test mode selection command and configure the corresponding initial test parameters, and to perform pre-test checks on the disk to be tested to generate test check results. The parameter configuration module 820 is used to determine the test mode to be executed based on the test mode selection instruction and test check results, and dynamically adjust the corresponding test parameters to generate the target test parameter configuration. The test execution module 830 is used to perform corresponding I / O read and write tests on the disk to be tested according to the target test parameters, and to call the multi-level high-precision time interface to obtain the test start and end timestamps during the test, and to calculate the benchmark performance data of the current iteration round in combination with the corresponding test transmission data volume; The adaptive testing module 840 is used to extract the baseline performance data of the previously completed iterations to calculate the average performance index when the current testing mode is adaptive mode. It compares the average performance index with the preset target performance index to obtain the current performance ratio, and then compares the current performance ratio with the preset performance ratio to dynamically adjust the test timeout duration of the next iteration and execute the next iteration until the preset total number of iterations is reached. The report generation module 850 is used to perform multi-round averaging statistics on the benchmark performance data of each iteration after all iteration rounds are completed, and generate a comprehensive performance index test report.

[0066] This embodiment responds to user commands and configures initial test parameters through the test preparation module, while simultaneously performing pre-test checks. The parameter configuration module generates target test parameter configurations based on the desired test mode. The test execution module performs I / O read / write tests on the disk according to the target test parameter configurations, and during the test, it calls a multi-level high-precision time interface to obtain test start and end timestamps to calculate baseline performance data. The adaptive test module dynamically adjusts the test duration in adaptive mode. The report generation module performs multi-round averaging statistics on the baseline performance data from each iteration to generate the final report. By dynamically generating the target configuration in conjunction with environmental checks, test interruptions caused by hardware and software environments are avoided, improving the test success rate. The introduction of a high-precision time interface effectively reduces errors and improves the accuracy of raw performance data when dealing with high-speed solid-state drives. The dynamic timeout adjustment mechanism and multi-round averaging statistics in adaptive mode avoid the time waste or insufficient data samples caused by traditional fixed timeouts, effectively improving test efficiency, adapting to tests on disks with different performance levels, and avoiding erroneous adjustments due to single performance fluctuations, thus increasing the test success rate and enhancing the confidence of the comprehensive test report.

[0067] The disk I / O performance testing device provided in the embodiments of the present invention can execute the disk I / O performance testing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0068] Example 5 Figure 5 This is a structural diagram of an electronic device according to Embodiment 5 of the present invention. Figure 5 A block diagram is shown of an exemplary electronic device 12 suitable for implementing embodiments of the present invention. Figure 5 The electronic device 12 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0069] like Figure 5As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0070] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0071] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0072] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 5 Not shown; usually referred to as a "hard drive"). Although Figure 5 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0073] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0074] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the electronic device 12 / server / computer, and / or with any device that enables the electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 5 As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 5 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0075] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the disk I / O performance testing method provided in the embodiments of the present invention.

[0076] Example 6 Embodiment 6 of the present invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the disk I / O performance testing method provided in the above embodiments.

[0077] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0078] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0079] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0080] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0081] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A method for testing disk I / O performance, characterized in that, include: S101, responding to the user's test mode selection command and configuring the corresponding initial test parameters, performs a pre-test check on the disk to be tested and generates test check results; S102, determine the test mode to be executed based on the test mode selection instruction and test check results, dynamically adjust the corresponding test parameters, and generate the target test parameter configuration; S103, according to the target test parameters, execute the corresponding I / O read and write test on the disk to be tested, and during the test, call the multi-level high-precision time interface to obtain the test start and end timestamps, and calculate the benchmark performance data of the current iteration round in combination with the corresponding test transmission data volume; S104. If the current test mode is adaptive mode, extract the baseline performance data of the previously completed iteration rounds to calculate the average performance index, compare it with the preset target performance index to obtain the current performance ratio, and then compare it with the preset performance ratio to dynamically adjust the test timeout duration of the next iteration round, and execute the next iteration round until the preset total number of iterations is reached. S105. After all iteration rounds are completed, the baseline performance data of each iteration round is averaged and statistically analyzed over multiple rounds to generate a comprehensive performance index test report.

2. The method according to claim 1, characterized in that, S101 includes: The system receives and parses the user's input test mode selection command to obtain the target test mode and basic test parameters, and configures the initial test parameters. The target test modes include normal mode, stress mode, stability mode and adaptive mode. Perform environment checks and test dependency tool checks on the disk to be tested, and generate test check results.

3. The method according to claim 2, characterized in that, S102 includes: Extract the hardware resource topology status from the test and inspection results to obtain CPU core distribution information and NUMA node topology information; Based on the test mode, select the instruction and CPU core distribution information, and dynamically adjust the concurrent thread count parameter in the test parameters. Based on the test mode selection instructions and NUMA node topology information, dynamically adjust the process core binding parameters in the test parameters; Select the command based on the test mode. If the target test mode is stress mode, increase the file size parameter. If the target test mode is stability mode, increase the test duration. If the target test mode is normal mode, use the initial test parameters. If the target test mode is adaptive mode, configure the initial test duration and the corresponding number of iterations. Generate the target test parameter configuration based on all dynamically adjusted test parameters.

4. The method according to claim 1, characterized in that, S103 further includes: Based on the target test parameter configuration, sequential write, sequential read, random write, random read, and mixed read / write tests are performed on the disk to be tested in sequence. During test execution, the operating system's nanosecond-level time interface is called to obtain the nanosecond-level test start and end timestamps; If the current operating system does not support nanosecond-level time interfaces, then the microsecond-level time interface will be triggered to obtain microsecond-level test start and end timestamps. If the current operating system does not support the microsecond-level time interface, then further downgrade to trigger the second-level time interface to obtain the second-level test start and end timestamps.

5. The method according to claim 2, characterized in that, S104 further includes: If the current test mode is normal mode, the initial test parameters will not be adjusted; If the current test mode is stress mode, then increase the test duration, number of concurrent threads, queue depth, and number of iterations parameters in the test parameters; If the current test mode is stability mode, then add the test duration and iteration count parameters to the test parameters; If the current test mode is adaptive mode, extract the number of I / O operations per second (IOPS) from the baseline performance data of the previously completed iterations, calculate the average IOPS value, compare it with the preset target IOPS value to obtain the current performance ratio, and then compare it with the preset performance ratio. If it exceeds the upper limit of the preset performance ratio, double the test timeout for the next iteration; if it is lower than the lower limit of the preset performance ratio, halve the test timeout for the next iteration.

6. The method according to claim 5, characterized in that, S104 further includes: Determine whether the current iteration is the first iteration. If so, use the initial test duration in the initial test parameters as the test timeout duration for the next iteration. Otherwise, dynamically adjust the test timeout duration for the next iteration based on the average performance index of the previously completed iterations.

7. The method according to claim 1, characterized in that, S105 includes: Collect benchmark performance data from all iterations, and use a multi-iteration averaging algorithm to statistically analyze the benchmark performance data from each iteration to obtain the final test results; The comprehensive performance index test report includes: target test parameter configuration, final test results, test inspection results, test anomaly records, and test delay statistics.

8. A disk I / O performance testing apparatus, used to implement the disk I / O performance testing method as described in any one of claims 1-7, characterized in that, include: The test preparation module is used to respond to the user's test mode selection command and configure the corresponding initial test parameters, and to perform pre-test checks on the disk to be tested to generate test check results. The parameter configuration module is used to determine the test mode to be executed based on the test mode selection instructions and test check results, and dynamically adjust the corresponding test parameters to generate the target test parameter configuration. The test execution module is used to perform corresponding I / O read and write tests on the disk to be tested according to the target test parameters, and during the test, it calls the multi-level high-precision time interface to obtain the test start and end timestamps, and calculates the benchmark performance data of the current iteration round in combination with the corresponding test transmission data volume; The adaptive testing module is used to extract the baseline performance data of the previously completed iterations to calculate the average performance index when the current testing mode is adaptive. It then compares the average performance index with the preset target performance index to obtain the current performance ratio, and compares the current performance ratio with the preset performance ratio to dynamically adjust the test timeout duration of the next iteration. The next iteration is then executed until the preset total number of iterations is reached. The report generation module is used to perform multi-round averaging statistics on the benchmark performance data of each iteration after all iteration rounds are completed, and generate a comprehensive performance index test report.

9. An electronic device, characterized in that, The electronic device includes: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the disk I / O performance testing method as described in any one of claims 1-7.

10. A storage medium comprising computer-executable instructions, which, when executed by a computer processor, are used to perform the disk I / O performance testing method as described in any one of claims 1-7.

Images