Solid state disk-based performance testing method, device and computer equipment

Abstract

The application relates to a solid state disk-based multiple performance test method and device, computer equipment and a storage medium, wherein the method comprises the following steps: acquiring available space of a solid state disk to be tested, reserving at least 61 GB of test space in the available space, leaving the remaining available space idle for a period of time after filling the space with first random data once; reserving a certain size of space in the available space, leaving the remaining available space idle for a period of time after filling the space with second random data twice; in the baseline performance test data collection process, deleting redundant filling files to ensure that the available space is at least 55.4 GB, leaving the system cache file idle for a period of time after flushing, and performing application scene performance test in the test space until all application scene tests and test rounds are completed. The application realizes data collection on baseline performance, deteriorated performance, steady-state performance and recovered performance of the solid state disk to be tested.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive (SSD) testing technology, and in particular to a method, apparatus, computer device, and storage medium for various performance tests based on SSDs. Background Technology

[0002] The performance testing specifications for solid-state drives (SSDs) are primarily published and maintained by the SNIA (Storage Networking Industry Association). While the testing methods for consumer-grade and enterprise-grade SSDs differ slightly, both processes involve three phases: cleanup, pre-filling, and steady-state testing. Test items typically include steady-state performance, write saturation performance, recovery performance after host idle time, and the interaction performance between two recent loads. Each test is exceptionally long; for example, the interaction performance test model between two recent loads is specified to last 22 hours. When testing a 512GB SSD with an interface bandwidth of 8GB / s (4 lanes), the data write volume can reach tens of TB, which will severely shorten the SSD's lifespan. This testing specification only provides partial test reference code; there are no pure testing software solutions on the market that are entirely based on this specification. Without independent software development capabilities, one can only purchase the software and hardware solutions from the specification's partners. While these solutions are developed based on the specification and meet testing requirements, they are quite expensive, costing approximately 100,000-200,000 RMB.

[0003] Currently, a popular pure software testing solution in the industry is PCMark 10 performance testing software. Its StorageConsistency test has undergone some modifications based on the test items in the aforementioned specifications, such as adding a baseline performance test after disk filling and removing write saturation performance and the interactive performance tests of the two most recent loads, reducing the test time to 11-20 hours. Each test phase covers seven scenarios. When the tested SSD is 512GB and the interface bandwidth is 8GB / s (4 lanes), the test data write volume is 7.5TB, effectively mitigating the wear and tear on the SSD's lifespan. However, this software only supports Windows systems, and the test data only includes single-point data from each test phase. When performance does not meet expectations, it is impossible to view the detailed performance changes in each test phase. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, and storage medium for various performance tests based on solid-state drives (SSDs) to address the aforementioned technical problems.

[0005] A method for multiple performance tests based on solid-state drives, the method comprising:

[0006] Obtain the available space of the solid-state drive under test, reserve at least 61GB of test space within the available space, fill the remaining available space with the first random data and then leave it idle for a period of time;

[0007] Reserve a certain amount of space within the available space, fill the remaining available space twice with the second random data, and then leave it idle for a period of time.

[0008] During the baseline performance test data collection process, redundant filler files are deleted to ensure that there is at least 55.4GB of available space. After flushing the system cache files, the system is left idle for a period of time. Performance tests of application scenarios are then performed in the test space until all application scenario tests and test rounds are completed.

[0009] During the data collection process for degraded performance tests, a certain amount of space is reserved within the available space. The remaining space is left idle for a period of time after writing 1 minute of third random data multiplied by the current test round number or 50GB multiplied by the current round number. Performance tests of application scenarios are then conducted in the test space until all application scenario tests and test rounds are completed.

[0010] During the steady-state performance test data collection process, a certain amount of space is reserved within the available space. The other space is used to write third random data for 8 minutes or 400GB and then left idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0011] After a period of inactivity, during the performance recovery test data collection process, redundant files are deleted to ensure at least 55.4GB of free space. After flushing system cache files, the system is left idle for a period of time. Performance tests of application scenarios are then performed on this test space until all application scenario tests and test rounds are completed.

[0012] In one embodiment, the step of obtaining the available space of the solid-state drive under test further includes:

[0013] Determine if the available space is greater than 80GB. Only if it is greater than 80GB can the subsequent test steps be executed.

