A method and system for dynamically obtaining optimal performance of a storage system
By automating the generation and parsing of storage system test configuration files, the problem of time-consuming manual adjustment of test pressure and parameters in existing technologies has been solved, realizing the automation and intuitiveness of storage system performance testing, and improving test efficiency and accuracy.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA TELECOM DIGITAL INTELLIGENCE TECH CO LTD
- Filing Date
- 2022-11-24
- Publication Date
- 2026-06-26
Smart Images
Figure CN115774669B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of performance testing technology for storage systems, specifically a method and system for dynamically obtaining the optimal performance of a storage system. Background Technology
[0002] With the rapid development of information technology, data across all industries has experienced explosive growth. As the core system ultimately carrying this data, the importance of storage systems is self-evident. Performance data, as a crucial parameter of storage products, is one of the most important core competitive advantages of storage systems. During the development of storage systems, developers often need to use performance testing tools (such as vdbench) to continuously stress and repeatedly test the storage system to determine the product's optimal performance. When using storage performance testing tools, the maximum IOPS of the storage system can be tested by continuously increasing the number of threads to increase business pressure.
[0003] This testing method yields high IOPS values, which can be used as a product's promotional parameter. However, in practical applications, latency must also be considered in addition to IOPS. If IOPS is high but latency is also high, the application performance will be very poor. Therefore, finding a balance between IOPS and latency is a major concern for developers.
[0004] In actual testing, developers need to first determine a maximum IOPS value and corresponding latency, and then repeatedly test under varying workloads to find a balance between IOPS and latency. This process requires developers to manually compare test results and adjust test loads and parameters repeatedly, which is time-consuming and inefficient. Furthermore, the test results need to be manually extracted and analyzed, making them less intuitive. Summary of the Invention
[0005] To address the shortcomings of existing technologies, this invention provides a method and system for dynamically obtaining the optimal performance of a storage system. This solves the problems of existing testing processes requiring R&D personnel to manually compare test results and adjust test pressure and parameters repeatedly, which is time-consuming and inefficient. Additionally, test results need to be manually extracted and analyzed, making them unintuitive.
[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for dynamically obtaining the optimal performance of a storage system, comprising the following steps:
[0007] S1: Write user configuration files according to the rules, which will serve as input for generating test tool configuration files later;
[0008] S2: Obtain the CPU information of the test stress machine, determine and obtain the appropriate number of test threads based on the number of CPU threads, and write it into the user configuration file of S1;
[0009] S3: Based on the user configuration file generated in S2, the corresponding test configuration file for the testing tool is generated by parsing and comparing with the conversion rules;
[0010] S4: Automatically test by calling the corresponding test tool based on the test configuration file generated in S3;
[0011] S5: Automatically processes and analyzes performance-related data from test results to generate visual charts.
[0012] Furthermore, the information in the configuration file of S1 includes the size of the IO block to be tested, the read / write mode, the read / write ratio, the path of the storage volume device to be tested, the absolute path of the test tool, the running time, and the data sampling points.
[0013] Furthermore, the configuration file of S1 is saved in ini format, and is divided into global section and rd section, with multiple rd sections.
[0014] Furthermore, the method for obtaining the number of test threads in S2 includes:
[0015] S21: Obtain the number of CPU cores of the test client according to Linux commands;
[0016] S22: Use twice the number of CPU cores obtained in S21 as the number of threads and write it to the user configuration file.
[0017] Furthermore, step S3 specifically includes the following steps:
[0018] S31: The system reads the user configuration files generated in S1 and S2;
[0019] S32: Parse the user configuration files in S31 one by one according to the conversion rules. The dictionary keys are the field names in the user configuration files, and the values are the field names in the corresponding test tool configuration files. The conversion rules are the correspondence between the fields in the user configuration files and the fields in the configuration files of common storage performance test tools. The conversion rules exist in the form of a dictionary.
[0020] S33: Generate the configuration file for the test tool in the user configuration file.
[0021] Furthermore, the step of S4 calling the corresponding testing tool to perform automatic testing includes the following steps:
[0022] S41: The test system starts the test tool and loads the test configuration file according to the test tool specified in the user configuration file. The test tool is the vdbench tool.
[0023] S42: Use the test configuration file generated in step 3 to perform a maximum performance test and test the maximum IOPS of the storage system;
[0024] S43: The system performs multiple dynamic tests based on the value defined in the datapoint field of the user configuration file, and records the business pressure limit for each test. The business pressure limit is the product of the maximum IOPS and the value defined in the datapoint field.
[0025] Furthermore, the value defined in the datapoint field in S43 is written into the test configuration file according to the conversion rules in S3.
[0026] Furthermore, the test time for both the maximum performance test and the dynamic test is 300 seconds.
[0027] Furthermore, step S5 specifically includes the following steps:
[0028] S51: The system switches to the test results directory and extracts valid data from the test results, including key test data from all test rounds under each IO test model;
[0029] S52: Extract the data of the maximum performance test rounds under each IO model, with one row for each IO test model, and display it in the form of a table;
[0030] The IOPS and latency under different business pressures for each IO test model are extracted, and the relationship between IOPS and latency is displayed in the form of a line graph with IOPS as the horizontal axis and latency as the vertical axis.
[0031] A system for dynamically obtaining the optimal performance of a storage system, comprising:
[0032] The configuration generation module is used to read the CPU information on the test stress machine, determine the number of test threads and write them to the user configuration file. At the same time, it parses the user configuration file and generates the test configuration file of the corresponding test tool according to the configuration items in the template configuration file.
[0033] The scheduling and execution module is used to call the corresponding test tool according to the test tool specified in the user configuration file and perform tests using the generated test configuration file.
[0034] The logging module is used to record key steps and information during the operation process, making it easier to track and analyze problems.
[0035] The results analysis module is used to process the test results, extract key performance information, and display the test data in the form of visual charts.
[0036] The present invention has the following beneficial effects:
[0037] The system parses user configuration files using conversion rules to generate corresponding test configuration files for testing tools. Then, based on these configuration files, the system calls the appropriate testing tools to perform a maximum performance test, determining the maximum IOPS of the storage system. Multiple dynamic tests are then performed based on the values defined in the datapoint field of the user configuration file, recording the business pressure limits for each test. Finally, the test results are processed to extract key performance information and present the test data in visual charts. Compared to existing technologies, this approach eliminates the need for developers to manually compare test results and adjust test pressure and parameters for repeated testing; the entire process is automated. Furthermore, the test structure does not require manual extraction and analysis; the system automatically generates visual charts after extraction and analysis, providing a more intuitive understanding.
[0038] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description
[0039] Figure 1 This is a flowchart of the method of the present invention;
[0040] Figure 2 This is a system flowchart of the present invention;
[0041] Figure 3 This is a schematic diagram of the user configuration file of the present invention;
[0042] Figure 4 This refers to the data from the maximum performance test rounds for each IO model in this invention;
[0043] Figure 5 This is a diagram showing the correspondence between IOPS and latency in this invention. Detailed Implementation
[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0045] In the description of this invention, it should be understood that the terms "opening", "upper", "lower", "thickness", "top", "middle", "length", "inner", "around", etc., which indicate orientation or positional relationship, are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the components or elements referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as limiting this invention.
[0046] Please see Figures 1-5 This invention provides a technical solution: a method for dynamically obtaining the optimal performance of a storage system, comprising the following steps:
[0047] S1: Write user configuration files according to the rules, which will serve as input for generating test tool configuration files later;
[0048] S2: Obtain the CPU information of the test stress machine, determine and obtain the appropriate number of test threads based on the number of CPU threads, and write it into the user configuration file of S1;
[0049] S3: Based on the user configuration file generated in S2, the corresponding test configuration file for the testing tool is generated by parsing and comparing with the conversion rules;
[0050] S4: Automatically test by calling the corresponding test tool based on the test configuration file generated in S3;
[0051] S5: Automatically processes and analyzes performance-related data from test results to generate visual charts.
[0052] The information in the configuration file of S1 includes the size of the IO block to be tested, the read / write mode, the read / write ratio, the path of the storage volume device to be tested, the absolute path of the test tool, the running time, and the data sampling points.
[0053] Specifically, the configuration file of S1 is saved in ini format and is divided into global section and rd section, with multiple rd sections.
[0054] In this implementation, the user configuration file is saved in INI format, which is divided into global section and rd section. There can be multiple rd sections. Common configuration items such as LUN, tool_path, runtime, and datapoint are placed under the global field, and the rest of the information is placed under the rd field.
[0055] Specifically, the method for obtaining the number of test threads in S2 includes:
[0056] S21: Obtain the number of CPU cores of the test client according to Linux commands;
[0057] S22: Use twice the number of CPU cores obtained in S21 as the number of threads and write it to the user configuration file.
[0058] In this implementation, the system first obtains the number of CPU cores of the test client through Linux commands (such as "cat / proc / cpuinfo|grepprocessor|wc -l"), and writes twice the obtained number of CPU cores into the global section of the user configuration file in the format of threads = number of CPU cores * 2.
[0059] Specifically, S3 includes the following steps:
[0060] S31: The system reads the user configuration files generated in S1 and S2;
[0061] S32: Parse the user configuration files in S31 one by one according to the conversion rules. The dictionary keys are the field names in the user configuration files, and the values are the field names in the corresponding test tool configuration files. The conversion rules are the correspondence between the fields in the user configuration files and the fields in the configuration files of common storage performance test tools. The conversion rules exist in the form of a dictionary.
[0062] S33: Generate the configuration file for the test tool in the user configuration file.
[0063] In this implementation, the conversion rule refers to the correspondence between fields in the user configuration file and fields in the configuration files of commonly used storage performance testing tools. The conversion rule exists in the form of a dictionary, where the dictionary key is the field name in the user configuration file and the value is the field name in the corresponding test tool configuration file. The system reads the user configuration file, parses it one by one according to the conversion rule, and generates the configuration file of the test tool in the user configuration file.
[0064] Specifically, the step of S4 calling the corresponding testing tool to perform automatic testing includes the following steps:
[0065] S41: The test system starts the test tool and loads the test configuration file according to the test tool specified in the user configuration file. The test tool is the vdbench tool.
[0066] S42: Use the test configuration file generated in step 3 to perform a maximum performance test and test the maximum IOPS of the storage system;
[0067] S43: The system performs multiple dynamic tests based on the value defined in the datapoint field of the user configuration file, and records the business pressure limit for each test. The business pressure limit is the product of the maximum IOPS and the value defined in the datapoint field.
[0068] The value defined in the datapoint field in S43 is written into the test configuration file according to the conversion rules of S3;
[0069] The test duration for both the maximum performance test and the dynamic test is 300 seconds.
[0070] In this implementation scheme, the testing system will start the testing tool and load the test configuration file according to the testing tool specified in the user configuration file. The testing tool will use the converted test configuration file to perform a maximum performance test and test the maximum IOPS of the storage system, which is denoted as P1.
[0071] After the IOPS test is completed, the system performs multiple dynamic tests based on the value defined in the datapoint field of the user configuration file. The business pressure of each test is the product of P1 and the ratio defined in the datapoint.
[0072] Specifically, S5 includes the following steps:
[0073] S51: The system switches to the test results directory and extracts valid data from the test results, including key test data from all test rounds under each IO test model;
[0074] S52: Extract the data of the maximum performance test rounds under each IO model, with one row for each IO test model, and display it in the form of a table;
[0075] The IOPS and latency under different business pressures for each IO test model are extracted, and the relationship between IOPS and latency is displayed in the form of a line graph with IOPS as the horizontal axis and latency as the vertical axis.
[0076] In this implementation plan, after the test is completed, the system will switch to the test results directory, analyze and process the test results, extract key information and generate visual charts, so that R&D personnel can view the maximum performance and quickly locate the point where the latency jumps, and find the balance point between IOPS and latency.
[0077] During this process, the system will extract the valid data from the test results, including key test data for all test rounds under each IO test model, such as IO size, read-write ratio, read-write mode, latency, IOPS, etc. The system will extract the data of the maximum performance test round under each IO model, one row for each IO test model, and display it in the form of a table.
[0078] At the same time, the IOPS and latency under different business pressures in each IO test model are extracted, and the relationship between IOPS and latency is displayed in the form of a line graph with IOPS as the horizontal axis and latency as the vertical axis.
[0079] A system for dynamically obtaining the optimal performance of a storage system, comprising:
[0080] The configuration generation module is used to read the CPU information on the test stress machine, determine the number of test threads and write them to the user configuration file. At the same time, it parses the user configuration file and generates the test configuration file of the corresponding test tool according to the configuration items in the template configuration file.
[0081] The scheduling and execution module is used to call the corresponding test tool according to the test tool specified in the user configuration file and perform tests using the generated test configuration file.
[0082] The logging module is used to record key steps and information during the operation process, making it easier to track and analyze problems.
[0083] The results analysis module is used to process the test results, extract key performance information, and display the test data in the form of visual charts.
[0084] In this implementation, the configuration generation module reads the CPU information on the test stress machine, determines the number of test threads and writes it into the user configuration file. At the same time, it parses the user configuration file and generates the test configuration file for the corresponding test tool according to the configuration items in the template configuration file. Then, the scheduling and execution module calls the corresponding test tool according to the test tool specified in the user configuration file and uses the generated test configuration file to perform the test.
[0085] During the testing process, the logging module records key steps and information during the operation, making it easier to track and analyze problems.
[0086] After the test is completed, the result analysis module processes the test results, extracts key performance information, and displays the test data in the form of visual charts.
[0087] like Figure 1 As shown, before conducting the test, it is necessary to first write a user configuration file according to the rules. The user configuration file is mainly used to limit the test scenario, test tools, and devices under test. It mainly includes information such as IO block size, read / write mode, read / write ratio, device path of the test volume, absolute path of the test tool on the stress machine, test duration, and data sampling points. These are configured under the fields xfers_size, seekpct, rdpct, lun, tool_path, runtime, and datapoint, respectively. The user configuration file is saved in INI format and is divided into globalsection and rdsection, where there can be multiple rdsections.
[0088] Common configuration items such as LUN, tool_path, runtime, and datapoint are placed under the global section field, while other information is placed under the rd section field. xfersize has four options: 4K, 8K, 64K, and 1M; seekpct has two options: 0 and 100, representing sequential and random modes respectively; rdpct is set from 0 to 100, representing the proportion of read I / O in the business I / O; LUN specifies the path of the volume device mounted on the stress tester, such as / dev / sdb; tool_path specifies the system path of the testing tools, such as / usr / local / bin / vdbench; runtime represents the test execution time in seconds, such as runtime=300 meaning a single test runs for 5 minutes.
[0089] like Figure 3 As shown, the configuration file sets up two rdsections, which are two IO test models: 8K sequential read / write with a read ratio of 30% and 8K random read / write with a write ratio of 100%. Combined with the configuration of the global field, it can be seen that the vdbench tool is used to test the / dev / sdb device, with each test lasting 300 seconds.
[0090] After the user configuration file is completed, it will be used as the input for the subsequent test tool configuration file. Then, the CPU information of the test stress machine needs to be obtained, and the appropriate number of test threads will be determined and written into the user configuration file based on the number of CPU threads.
[0091] During this process, the system first obtains the number of CPU cores of the test client through Linux commands (such as "cat / proc / cpuinfo|grep processor|wc -l"). In order to ensure sufficient business pressure, the system writes twice the number of CPU cores obtained into the global section of the user configuration file in the form of threads = number of CPU cores * 2. For example, if the number of CPU cores of the current test stress machine is 48, then the information written into the user configuration file is threads = 96.
[0092] After completing the above steps, the final generated user configuration file needs to be converted into a test configuration file for the specified testing tool according to the conversion rules.
[0093] The conversion rules refer to the mapping between fields in the user configuration file and fields in the configuration files of commonly used storage performance testing tools. The conversion rules exist in the form of multiple dictionaries, where the dictionary keys are field names from the user configuration file, and the values are field names from the corresponding testing tool configuration files. For example... Figure 3The user configuration file shown shows that the specified test tool is vdbench, and the test time is 300 seconds, as indicated by the tool_path. According to the conversion rules, runtime=300 will be converted to elapsed=300. Similarly, the other fields will also be converted to their corresponding values in the vdbench configuration file, ultimately generating a complete vdbench test configuration file. With the conversion rules in place, the system can generate the configuration file for the test tool in the user configuration file from the user configuration file generated in the above steps. When tool_path specifies other test tools, the parsing and conversion will also follow a similar process.
[0094] Then, the system calls the specified testing tool and uses the converted test configuration file to perform the test. The testing system will start the testing tool and load the test configuration file according to the testing tool specified in the user configuration file.
[0095] First, the testing tool will use the converted test configuration file to perform a maximum performance test and test the maximum IOPS of the storage system, which is denoted as P1.
[0096] After the IOPS maximization test is completed, the system performs multiple dynamic tests based on the value defined in the datapoint field of the user configuration file. The business load for each test is the product of P1 and the ratio defined in the datapoint. For example... Figure 3 The user profile shown has datapoint values of 50%, 60%, 70%, 80%, 85%, 90%, 91%, 92%, 93%, 94%, 95%, 96%, 97%, 98%, and 99%. This indicates that after the first maximum IOPS test, 15 more tests will be performed, each lasting 300 seconds as defined in the user profile. The business pressure limit is the product of P1 and the corresponding percentage.
[0097] The business pressure limit parameter is written into the test configuration file as part of the conversion rules. For example... Figure 3The user configuration file shows that the testing tool specified is vdbench. The parameter in its test configuration file that limits the business load is iorate. After a maximum IOPS test is completed, the system calculates the iorate parameter for each subsequent test based on the proportion value in the datapoint, writes it to the test configuration file, and performs a new test. Assuming the maximum IOPS in the first test is 10000, the corresponding business load for each subsequent test will be 5000, 6000, 7000, 8000, 8500, 9000, 9100, etc. The system will continue this process until all IO test models and their corresponding datapoints defined in the user configuration file have been tested, thus completing multiple dynamic tests.
[0098] After the test is completed, the system will switch to the test results directory to analyze and process the test results, extract key information and generate visual charts, so that R&D personnel can view the maximum performance and quickly locate the point where the latency jumps, and find the balance point between IOPS and latency.
[0099] During this process, the system extracts valid data from the test results, including key test data from all test rounds under each IO test model, such as IO size, read / write ratio, read / write mode, latency, IOPS, etc. Figure 4 As shown, the system extracts the data of the maximum performance test rounds under each IO model, with each IO test model on a separate row, and displays it in the form of a table;
[0100] Simultaneously, the IOPS and latency under different business pressures for each IO test model are extracted. Using IOPS as the horizontal axis and latency as the vertical axis, the relationship between IOPS and latency is displayed in a line graph, such as... Figure 5 As shown, when IOPS exceeds 120,000, latency will increase sharply. We can basically determine that the optimal performance of the storage system is 120,000 IOPS.
[0101] Based on the above method, the optimal performance of the storage system can be obtained automatically and dynamically, which greatly improves the testing efficiency and accuracy. This process does not require R&D personnel to manually compare test results and adjust test pressure and parameters repeatedly. It is time-saving and efficient. At the same time, the test results do not need to be manually extracted and analyzed. They can be displayed more intuitively through visualization charts.
[0102] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.
[0103] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.
Claims
1. A method for dynamically obtaining the optimal performance of a storage system, characterized in that: Includes the following steps: S1: Write user configuration files according to the rules, which will serve as input for generating test tool configuration files later; S2: Obtain the CPU information of the test stress machine, determine and obtain the appropriate number of test threads based on the number of CPU threads, and write it into the user configuration file of S1; S3: Based on the user configuration file generated in S2, the corresponding test configuration file for the testing tool is generated by parsing and comparing with the conversion rules; S4: Automatically test by calling the corresponding test tool based on the test configuration file generated in S3; The step of S4 calling the corresponding testing tool to perform automatic testing includes the following steps: S41: The test system starts the test tool and loads the test configuration file according to the test tool specified in the user configuration file. The test tool is the vdbench tool. S42: Use the test configuration file generated in step S3 to perform a maximum performance test and test the maximum IOPS of the storage system. S43: The system performs multiple dynamic tests based on the value defined in the datapoint field of the user configuration file, and records the business pressure limit for each test. The business pressure limit is the product of the maximum IOPS and the value defined in the datapoint field. The value defined in the datapoint field in S43 is written into the test configuration file according to the conversion rules in S3. S5: Automatically process and analyze performance-related data in the test results to generate visual charts; S5 specifically includes the following steps: S51: The system switches to the test results directory and extracts valid data from the test results, including key test data from all test rounds under each IO test model; S52: Extract the data of the maximum performance test rounds under each IO model, with one row for each IO test model, and display it in the form of a table; The IOPS and latency under different business pressures for each IO test model are extracted, and the relationship between IOPS and latency is displayed in the form of a line chart with IOPS as the horizontal axis and latency as the vertical axis.
2. The method for dynamically obtaining the optimal performance of a storage system according to claim 1, characterized in that: The information in the configuration file of S1 includes the size of the IO block to be tested, the read / write mode, the read / write ratio, the path of the storage volume device to be tested, the absolute path of the test tool, the running time, and the data sampling points.
3. The method for dynamically obtaining the optimal performance of a storage system according to claim 1, characterized in that: The configuration file for S1 is saved in ini format and is divided into a global section and an rd section, with multiple rd sections.
4. The method for dynamically obtaining the optimal performance of a storage system according to claim 1, characterized in that: The method for obtaining the number of test threads in S2 includes: S21: Obtain the number of CPU cores of the test client according to Linux commands; S22: Use twice the number of CPU cores obtained in S21 as the number of threads and write it to the user configuration file.
5. The method for dynamically obtaining the optimal performance of a storage system according to claim 1, characterized in that: S3 specifically includes the following steps: S31: The system reads the user configuration files generated in S1 and S2; S32: Parse the user configuration files in S31 one by one according to the conversion rules. The conversion rules are the correspondence between the fields in the user configuration files and the fields in the configuration files of common storage performance testing tools. The conversion rules exist in the form of a dictionary; where the dictionary keys are the field names in the user configuration files and the values are the field names in the corresponding testing tool configuration files. S33: Generate the configuration file for the test tool in the user configuration file.
6. The method for dynamically obtaining the optimal performance of a storage system according to claim 1, characterized in that: The test duration for both the maximum performance test and the dynamic test is 300 seconds.
7. A system for dynamically acquiring the optimal performance of a storage system, characterized in that: include: The configuration generation module is used to read the CPU information on the test stress machine, determine the number of test threads and write them to the user configuration file. At the same time, it parses the user configuration file and generates the test configuration file of the corresponding test tool according to the configuration items in the template configuration file. The scheduling and execution module is used to call the corresponding test tool according to the test tool specified in the user configuration file and perform tests using the generated test configuration file. The process of calling the corresponding testing tool for automated testing includes the following steps: The testing system starts the testing tool and loads the testing configuration file according to the testing tool specified in the user configuration file. The testing tool is the vdbench tool. Use the generated test configuration file to perform a maximum performance test and determine the maximum IOPS of the storage system. The system performs multiple dynamic tests based on the value defined in the datapoint field of the user configuration file, and records the business pressure limit for each test. The business pressure limit is the product of the maximum IOPS and the value defined in the datapoint field. The value defined in the datapoint field is written into the test configuration file according to the conversion rules. The conversion rules are the correspondence between the fields in the user configuration file and the fields in the configuration files of commonly used storage performance testing tools. The conversion rules exist in the form of a dictionary. The logging module is used to record key steps and information during the operation process, making it easier to track and analyze problems. The results analysis module is used to process the test results, extract key performance information, and display the test data in the form of visual charts. The result parsing module is specifically used to perform the following steps: The system switches to the test results directory and extracts valid data from the test results, including key test data from all test rounds under each IO test model. Extract the data of the maximum performance test rounds under each IO model, and display it in the form of a table with one row for each IO test model. The IOPS and latency under different business pressures for each IO test model are extracted, and the relationship between IOPS and latency is displayed in the form of a line chart with IOPS as the horizontal axis and latency as the vertical axis.