[0014] In one embodiment, after the idle period, during the performance recovery test data collection process, redundant files are deleted to ensure at least 55.4GB of available space. After flushing system cache files and remaining idle for a period of time, the step of performing application scenario performance tests on the test space further includes:

[0015] Clean up the test environment by writing 0 to all files within the available space and then deleting the files.

[0016] In one embodiment, the first random data is sequentially written, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

[0017] The second random data is written sequentially, with a queue depth of 10, 1 thread, and a block size of 128K.

[0018] The third random data is written randomly, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

[0019] A multi-performance testing device based on a solid-state drive, the device comprising:

[0020] The first disk filling module is used to obtain the available space of the solid-state drive under test, reserve at least 61GB of test space in the available space, and fill the remaining available space with the first random data and then leave it idle for a period of time.

[0021] The second filling module is used to reserve a certain amount of space within the available space, and fill the remaining available space twice with the second random data and then leave it idle for a period of time.

[0022] The first test module is used to delete redundant filler files during the baseline performance test data collection process to ensure that the available space is at least 55.4GB. After flushing the system cache files, the system is idle for a period of time. The application scenario performance test is then performed in the test space until all application scenario tests and test rounds are completed.

[0023] The second test module is used to reserve a certain amount of space within the available space during the test data collection process of deteriorating performance. The other space is used to write 1 minute of third random data multiplied by the current test round number or 50GB multiplied by the current round number and then left idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0024] The third test module is used to reserve a certain amount of space within the available space during the steady-state performance test data collection process. The other space is used to write third random data for 8 minutes or 400GB and then left idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0025] The fourth test module is used to idle for a period of time. During the performance recovery test data collection process, redundant files are deleted to ensure that the available space is at least 55.4GB. After flushing the system cache files, the module is idle for a period of time. Application scenario performance tests are performed in the test space until all application scenario tests and test rounds are completed.

[0026] In one embodiment, the device further includes a determining module, the determining module being used to:

[0027] Determine if the available space is greater than 80GB. Only if it is greater than 80GB can the subsequent test steps be executed.

[0028] In one embodiment, the apparatus further includes a cleaning module, the cleaning module being used for:

[0029] Clean up the test environment by writing 0 to all files within the available space and then deleting the files.

[0030] In one embodiment, the first random data is sequentially written, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

[0031] The second random data is written sequentially, with a queue depth of 10, 1 thread, and a block size of 128K.

[0032] The third random data is written randomly, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

[0033] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the methods described above.

[0034] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above methods.

[0035] The aforementioned performance testing methods, devices, computer equipment, and storage media based on solid-state drives (SSDs) can utilize the open-source tool FIO+ and the commands natively included in the operating system to perform space analysis on the SSD under test. This enables data collection of baseline performance, post-deterioration performance, steady-state performance, and post-recovery performance from the cleanup, filling, deterioration, steady-state stages to the recovery stage. Furthermore, it can combine the performance records per second to analyze the causes of anomalies. Attached Figure Description

[0036] Figure 1 This is a flowchart illustrating multiple performance testing methods based on solid-state drives in one embodiment;

[0037] Figure 2 This is a flowchart illustrating various performance testing methods based on solid-state drives in another embodiment;

[0038] Figure 3 This is a structural block diagram of a variety of performance testing devices based on solid-state drives in one embodiment;

[0039] Figure 4 This is a structural block diagram of a multi-performance testing device based on a solid-state drive in another embodiment;

[0040] Figure 5 This is a structural block diagram of a multi-performance testing device based on a solid-state drive in another embodiment;

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

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

[0043] Currently, a popular pure software testing solution in the industry is PCMark 10 performance testing software. Its StorageConsistency test has been modified based on the test items in the aforementioned specifications, with some additions and deletions. For example, a baseline performance test after disk filling has been added, while write saturation performance and the interactive performance tests of the two most recent loads have been removed, shortening the test time to 11-20 hours. Each test phase covers seven scenarios. When the tested SSD is 512GB and the interface bandwidth is 8GB / s, the test data write volume is 7.5TB, effectively mitigating the wear and tear on the SSD's lifespan. However, this software only supports Windows systems, and the test data only includes single-point data from each test phase. When performance does not meet expectations, it is impossible to view the detailed performance changes in each test phase.

[0044] Based on this, the present invention provides a variety of performance testing methods based on solid-state drives (SSDs), which are designed to perform performance testing and verification on SSDs during space analysis, disk filling, deterioration, steady state, and finally recovery stages.

[0045] In one embodiment, such as Figure 1 As shown, a variety of performance testing methods based on solid-state drives are provided, including:

[0046] Step 102: Obtain the available space of the solid-state drive under test, reserve at least 61GB of test space within the available space, fill the remaining available space with the first random data and then leave it idle for a period of time.

[0047] Step 104: Reserve a certain amount of space within the available space, fill the remaining available space twice with the second random data, and then leave it idle for a period of time.

[0048] Step 106: During the baseline performance test data collection process, delete redundant filler files to ensure that the available space is at least 55.4GB. After flushing the system cache files, leave the system idle for a period of time. Then, perform application scenario performance tests in the test space until all application scenario tests and test rounds are completed.

[0049] Step 108: During the process of collecting test data for deteriorating performance, a certain amount of space is reserved in the available space. The other space is left idle for a period of time after writing 1 minute of third random data multiplied by the current test round number or 50GB multiplied by the current round number. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0050] Step 110: During the steady-state performance test data collection process, a certain amount of space is reserved in the available space, and the other space is left idle for a period of time after writing 8 minutes or 400GB of third random data. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0051] Step 112: After a period of inactivity, during the performance recovery test data collection process, delete redundant files to ensure that the available space is at least 55.4GB. After flushing the system cache files, allow the system to remain idle for a period of time. Then, perform performance tests of application scenarios in the test space until all application scenario tests and test rounds are completed.

[0052] In this embodiment, a multi-performance testing method based on solid-state drives is provided. This method can use the open-source tool FIO+ and the commands natively provided by the operating system to perform space analysis on the solid-state drive under test, and collect data on the baseline performance, post-deterioration performance, steady-state performance and post-recovery performance of the disk from the cleanup, filling, deterioration, steady-state stage to the recovery stage.

[0053] It's worth noting that this tool supports testing on both Windows and Linux systems. Since consumer-grade SSDs are primarily used on Windows systems, this test only utilizes FIO in conjunction with PowerShell for Windows. This testing method supports both master and slave drives, and the testing time can be controlled within 6 hours. In addition to a summary, the test data for each stage includes performance records per second for each test stage. The script can also be run directly from a Linux terminal using PowerShell.

[0054] Specifically, the solid-state drive under test is first safely erased. If the drive under test is the primary drive, the operating system and drivers are installed. Except for the testing tools, no other software needs to be installed.

[0055] Next, the available space of the tested SSD was obtained. 61GB of the available space was reserved, and the remaining available space was filled with random data of 4K-1M block size using sequential write, queue depth 10, thread 1, and a process of 1000 threads. After that, the space was left idle for 5 minutes. Then, only 7.28GB of the available space was reserved, and the space was filled with random data of 128K block size using sequential write, queue depth 10, thread 1, and a process of 1000 threads. After that, the space was left idle for 40 seconds.

[0056] For baseline performance test data collection, first delete redundant files to ensure 55.4GB of free space, then flush the system cache and let it idle for 10 seconds. Use the reserved free space to perform performance tests on application scenarios, such as simulating the writing of 5 identical operating system image files.

[0057] For performance degradation test data collection, 8GB of available space is reserved. The remaining space is used for random writes with a queue depth of 10, 1 thread, and block size of 4k-1M, multiplied by the current test cycle number for 1 minute, or 50GB multiplied by the current cycle number (the latter has higher priority). After the space is full, it is idle for 10 seconds. The reserved available space is used for application scenario performance testing, such as simulating the writing of 5 identical operating system image files.

[0058] For steady-state performance test data collection, 8GB of available space is reserved. The remaining space is used for random writes (8 minutes or 400GB, with a queue depth of 10, 1 thread, and block size of 4KB-1MB, and priority given to the first available data) to write random data. After the space is full, it is idle for 10 seconds. The reserved available space is used for application scenario performance testing, such as simulating the writing of 5 identical operating system image files.

[0059] After a 5-minute idle period, performance test data collection was performed. First, redundant files were deleted to ensure 55.4GB of free space. The system cache was then flushed, followed by a 10-second idle period. The reserved free space was then used for performance testing of application scenarios, such as simulating the writing of five identical operating system image files.

[0060] Finally, clean up the test environment by writing 0 to all files in the available space and deleting the files.

[0061] In this embodiment, the open-source tool FIO+ and the commands natively provided by the operating system can be used to perform space analysis on the solid-state drive under test. This enables data collection on the baseline performance, post-deterioration performance, steady-state performance, and post-recovery performance of the drive from the cleanup, filling, deterioration, steady-state stage to the recovery stage. Furthermore, the performance records per second can be combined to analyze the causes of anomalies.

[0062] In one embodiment, the step of obtaining the available space of the solid-state drive under test further includes: determining whether the available space is greater than 80GB; if it is greater than 80GB, the subsequent test steps can be performed.

[0063] In one embodiment, after a period of inactivity, during the test data collection process for performance recovery, redundant files are deleted to ensure that the available space is at least 55.4GB. After flushing the system cache files and inactivity for a period of time, the step of conducting application scenario performance tests in the test space further includes: cleaning the test environment by writing 0 to all files in the available space and clearing the files.

[0064] In one embodiment, the first random data is sequentially written, with a queue depth of 10, a thread of 1, and a block size of 4K-1M; the second random data is sequentially written, with a queue depth of 10, a thread of 1, and a block size of 128K; and the third random data is randomly written, with a queue depth of 10, a thread of 1, and a block size of 4K-1M.

[0065] For specific details, please refer to Figure 2 The flowcharts shown below illustrate various performance testing methods based on solid-state drives. In this embodiment, a complete testing process is provided, and the testing environment is as follows:

[0066] Hardware Requirements: The computer under test is an ASUS Z690. For this computer, the method described in this embodiment is applicable to desktops, laptops, and other computers that support the M.2 PCIe interface; the specific model is not mandatory. The ASUS Z690 is preferred. The solid-state drive (SSD) under test is a consumer-grade SSD.

[0067] Software requirements: Operating system: Windows 11; Testing tool: FIO; Testing script: Self-written PowerShell script.

[0068] The specific testing procedure in this embodiment is as follows:

[0069] 1. After safely erasing the solid-state drive under test, if the drive under test is the primary drive, install the operating system and drivers. Except for the testing tools, no other software needs to be installed.

[0070] 2. Obtain the available space of the solid-state drive under test. The available space X must be greater than 80GB before the following test steps can be performed.

[0071] 3. Reserve 61GB (Y') within the available space, and fill the remaining available space Y with random data written sequentially, with a queue depth of 10, 1 thread, and a block size of 4K-1M, and then leave it idle for 5 minutes.

[0072] 4. Only 7.28GB is reserved in the available space. The space is then filled twice with random data of 128K block size in sequential write, queue depth 10, thread 1, and the space is left idle for 40 seconds.

[0073] 5. Baseline performance test data collection: First, delete unnecessary files to ensure available space is 55.4GB, flush the system cache and let it idle for 10 seconds.

[0074] 6. Use the Y' space from step 3 to perform performance tests on application scenarios, such as simulating the writing of 5 identical operating system image files.

[0075] 7. Determine whether the last application scenario test is completed and steps 5-6 above have been completed 3 times. If yes, proceed to step 8 for deterioration performance testing; otherwise, continue with steps 6-7.

[0076] 8. Collect test data that degrades performance. Reserve 8GB in the X space. Write random data for 1 minute multiplied by the current test cycle number or 50GB multiplied by the current cycle number in the other space with a queue depth of 10, 1 thread, and a block size of 4k-1M. After the space is full, leave it idle for 10 seconds.

[0077] 9. Perform performance tests on application scenarios in the Y' space of step 3, such as simulating the writing of 5 identical operating system image files.

[0078] 10. Determine whether the test of the last application scenario has been completed and whether steps 8-9 above have been completed 8 times. If yes, proceed to the steady-state performance test in step 10; otherwise, continue with steps 8-9.

[0079] 11. For steady-state performance test data collection, reserve 8GB in the X space, and use random writes, queue depth 10, thread 1, and block size of 4k-1M to write random data for 8 minutes or 400GB (the one that is satisfied first has higher priority). After the space is full, leave it idle for 10 seconds.

[0080] 12. Use the Y' space from step 3 to perform performance tests on application scenarios, such as simulating the writing of 5 identical operating system image files.

[0081] 13. Determine whether the test of the last application scenario has been completed and whether steps 11-12 above have been completed 3 times. If yes, proceed to step 14; otherwise, continue with steps 11-12.

[0082] 14. Leave idle for 5 minutes.

[0083] 15. To collect test data for performance recovery, first delete unnecessary files to ensure available space is 55.4GB, flush the system cache, and then let it idle for 10 seconds.

[0084] 16. Use the Y' space from step 3 to perform performance tests on application scenarios, such as simulating the writing of 5 identical operating system image files.

[0085] 17. Determine whether the test of the last application scenario is completed and whether steps 15-16 above have been completed 5 times. If yes, proceed to step 18; otherwise, continue with steps 15-16.

[0086] 18. Clean up the test environment by writing 0 to all files in the X space and deleting the files.

[0087] In the above embodiments, the FIO+PowerShell script can quickly and efficiently detect performance anomalies in the SSD's baseline performance, deteriorated performance, steady-state performance, and recovered performance, and combine the performance records per second to analyze the causes of the anomalies.

[0088] It should be understood that, although Figures 1-2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figures 1-2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0089] In one embodiment, such as Figure 3 As shown, a multi-performance testing device 300 based on a solid-state drive is provided, the device comprising:

[0090] The first disk filling module 301 is used to obtain the available space of the solid-state drive under test, reserve at least 61GB of test space in the available space, fill the remaining available space with the first random data and then leave it idle for a period of time.

[0091] The second filling module 302 is used to reserve a certain amount of space in the available space, fill the remaining available space twice with the second random data, and then leave it idle for a period of time.

[0092] The first test module 303 is used to delete redundant filler files to ensure that the available space is at least 55.4GB during the baseline performance test data collection process, and after flushing the system cache files, it is idle for a period of time, and then the performance test of the application scenario is performed in the test space until all application scenario tests and test rounds are completed.

[0093] The second test module 304 is used to reserve a certain amount of space within the available space during the test data collection process of deteriorating performance. The other space is left idle for a period of time after writing 1 minute of third random data multiplied by the current test round number or 50GB multiplied by the current round number. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0094] The third test module 305 is used to reserve a certain amount of space within the available space during the steady-state performance test data collection process. The other space is used to write third random data for 8 minutes or 400GB and then left idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0095] The fourth test module 306 is used to idle for a period of time. During the performance recovery test data collection process, redundant files are deleted to ensure that the available space is at least 55.4GB. After flushing the system cache files, it is idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed.

[0096] In one embodiment, such as Figure 4 As shown, a multi-performance testing device 300 based on a solid-state drive is provided. This device further includes a judgment module 307, which is used for:

[0097] Determine if the available space is greater than 80GB. Only if it is greater than 80GB can the subsequent test steps be executed.

[0098] In one embodiment, such as Figure 5 As shown, a multi-performance testing device 300 based on a solid-state drive is provided. This device also includes a cleaning module 308, which is used for:

[0099] Clean up the test environment by writing 0 to all files within the available space and then deleting the files.

[0100] In one embodiment, the first random data is sequentially written, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

[0101] The second random data is written sequentially, with a queue depth of 10, 1 thread, and a block size of 128K.

[0102] The third random data is written randomly, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

[0103] For specific limitations on various performance testing devices based on solid-state drives, please refer to the limitations on various performance testing methods based on solid-state drives mentioned above, which will not be repeated here.

[0104] In one embodiment, a computer device is provided, the internal structure of which can be shown as follows: Figure 6 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a multi-performance testing method based on a solid-state drive.

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

[0106] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps in the various method embodiments described above.

[0107] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the various method embodiments described above.

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

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

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

Claims

1. A method for testing various performance aspects based on a solid-state drive (SSD), the method comprising: Obtain the available space of the solid-state drive under test, reserve at least 61GB of test space within the available space, fill the remaining available space with the first random data and then leave it idle for a period of time; Reserve a certain amount of space within the available space, fill the remaining available space twice with the second random data, and then leave it idle for a period of time. During the baseline performance test data collection process, redundant filler files are deleted to ensure that there is at least 55.4GB of available space. After flushing the system cache files, the system is left idle for a period of time. Performance tests of application scenarios are then performed in the test space until all application scenario tests and test rounds are completed. During the data collection process for degraded performance tests, a certain amount of space is reserved within the available space. The remaining space is left idle for a period of time after writing 1 minute of third random data multiplied by the current test round number or 50GB multiplied by the current round number. Performance tests of application scenarios are then conducted in the test space until all application scenario tests and test rounds are completed. During the steady-state performance test data collection process, a certain amount of space is reserved within the available space. The other space is used to write third random data for 8 minutes or 400GB and then left idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed. After a period of inactivity, during the performance recovery test data collection process, redundant files are deleted to ensure that there is at least 55.4GB of available space. After flushing the system cache files, the system is left idle for a period of time. Performance tests of application scenarios are then conducted in the test space until all application scenario tests and test rounds are completed.

2. The multiple performance testing methods based on solid-state drives according to claim 1, characterized in that, The step of obtaining the available space of the solid-state drive under test also includes: Determine if the available space is greater than 80GB. Only if it is greater than 80GB can the subsequent test steps be executed.

3. The multiple performance testing methods based on solid-state drives according to claim 2, characterized in that, During the idle period, in the process of collecting test data to restore performance, redundant files are deleted to ensure at least 55.4GB of available space. After flushing system cache files and remaining idle for a period of time, the following steps are taken after performing application scenario performance tests on the test space: Clean up the test environment by writing 0 to all files within the available space and then deleting the files.

4. The multiple performance testing methods based on solid-state drives according to any one of claims 1-3, characterized in that, The first random data is written sequentially, with a queue depth of 10, 1 thread, and a block size of 4K-1M. The second random data is written sequentially, with a queue depth of 10, 1 thread, and a block size of 128K. The third random data is written randomly, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

5. A multi-performance testing device based on a solid-state drive, characterized in that, The device includes: The first disk filling module is used to obtain the available space of the solid-state drive under test, reserve at least 61GB of test space in the available space, and fill the remaining available space with the first random data and then leave it idle for a period of time. The second filling module is used to reserve a certain amount of space within the available space, and fill the remaining available space twice with the second random data and then leave it idle for a period of time. The first test module is used to delete redundant filler files during the baseline performance test data collection process to ensure that the available space is at least 55.4GB. After flushing the system cache files, the system is idle for a period of time. The application scenario performance test is then performed in the test space until all application scenario tests and test rounds are completed. The second test module is used to reserve a certain amount of space within the available space during the test data collection process of deteriorating performance. The other space is used to write 1 minute of third random data multiplied by the current test round number or 50GB multiplied by the current round number and then left idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed. The third test module is used to reserve a certain amount of space within the available space during the steady-state performance test data collection process. The other space is used to write third random data for 8 minutes or 400GB and then left idle for a period of time. The performance test of the application scenario is carried out in the test space until all application scenario tests and test rounds are completed. The fourth test module is used to idle for a period of time. During the performance recovery test data collection process, redundant files are deleted to ensure that the available space is at least 55.4GB. After flushing the system cache files, the module is idle for a period of time. Application scenario performance tests are performed in the test space until all application scenario tests and test rounds are completed.

6. The multi-performance testing device based on solid-state drives according to claim 5, characterized in that, The device further includes a judgment module, the judgment module being used for: Determine if the available space is greater than 80GB. Only if it is greater than 80GB can the subsequent test steps be executed.

7. The multi-performance testing device based on solid-state drives according to claim 6, characterized in that, The device further includes a cleaning module, the cleaning module being used for: Clean up the test environment by writing 0 to all files within the available space and then deleting the files.

8. The multi-performance testing device based on solid-state drives according to any one of claims 5-7, characterized in that, The first random data is written sequentially, with a queue depth of 10, 1 thread, and a block size of 4K-1M. The second random data is written sequentially, with a queue depth of 10, 1 thread, and a block size of 128K. The third random data is written randomly, with a queue depth of 10, 1 thread, and a block size of 4K-1M.

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

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

Images