Load testing method and system for storage device, and electronic device

Abstract

The application provides a load test method and system of a storage device and an electronic device, relates to the technical field of storage, and can obtain real use behaviors of a user by collecting access logs of the user on the storage device and preprocessing the access logs to obtain user behavior data, so as to avoid the defect that a general test case is separated from actual operation; features are extracted based on the user behavior data, and a user behavior portrait library is constructed, so as to accurately capture load tidal fluctuation characteristics and abnormal behavior patterns of user access and ensure the accuracy of test cases; and exclusive test cases containing tidal load test cases and abnormal behavior injection test cases are generated according to the portrait library, so as to simulate load fluctuations in actual use of the user, the abnormal behavior injection test cases match abnormal behavior characteristics in the portrait library, and sudden scenes in user operation can be reproduced, so that potential defects of the storage device under tidal load fluctuation and accidental abnormal behaviors are solved.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a load testing method and system for storage devices, and electronic equipment. Background Technology

[0002] Existing load testing methods for storage devices evaluate their performance by pre-setting standardized test cases. These pre-set standardized test cases typically employ averaged and standardized scenario presets. This approach uses averaged and standardized scenarios, which differ from actual user access behavior, leading to inaccurate test results. This results in significant deviations from real business performance or an inability to effectively identify potential defects in storage devices under load fluctuations and sudden anomalies. Furthermore, the lack of simulation of occasional abnormal behavior further weakens the comprehensiveness and practicality of load testing. Summary of the Invention

[0003] This application provides a load testing method, system, and electronic device for storage devices, which at least solves the problem in related technologies where load testing using pre-defined standardized test cases cannot simulate real user operations, resulting in test results that do not match the actual situation.

[0004] This application provides a load testing method for a storage device, including:

[0005] Collect access logs of target users on storage devices, preprocess the access logs, and obtain user behavior data;

[0006] Based on user behavior data, extract user behavior features to build a user behavior profile library;

[0007] Based on the user behavior profile library, generate user profile test cases for the target user. The user profile test cases include tidal load test cases that simulate load intensity changing over time and abnormal behavior injection test cases that simulate abnormal behavior characteristics.

[0008] Inject the load corresponding to the user profile test cases into the storage device under test, perform the test, and obtain the test results of the storage device under test.

[0009] This application also provides a load testing system for storage devices, including: a data acquisition module, an extraction module, a generation module, and a testing module;

[0010] The data collection module is configured to collect access logs of target users on storage devices, preprocess the access logs, and obtain user behavior data.

[0011] The extraction module is configured to extract user behavior features based on user behavior data to build a user behavior profile library.

[0012] The generation module is configured to generate user profile test cases for the target user based on the user behavior profile library. The user profile test cases include tidal load test cases and abnormal behavior injection test cases.

[0013] The testing module is configured to execute user profile test cases, inject the load corresponding to the user profile test cases into the storage device under test, and obtain the test results of the storage device under test.

[0014] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the load testing method of any of the above-described storage devices when executing the computer program.

[0015] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the load testing method for any of the above-described storage devices.

[0016] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the load testing method for any of the above-described storage devices.

[0017] This application provides a load testing method, system, and electronic device for storage devices. By collecting and preprocessing access logs of target users on the storage device to obtain user behavior data, it can capture real user behavior and avoid the defects of generic test cases that are divorced from actual user operations. Based on the user behavior data, features are extracted and a user behavior profile library is constructed, which can accurately capture the tidal fluctuation characteristics and abnormal behavior patterns of user access load, ensuring the accuracy of test cases. Dedicated test cases containing tidal load test cases and abnormal behavior injection test cases are generated according to the profile library. The tidal load test cases directly correspond to the user load fluctuation patterns extracted from the profile library, which can simulate the load fluctuations in actual user use. The abnormal behavior injection test cases match the abnormal behavior characteristics in the profile library, which can reproduce sudden scenarios in user operation, solving the potential defects of storage devices under tidal load fluctuations and occasional abnormal behavior. The user profile test cases are executed and the corresponding load is injected into the device under test, so that the test process fully matches the load characteristics and behavior patterns of real user use, ensuring the consistency between the test scenario and the actual business environment.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0019] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0020] Figure 1 A schematic flowchart illustrating a load testing method for a storage device provided in an embodiment of this application;

[0021] Figure 2 A flowchart illustrating another load testing method for a storage device provided in an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of the structure of a load testing system for a storage device provided in an embodiment of this application. Detailed Implementation

[0023] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0024] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0025] The specific application environment architecture or specific hardware architecture on which the load testing method for the storage device depends is described here.

[0026] Embodiments of this application provide a load testing method for a storage device. Figure 1 This is a flowchart illustrating a load testing method for a storage device provided in an embodiment of this application.

[0027] like Figure 1 As shown, the method includes the following steps:

[0028] Step 101: Collect the access logs of the target user on the storage device, preprocess the access logs to obtain user behavior data.

[0029] In the embodiments of this application, when collecting access logs for a target user's storage device, a combination of real-time monitoring and scheduled capture can be used to comprehensively collect logs generated by the user's use of the storage device. For example, file operation events can be captured in real time through the storage device's standard interface (such as SCSI protocol, NAS interface), while a historical log supplementation process (scheduled capture) is triggered every hour to cover offline or delayed logs, ensuring the integrity of data collection. Considering the diversity of storage device types, the collection process requires preprocessing the collected logs to ensure compatibility with log formats of different types of devices such as block storage, file storage, and object storage. During log collection, methods such as parsing the device's native logs (such as NTFS logs, EXT4 logs, S3 access logs) to extract unified fields can be used to solve the problem of log format differences in heterogeneous storage environments. The collected access logs cover three core categories: file operation records, including file size, operation type (read, write, delete, etc.), operation time, and operation frequency; concurrency information, including the number of users accessing the site at the same time and the number of IO requests; and abnormal behavior records, such as sudden IO events like more than 1,000 file writes within one minute or unexpected operations like cross-permission file access.

[0030] After data collection, the process enters the preprocessing stage. In this embodiment, the following exemplary processing methods may be used, but are not limited to: performing invalid data filtering, deleting duplicate records based on the triple key value of "file path + operation time + user ID", removing format errors in key fields such as missing operation time and file size, and filtering test records such as batch operations by administrator scripts through user permission identifiers; then performing standardization processing, converting the local time to UTC time accurate to milliseconds, and classifying file sizes into multiple categories according to preset thresholds based on preset file sizes (e.g., 4K, 1M, 100M); finally, performing data aggregation, statistically analyzing indicators such as file operation frequency, total IO requests, and peak concurrent users for each time period by hour, and marking abnormal behavior and associating it with the operation context based on preset thresholds, ultimately outputting structured user behavior data containing "time period - file type - operation type - concurrency indicator - anomaly marker".

[0031] By collecting all data and performing precise preprocessing, we ensure the integrity, accuracy, and standardization of user behavior data, providing a reliable data foundation for building accurate user behavior profiles and avoiding interference from invalid or distorted data in subsequent testing processes.

[0032] Step 102: Based on user behavior data, extract user behavior features to build a user behavior profile library.

[0033] In the embodiments of this application, based on the structured user behavior data output in step 101, feature extraction is carried out through statistical analysis or machine learning algorithms (such as cluster analysis) to construct a user behavior profile library. Feature extraction focuses on multiple core dimensions, such as: time feature dimension, defining peak load periods (e.g., 8:00-18:00) and off-peak periods (e.g., 0:00-6:00) based on aggregated data for different time periods, and calculating the duration and load percentage of each period (e.g., peak IO requests account for 70% of the total daily load); file feature dimension, analyzing the file size distribution (e.g., peak periods have 60% of files smaller than 4K and off-peak periods have 80% of files larger than 1G) and read / write ratio (e.g., peak write operations account for 70% and off-peak read operations account for 90%); concurrency feature dimension, extracting indicators such as average concurrent users, peak concurrent users, and IO request frequency (requests per second) for each period; and anomaly feature dimension, identifying anomaly types (e.g., IO storms), occurrence frequency (e.g., 1-2 times per month), duration (e.g., an average of 5 minutes), and load intensity (e.g., IO requests during anomalies are 5 times higher than normal periods). It should be noted that behavioral data reflecting user operations on storage devices includes multiple dimensions, and the aforementioned time feature dimension, file feature dimension, etc., data are merely illustrative and do not constitute a limitation on the scope of protection of this application.

[0034] The extracted feature parameters are stored in a structured format (such as a relational database, a type of database that stores data in a preset format and supports efficient querying) to form a user profile library. A dynamic update mechanism is established, for example, the features are iteratively updated every 7 days based on newly collected data to ensure that the profile matches the user's actual habits. Taking customer A as an example, the profile can accurately present information such as "peak hours from 9:00 to 22:00, 80% of write operations are small files under 4K, peak concurrency is 200 people, and 500 IO requests per second; there are 10-minute IO storms on the two monthly promotional days, with request volume 8 times that of normal."

[0035] It enables precise characterization of user storage habits, providing core data support for the subsequent generation of test cases that match actual scenarios, and solving the problem of test cases being out of touch with reality due to the lack of user behavior insights in traditional testing.

[0036] Step 103: Based on the user behavior profile library, generate user profile test cases for the target user. The user profile test cases include tidal load test cases that simulate load intensity changing over time and abnormal behavior injection test cases that simulate abnormal behavior characteristics.

[0037] In the embodiments of this application, the user profile test cases for generating target users are based on the time characteristics, file characteristics, concurrency characteristics and abnormal characteristics stored in the user behavior profile library. The test cases are constructed through parameterized generation logic to be highly matched with the actual storage and usage habits of the target users. The core includes two key contents: tidal load test cases and abnormal behavior injection test cases. For tidal load use cases, the system first accurately divides the peak and off-peak periods of the target user's load based on the time characteristics in the user profile database (e.g., in the A customer profile, 9:00-22:00 is the peak period and 22:00-9:00 the next day is the off-peak period). Then, it combines the file characteristics corresponding to each period (e.g., during the peak period, small file write operations account for 80%, and during the off-peak period, large file read operations account for 1G and above) and concurrency characteristics (during the peak period, 500 IO requests per second and a peak of 200 concurrent users; during the off-peak period, 50 IO requests per second and 20 concurrent users), and injects matching load parameters within the corresponding period. At the same time, to reproduce the natural fluctuation of the load in actual business, a load switching mechanism is designed at the boundary between the peak and off-peak periods. A gradual algorithm is used to achieve a smooth transition of load intensity (e.g., gradually increasing the IO request volume from 50 times / second to 500 times / second within 5 minutes), ultimately forming a tidal load use case where the load intensity dynamically changes over time. For abnormal behavior injection test cases, the generation is based on the abnormal features in the profile library, and automatically extracts key parameters such as abnormal type (e.g., IO storm), occurrence frequency (e.g., twice a month), duration (e.g., 10 minutes), and load intensity (e.g., 8 times that of normal periods). Abnormal scenarios that match the features are randomly inserted into the runtime sequence of tidal load test cases (e.g., inserting an IO storm scenario lasting 10 minutes with IO requests reaching 4000 times / second at 15:00 during customer A's peak period). At the same time, it supports users to manually customize abnormal parameters, including abnormal type, occurrence time, load intensity, etc., to further improve the flexibility and accuracy of abnormal scenario simulation.

[0038] The generated test cases accurately replicate the actual load fluctuation patterns and abnormal scenario characteristics of users, solving the problem of scenario distortion caused by the "averaging" of traditional general test cases, and providing scenario support that fits the real business for subsequent testing.

[0039] Step 104: Inject the load corresponding to the user profile test case into the storage device under test, and obtain the test results of the storage device under test.

[0040] A connection is established with the storage device under test through a standard interface of the storage device (such as SCSI protocol or NAS interface). Then, based on the actual deployment environment of the target user, the test environment parameters are precisely configured, including key configurations such as network bandwidth (such as 10Gbps bandwidth matching the user's business) and device cache size (such as 8GB cache consistent with the user's actual use), to ensure the consistency between the test environment and the user's real usage scenario, laying the foundation for the authenticity of the load test.

[0041] In the embodiments of this application, after the environment is ready, the load injection process is started: strictly following the timing logic of the user profile test cases, the concurrent access behavior of the target user is simulated through multi-threading technology, and corresponding types of IO requests are sent to the storage device under test. For the tidal load test case, 200 concurrent threads are started during peak hours (such as 9:00-22:00 for customer A) to send 4K small file write requests at a frequency of 500 times per second; during off-peak hours (22:00-9:00 the next day), the number of concurrent threads is switched to 20 to send large file read requests of more than 1G at a frequency of 50 times per second, and the load is smoothly switched by adjusting the number of threads at the boundary of the time period; for the abnormal behavior injection test case, when the preset abnormal time point is reached (such as 15:00), the thread request frequency is instantly increased to simulate an IO storm scenario of 4000 times per second for 10 minutes.

[0042] Throughout the load injection process, test result data from the storage device under test is collected in real time at a preset sampling frequency. The collected metrics include performance metrics (response time, throughput), resource usage metrics (CPU utilization, cache hit rate), and stability metrics (error rate, number of failures), etc. All data is stored in a structured format in real time. If a device times out or becomes unresponsive during the test, the system automatically records the time of the failure, the load intensity at that time (such as IO request volume, number of concurrent threads), and other contextual information. At the same time, it triggers the fault tolerance mechanism to attempt to restart the test process or skip the failure period to continue the test, ensuring the integrity of the test results.

[0043] By accurately replicating the injection method of actual user load scenarios and collecting full-dimensional indicators, the obtained test results can truly reflect the actual performance of the device under tidal loads and abnormal scenarios, providing reliable data support for subsequent result analysis and optimization suggestions.

[0044] This application provides a load testing method for storage devices. By collecting and preprocessing access logs of target users on the storage device to obtain user behavior data, it can capture real user behavior and avoid the defects of generic test cases that are divorced from actual user operations. Based on the user behavior data, features are extracted and a user behavior profile library is constructed, which can accurately capture the tidal fluctuation characteristics and abnormal behavior patterns of user access load, ensuring the accuracy of test cases. Dedicated test cases containing tidal load test cases and abnormal behavior injection test cases are generated according to the profile library. The tidal load test cases directly correspond to the user load fluctuation patterns extracted from the profile library, which can simulate the load fluctuations in actual user use. The abnormal behavior injection test cases match the abnormal behavior characteristics in the profile library, which can reproduce sudden scenarios in user operation, solving the potential defects of storage devices under tidal load fluctuations and occasional abnormal behavior. The user profile test cases are executed and the corresponding load is injected into the device under test, so that the test process fully matches the load characteristics and behavior patterns of real user use, ensuring the consistency between the test scenario and the actual business environment.

[0045] The embodiments listed above do not constitute a limitation on the scope of protection of this application. That is, in addition to the embodiments described above, other embodiments that can be obtained by those skilled in the art based on the technical content disclosed in this application through reasonable logical analysis, reasoning, or limited experimentation should also be covered within the scope of protection of this application. This application also provides another embodiment, such as... Figure 2 As shown, this embodiment includes the following steps:

[0046] Step 201: Capture access logs by listening to the storage device interface and periodically retrieve access logs.

[0047] Specifically, this step employs a dual-mode approach combining real-time monitoring and scheduled capture to collect access logs. Real-time monitoring is implemented through standard interfaces on storage devices, such as the SCSI protocol interface for block storage data interaction and the NAS interface adapted for file sharing scenarios. It continuously captures various operation events occurring on the device, including file read / write, deletion, and backup, ensuring that every storage access behavior is recorded in real time. Simultaneously, to avoid log omissions caused by offline generation or transmission delays, a scheduled capture mechanism is initiated, automatically triggering a historical log supplementation process every hour. This retrieves log entries not captured in real-time through the device's preset log storage path. Furthermore, for different types of storage devices, such as block storage, file storage, and object storage, their native log formats (e.g., NTFS file system logs, EXT4 file system logs, S3 access logs for object storage) are parsed to extract unified core fields such as "file path, operation time, user ID, and file size." This addresses the issue of log format differences in heterogeneous storage environments and achieves standardized collection of multi-source logs.

[0048] Dual-mode acquisition ensures log integrity, and multi-source adaptation enables unified acquisition of logs across devices, providing a comprehensive and reliable raw data foundation for subsequent data cleaning and feature extraction.

[0049] Step 202: Clean the access logs to filter out invalid data.

[0050] Specifically, in this step, the collected access logs undergo data cleaning. The core objective is to filter out invalid data to ensure the accuracy of subsequent data processing, achieved through three types of rules. For duplicate records, a triple key-value combination of "file path + operation time + user ID" is used for deduplication. Records of duplicate operations performed on the same file by the same user at the same time are identified as redundant data and deleted, as these duplicate records do not add effective information to the behavior description and instead lead to data redundancy. For entries with incorrect formats, a field validation mechanism is used to remove records lacking key information, such as log entries missing core fields like "operation time" or "file size." Such data is worthless because it cannot support subsequent feature extraction (such as time period segmentation and file type statistics). In addition, test operation records also need to be filtered. User permission identifiers are used to distinguish between non-real business behaviors such as batch script operations manually executed by administrators, preventing such manual test data from interfering with the judgment of actual user habits. During the cleaning process, all filtered data is marked with the reason and logged to ensure the traceability of the cleaning operation.

[0051] By accurately filtering duplicate, incomplete, and test data, the quality of access logs is significantly improved, providing clean and effective data input for subsequent standardization processing and feature extraction.

[0052] Step 203: Standardize the cleaned access logs to obtain user behavior data.

[0053] Specifically, in this step, the standardization process takes the cleaned access logs as input and focuses on unifying and standardizing two key data categories: time format and file size, ultimately forming structured user behavior data. Regarding time format standardization, to address potential differences in local time (such as CST, China Standard Time) formats in the logs, a time conversion algorithm is used to uniformly convert them to Coordinated Universal Time (UTC) with millisecond-level precision. This unified format facilitates subsequent time-zone analysis and data comparison, avoiding errors in time feature extraction caused by time zone discrepancies. Regarding file size standardization, based on a preset threshold system (4K, 1M, 100M), the file size values ​​recorded in the logs are mapped to four standardized categories: "below 4K," "4K-1M," "1M-100M," and "above 100M." This tiered processing simplifies the dimensions of subsequent file feature extraction and reduces data computation complexity. After standardization, the output data is structured and integrated based on the dimensions of "time period - file type - operation type - concurrency index" to ensure that cleaned logs from different sources and in different formats form a unified and standardized user behavior data format, providing a consistent data foundation for subsequent anomaly labeling and feature extraction.

[0054] By standardizing and regulating time and file size, interference caused by differences in data format is eliminated, ensuring the consistency and standardization of user behavior data, and providing key support for the accuracy of subsequent multidimensional feature extraction.

[0055] Step 204: Based on a preset anomaly threshold, mark the data in the user behavior data as anomalies.

[0056] Specifically, in this step, the standardized user behavior data obtained in step 203 is used as the processing object, and anomaly marking is carried out based on preset multi-dimensional anomaly thresholds. The preset anomaly thresholds are set in combination with typical anomaly scenarios in the actual use of storage devices, covering two core dimensions: one is the load intensity threshold, for example, setting "more than 1,000 IO requests within 1 minute" as the standard for judging sudden IO, and this threshold is determined based on the statistical upper limit of the IO request frequency during normal business hours of most enterprises; the other is the operation permission threshold, which includes unexpected behaviors such as "cross-permission file access" and "unauthorized batch operations" in the scope of anomaly judgment, and is identified by comparing the operation user permission identifier with the file access permission configuration.

[0057] In practice, structured user behavior data is scanned and compared in real time: when the frequency of IO requests in a certain period reaches or exceeds the load intensity threshold, the data for that period is immediately marked as "sudden IO anomaly"; when an operator's access behavior is detected to exceed permission restrictions, the corresponding operation record is marked as "permission anomaly". Simultaneously, to retain complete background information of the abnormal behavior, the corresponding operation context must be associated with the marker, including key data such as the operator's ID, file path, operation time, and the number of concurrent users at that time. This ensures that each anomaly marker is accompanied by traceable scenario information, and the final output includes marked user behavior data containing "anomaly type - occurrence time - associated context".

[0058] By setting precise thresholds and using context-related markers, we can effectively identify and retain abnormal information in user behavior data, providing accurate data support for the generation of abnormal features in subsequent multi-dimensional feature extraction, and ensuring the accuracy of user behavior profiles in depicting abnormal scenarios.

[0059] Step 205: Extract multidimensional features from user behavior data using a clustering algorithm to generate multidimensional feature parameters, including time features, file features, concurrency features, and anomaly features.

[0060] Furthermore, regarding the operation of "extracting multi-dimensional features from user behavior data using clustering algorithms to generate multi-dimensional feature parameters," there are various feasible implementation methods. To ensure a clear and complete explanation of the technical solution disclosed herein, the following implementation methods are merely exemplary and do not constitute a limitation on the scope of protection of this disclosure. The following specifically describes some exemplary implementation methods: classifying the time data in the user behavior data to divide the peak and off-peak periods of load on the storage device to generate time features; obtaining the file size distribution within the peak and off-peak periods, and obtaining the read / write operation ratios within the peak and off-peak periods to generate file features; collecting the average number of concurrent users, the peak number of concurrent users, and the read / write request frequency within the peak and off-peak periods to generate concurrency features; and analyzing the user behavior data to identify data with abnormal behavior to generate abnormal features.

[0061] Specifically, in this step, user behavior data marked with anomalies is used as input. A clustering algorithm (a machine learning method that aggregates similar data points into categories, used here to uncover hidden behavioral patterns in the data) is used to extract multidimensional features, generating multidimensional feature parameters containing time, file, concurrency, and anomaly characteristics. The specific implementation is as follows: For time feature generation, the "time period-load intensity" data in the user behavior data is used as clustering samples. The clustering algorithm aggregates time periods with similar load intensity into two categories, defining them as peak periods (e.g., 8:00-18:00) and off-peak periods. Then, the duration and load percentage of the two types of time periods are calculated (e.g., peak IO requests account for 70% of the total daily load), forming the time feature; for file features… The system uses clustering to divide peak and trough periods, statistically analyzing the distribution ratio of standardized file sizes (below 4K, above 1M, etc.) within each period, and calculating the difference in the proportion of read and write operations (e.g., 70% write operations during peak periods and 90% read operations during trough periods), integrating these to generate file features. For concurrency feature extraction, it collects and calculates indicators such as average concurrent users, peak concurrent users, and read / write request frequency per second (total IO requests / period duration) for the two types of periods, forming concurrency features. Anomaly features are generated by clustering labeled abnormal data and extracting common parameters such as anomaly type (e.g., IO storm), occurrence frequency (1-2 times per month), duration (average 5 minutes), and load intensity (abnormal IO is 5 times that of normal).

[0062] By leveraging clustering algorithms to mine patterns in behavioral data, we can accurately extract multi-dimensional feature parameters, providing core data support for building a user behavior profile library that closely reflects reality.

[0063] Step 206: Store the multidimensional feature parameters of the target user in a preset database according to a preset structure to build a user behavior profile library.

[0064] Specifically, in this step, a user behavior profile database is constructed using the target user's multi-dimensional feature parameters (time features, file features, concurrency features, and anomaly features) generated in step 205 as core data, and stored in a preset database according to a preset structure. The preset database is a relational database (a type of database that organizes data through tables, rows, and columns and supports structured queries and relational operations) to meet the structured storage requirements of the feature parameters; the preset structure designs data table fields based on the core attributes of the four types of features. For example, time features correspond to fields such as "peak hours, off-peak hours, and peak load percentage"; file features correspond to fields such as "peak file size distribution, off-peak file size distribution, and peak read / write ratio"; concurrency features correspond to fields such as "average concurrent users, peak concurrent users, and IO request frequency"; and anomaly features correspond to fields such as "anomaly type, occurrence frequency, duration, and load intensity". At the same time, "user ID and feature update timestamp" fields are added for user identification and update tracking. During storage, various characteristic parameters of the target user are mapped to corresponding fields one by one. For example, parameters such as "peak hours 9:00-22:00 for customer A, 80% of files are under 4K, peak concurrency is 200 users, and there are 2 IO storms per month" are filled into the corresponding fields to form a complete data record. In addition, to adapt to changes in user behavior, the data table is associated with a dynamic update mechanism. Old data is identified by "feature update timestamps," and historical records are replaced every 7 days based on newly generated multi-dimensional feature parameters to ensure that the user profile database is synchronized with the actual user habits.

[0065] Through structured storage and dynamic update mechanisms, the system enables standardized management and real-time iteration of multi-dimensional feature parameters. The constructed user behavior profile library accurately and continuously matches user habits, providing stable and reliable feature support for the generation of subsequent test cases.

[0066] Step 207: Generate tidal load test cases based on file characteristics and concurrency characteristics during peak hours and during off-peak hours.

[0067] Specifically, in this step, the generation of tidal load test cases is based on the file characteristics and concurrency characteristics of peak and off-peak periods in the user behavior profile library. This is achieved through precise mapping between feature parameters and load test case parameters. First, based on time characteristics, the time period division framework of the test cases is defined, dividing the test case execution cycle into peak test periods and off-peak test periods to ensure consistency with the actual load time patterns of the target users. For the peak test period, key parameters from the file characteristics are extracted—file size distribution ratio (e.g., 80% of files are smaller than 4K) and read / write operation ratio (e.g., 70% of write operations). At the same time, core indicators from the concurrency characteristics—peak concurrent users (e.g., 200 users) and IO request frequency (e.g., 500 times per second)—are retrieved. These parameters are then transformed into load injection rules, namely, "continuously inject small files smaller than 4K during peak periods, with 70% of write operations, simulating 200 concurrent users, and sending 500 IO requests per second." For off-peak testing periods, corresponding characteristic parameters were also matched: based on the file characteristics of "80% of files larger than 1GB and 90% of read operations," combined with the concurrency characteristics of "an average of 20 concurrent users and 50 IO requests per second," a load rule was formulated to "inject large files larger than 1GB during off-peak periods, with 90% of read operations, simulating 20 concurrent users and sending 50 IO requests per second." Finally, the load rules for peak and off-peak periods were concatenated in chronological order to form a tidal load test case where the load intensity alternates with time periods, fully replicating the peak-to-valley fluctuation pattern of actual user storage access.

[0068] By directly mapping the file and concurrency characteristics of users during real time periods, the generated tidal load test cases accurately reproduce the load fluctuation characteristics in actual business, solving the problem of scenario distortion caused by the "averaging" of traditional general test cases, and providing load scenario support that fits the real business for subsequent testing.

[0069] Step 208: At the boundary between peak and off-peak hours, generate load switching use cases with gradually changing load intensity.

[0070] Specifically, in this step, the load switching use cases that generate gradual load intensity changes are based on the characteristic parameters of peak and off-peak periods in the user behavior profile library, with a core focus on the design of a smooth load transition at the boundary between the two periods. First, key characteristic boundary values ​​of peak and off-peak periods are extracted from the profile library, including IO request frequency in concurrency characteristics (e.g., 50 times / second at the end of the off-peak period and 500 times / second at the beginning of the peak period), peak concurrent user count (e.g., 20 users at the end of the off-peak period and 200 users at the beginning of the peak period), and file size distribution ratio in file characteristics (e.g., 80% of files larger than 1GB at the end of the off-peak period and 80% of files smaller than 4KB at the beginning of the peak period), and read / write operation ratio (e.g., 90% of read operations at the end of the off-peak period and 70% of write operations at the beginning of the peak period). At the same time, combined with the duration pattern of natural load changes in actual business, a boundary transition period (e.g., 5 minutes) is preset. Subsequently, based on a linear gradient algorithm (a gradient method that maintains a stable rate of parameter change), the unit-time increment of each characteristic parameter is calculated: the IO request frequency is calculated based on 5 minutes and 300 seconds, requiring an increase of (500-50) / 300=1.5 times per second; the number of concurrent users needs to increase by (200-20) / 300=0.6 people per second; the file size distribution ratio is adjusted by a gradient of (80%-20%) / 300 per second, and the read / write operation ratio switches synchronously at a rate of (70%-10%) / 300 per second. When generating test cases, these gradient parameters are broken down into second-level execution instructions according to the time series to ensure that parameters such as IO request frequency, number of concurrent users, file type ratio, and read / write ratio increase or decrease synchronously and smoothly within the boundary period, avoiding sudden load changes. For example, when transitioning from a low point to a high point, the use case instructions are: "Second 1: 51.5 IO requests / second, 20.6 concurrent users, 79.8% of files larger than 1GB, and 89.8% of read operations; Second 2: 53 IO requests / second, 21.2 concurrent users, 79.6% of files larger than 1GB, and 89.6% of read operations... Second 300: 500 IO requests / second, 200 concurrent users, 80% of files smaller than 4KB, and 70% of write operations," ultimately forming a load switching use case with gradually changing load intensity.

[0071] By simulating the natural gradual change of load in real business operations, the test scenario distortion caused by sudden load changes is avoided. It can accurately verify the stability and adaptability of the equipment at the critical point of load fluctuation, and provide a more realistic test basis for equipment performance evaluation.

[0072] Step 209: Based on the abnormal characteristics, insert simulated abnormal test cases at preset time points, and modify the simulated abnormal test cases to generate abnormal behavior injection test cases based on the abnormal parameters set in the received data.

[0073] Specifically, in this step, the generation of abnormal behavior injection test cases is based on the abnormal features in the user behavior profile library, combined with user-defined parameters to complete precise construction. First, the core parameters of the abnormal features of the target user are extracted from the user behavior profile library, including the abnormal type (such as IO storm, cross-permission file access, sudden batch file upload, etc.), historical occurrence frequency (such as twice a month), duration (such as an average of 10 minutes), and load intensity (such as IO request volume being 8 times that of normal periods during an abnormality). These parameters constitute the initial template basis for simulating abnormal test cases. Then, the preset time point is determined based on the storage device load characteristics—prioritizing peak periods (such as 15:00 within 9:00-22:00 marked in the profile library, when the load is dense and it is easier to expose device defects). The initial simulated abnormal test cases are inserted into this time point to form basic test cases (such as "starting an IO storm simulation lasting 10 minutes at 15:00, with an IO request frequency of 4000 times / second").

[0074] Based on this, the system receives manually set exception parameters from the user. Adjustable dimensions include exception type (e.g., changing IO storm to file deletion storm), occurrence time (e.g., adjusting to 16:30), load intensity (e.g., increasing to 10 times the normal period), and duration (e.g., extending to 15 minutes). The system then modifies the basic simulated exception test cases according to the received parameters. For example, it replaces "IO storm" with "file deletion storm," adjusts the IO request frequency to 5000 times / second, and updates the duration to 15 minutes, ultimately generating exception behavior injection test cases that fit the user's actual needs and custom scenarios.

[0075] It not only relies on historical anomaly characteristics to ensure the authenticity of test cases, but also improves the flexibility of scenarios through user-defined parameters, comprehensively covering real and personalized anomaly scenarios, and solving the problem of insufficient anomaly coverage in traditional testing.

[0076] Step 210: Perform test case parameterization on the tidal load test cases, load switching test cases, and abnormal behavior injection test cases to generate user profile test cases.

[0077] Specifically, in this step, test case parameterization is based on tidal load test cases, load switching test cases, and abnormal behavior injection test cases. Standardization and integration are achieved by extracting core variables and establishing parameter mapping rules, ultimately generating User Profile Test Cases (UPTC). In practice, the key execution attributes of each test case are first extracted as parameters: For tidal load test cases, peak / valley time range, file size distribution ratio in each time period (e.g., peak percentage of files smaller than 4K) and read / write operation ratio (e.g., valley percentage of read operations) are extracted as independent parameters, along with the number of concurrent users (e.g., peak concurrent users) and IO request frequency (e.g., valley IO frequency). For load switching test cases, parameters such as transition period (e.g., load transition duration) and the rate of change of each parameter (e.g., IO frequency increment per second) are extracted. For abnormal behavior injection test cases, abnormal type (e.g., abnormal type), occurrence time (e.g., abnormal trigger time) and duration (e.g., abnormal duration) and load intensity multiple (e.g., abnormal load multiple) are set as adjustable parameters.

[0078] Subsequently, a parameter association mechanism is established to ensure the logical consistency of parameters across different test cases: for example, the {starting IO frequency} of a load switching test case is associated with the {end-of-valley IO frequency} of a tidal load test case, and the {ending IO frequency} is associated with the {peak-starting IO frequency} of a tidal load test case; the {abnormal trigger time} of an abnormal behavior injection test case must fall within a preset time period (such as {peak period}) of the tidal load test case. Finally, all parameterized test case fragments are concatenated in a time sequence and stored in a structured format (such as a script template containing parameter placeholders) to form user profile test cases containing "time period parameters - load parameters - switching parameters - abnormal parameters". Parameter values ​​can be directly associated with the user behavior profile library for dynamic calls.

[0079] Parameterization frees test cases from fixed numerical limitations, allowing them to automatically adapt to parameter changes as the user behavior profile database is updated, eliminating the need to redesign test cases. This also improves the flexibility and reusability of test cases, ensuring dynamic matching between test scenarios and user habits.

[0080] Step 211: Execute the preset test cases, inject load into the storage device under test, and collect the performance indicators of the storage device under test to obtain the test results.

[0081] Specifically, this step begins with initializing the test environment. A stable connection is established with the storage device under test via standard interfaces (such as SCSI protocol or NAS interface). Then, based on the target user's actual deployment scenario, core environmental parameters such as network bandwidth and device cache size are precisely configured to ensure the test environment closely matches the user's real-world usage scenario, laying the foundation for the authenticity of the load injection. After initialization, the execution flow of preset test cases is initiated—planned according to the test case sequence, using multi-threading technology to simulate concurrent user behavior and inject load into the device under test in a targeted manner: for tidal load segments, requests are sent according to preset file types, read / write ratios, and IO frequencies during the corresponding time periods; for load switching segments, the load intensity is smoothly adjusted according to gradual parameters; and for abnormal injection segments, a sudden load is triggered at preset time points.

[0082] Throughout the load injection process, performance metrics of the device under test are collected in real time at a sampling frequency of once per second, covering core performance metrics (response time, throughput), resource usage metrics (CPU utilization, cache hit rate), and stability metrics (error rate, number of failures). All collected data is stored immediately in structured formats (such as JSON and CSV) to ensure traceability of metrics. If a device times out or becomes unresponsive during the test, the system automatically records the time of the failure, the load intensity at that time (such as IO request volume, number of concurrent threads), and other contextual information, and triggers a fault tolerance mechanism to attempt to restart the test process or skip the failure period to continue execution, ensuring the integrity of the test results.

[0083] By adapting to the environment and injecting precise loads, combined with the collection of indicators across all dimensions and at high frequency, the test results obtained can truly reflect the performance and stability of the device under preset scenarios, providing reliable data support for subsequent comparative analysis of results.

[0084] Step 212: Compare and analyze the test results of the user profile test cases with the test results of the preset test cases, and output an analysis report and optimization suggestions.

[0085] Specifically, this step involves a comparative analysis of the test results of User Profile Test Cases (UPTC) and preset test cases (General Test Cases GTC). The analysis focuses on three dimensions: performance, stability, and anomaly handling capability, leading to the output of an analysis report and optimization suggestions. First, the core test data for both types of test cases is analyzed: UPTC data reflects the device's performance under actual user load and real-world anomaly scenarios, while GTC data reflects the device's performance under standardized average scenarios.

[0086] In terms of performance differences, key metrics such as response time and throughput are compared. For example, the average response time of UPTC during peak hours is 30ms, while the average response time of GTC is 15ms. The performance gap between real-world and general scenarios is quantified by the data difference and its proportion. In terms of stability differences, the frequency of device failures (such as timeouts and cache overflows) under the two types of use cases is statistically analyzed. If UPTC experiences two cache overflows while GTC has no failures, the stability weakness is clearly marked. In terms of anomaly handling capability, the device performance during anomaly injection periods in UPTC is focused on. The metric fluctuations in GTC under anomaly-free scenarios are compared. For example, during an IO storm, the throughput of UPTC drops by 50%, while GTC remains unchanged, thus identifying the device's deficiencies in handling sudden loads.

[0087] The analysis report is presented in a visual format, including response time comparison curves, failure count statistics tables, and indicator change graphs during abnormal periods, supplemented by textual explanations of the core causes of the differences. Optimization recommendations are specifically provided: for insufficient performance, it is recommended to "increase the read cache capacity to 16GB and enable the small file aggregation write mechanism"; for insufficient stability, it is suggested to "optimize the IO scheduling algorithm and add a load prediction module"; for weak anomaly handling, it is recommended to "configure an SSD cache pool and perform burst writes to the temporary cache".

[0088] By making quantitative comparisons, we can identify the shortcomings of equipment in adapting to real-world scenarios and provide targeted suggestions that offer direct basis for enterprises to optimize storage configurations, thus solving the problem of insufficient practicality of traditional test results.

[0089] It should be noted that the embodiments of this disclosure may include multiple steps. For ease of description, these steps are numbered, but these numbers are not a limitation on the execution time slots or execution order between the steps; these steps can be implemented in any order, and the embodiments of this disclosure do not limit this.

[0090] Corresponding to the above-described load testing method for storage devices, this application also proposes a load testing system for storage devices. Since the system embodiments of this application correspond to the method embodiments described above, details not disclosed in the system embodiments can be referred to the method embodiments described above, and will not be repeated here.

[0091] Figure 3 This is a schematic diagram of the structure of a load testing system for a storage device provided in an embodiment of this application, as shown below. Figure 3 As shown, it includes: acquisition module 21, extraction module 22, generation module 23, and testing module 24.

[0092] The acquisition module 21 is configured to collect access logs of the target user on the storage device, preprocess the access logs, and obtain user behavior data.

[0093] Extraction module 22 is configured to extract user behavior features based on user behavior data to build a user behavior profile library;

[0094] The generation module 23 is configured to generate user profile test cases for the target user based on the user behavior profile library. The user profile test cases include tidal load test cases and abnormal behavior injection test cases.

[0095] Test module 24 is configured to execute user profile test cases, inject the load corresponding to the user profile test cases into the storage device under test for testing, and obtain the test results of the storage device under test.

[0096] It should be noted that the foregoing explanation of the method embodiments also applies to the system principle of this embodiment, and is not limited thereto in this embodiment.

[0097] For a description of the features in the embodiment corresponding to the load testing system for the storage device, please refer to the relevant description of the embodiment corresponding to the load testing method for the storage device, which will not be repeated here.

[0098] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the load testing method for a storage device.

[0099] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described XX method embodiments when it is run.

[0100] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0101] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the load testing method for storage devices.

[0102] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the load testing method for storage devices.

[0103] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0104] The above provides a detailed description of the load testing method, system, and electronic device for a storage device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A load testing method for a storage device, characterized in that, include: The system collects access logs of target users on storage devices, preprocesses the access logs to obtain user behavior data, including: capturing access logs by listening to the storage device interface and periodically capturing access logs; cleaning the access logs to filter out invalid data; and standardizing the cleaned access logs to obtain the user behavior data. Based on the user behavior data, extracting user behavior features to construct a user behavior profile library includes: extracting multi-dimensional features from the user behavior data using a clustering algorithm to generate multi-dimensional feature parameters, including time features, file features, concurrency features, and anomaly features; storing the multi-dimensional feature parameters of the target user in a preset database according to a preset structure to construct and generate the user behavior profile library. The step of extracting multidimensional features from the user behavior data using a clustering algorithm to generate multidimensional feature parameters includes: The time data in the user behavior data is classified to divide the peak and off-peak periods of the load on the storage device, so as to generate the time features; The file size distribution during peak and off-peak periods is obtained, and the read / write operation ratio during the peak and off-peak periods is obtained to generate the file characteristics. The average number of concurrent users, peak number of concurrent users, and read / write request frequency during peak and off-peak periods are collected to generate the concurrency characteristics. The user behavior data is analyzed to identify data with abnormal behavior, and the abnormal features are generated accordingly. Based on the user behavior profile database, user profile test cases for the target user are generated, including: generating tidal load test cases based on file characteristics and concurrency characteristics during peak hours and during off-peak hours; generating load switching test cases with gradually changing load intensity at the boundary between peak and off-peak hours; inserting simulated anomaly test cases at preset time points based on the anomaly characteristics, and modifying the simulated anomaly test cases based on received and set anomaly parameters to generate anomaly behavior injection test cases; and parameterizing the tidal load test cases, the load switching test cases, and the anomaly behavior injection test cases to generate the user profile test cases; wherein, the user profile test cases include tidal load test cases with load intensity changing over time and anomaly behavior injection test cases simulating anomaly behavior characteristics. The test load corresponding to the user profile test case is injected into the storage device under test for testing, and the test results of the storage device under test are obtained.

2. The load testing method for a storage device according to claim 1, characterized in that, The method further includes: Based on a preset anomaly threshold, the data in the user behavior data is marked as abnormal.

3. The load testing method for a storage device according to claim 1, characterized in that, The method further includes: Execute preset test cases to inject load into the storage device under test and collect the performance indicators of the storage device under test to obtain test results.

4. The load testing method for a storage device according to claim 3, characterized in that, The method further includes: The test results of the user profile test cases are compared and analyzed with the test results of the preset test cases, and an analysis report and optimization suggestions are output.

5. A load testing system for a storage device, characterized in that, include: Acquisition module, extraction module, generation module, and testing module; The acquisition module is configured to collect access logs of the target user on the storage device, preprocess the access logs to obtain user behavior data, including: capturing access logs by listening to the storage device interface and periodically capturing access logs; cleaning the access logs to filter invalid data; and standardizing the cleaned access logs to obtain the user behavior data. The extraction module is configured to extract user behavior features based on the user behavior data to construct a user behavior profile library, including: extracting multi-dimensional features from the user behavior data using a clustering algorithm to generate multi-dimensional feature parameters, the multi-dimensional feature parameters including time features, file features, concurrency features and anomaly features; storing the multi-dimensional feature parameters of the target user into a preset database according to a preset structure to construct and generate the user behavior profile library; The step of extracting multidimensional features from the user behavior data using a clustering algorithm to generate multidimensional feature parameters includes: The time data in the user behavior data is classified to divide the peak and off-peak periods of the load on the storage device, so as to generate the time features; The file size distribution during peak and off-peak periods is obtained, and the read / write operation ratio during the peak and off-peak periods is obtained to generate the file characteristics. The average number of concurrent users, peak number of concurrent users, and read / write request frequency during peak and off-peak periods are collected to generate the concurrency characteristics. The user behavior data is analyzed to identify data with abnormal behavior, and the abnormal features are generated accordingly. The generation module is configured to generate user profile test cases for the target user based on the user behavior profile database, including: generating tidal load test cases based on file characteristics and concurrency characteristics during peak hours and during off-peak hours; generating load switching test cases with gradually changing load intensity at the boundary between peak and off-peak hours; inserting simulated anomaly test cases at preset time points based on the anomaly characteristics, and modifying the simulated anomaly test cases to generate anomaly behavior injection test cases based on received and set anomaly parameters; and performing test case parameterization processing on the tidal load test cases, the load switching test cases, and the anomaly behavior injection test cases to generate the user profile test cases; wherein, the user profile test cases include tidal load test cases and anomaly behavior injection test cases; The testing module is configured to execute the user profile test cases, inject the load corresponding to the user profile test cases into the storage device under test for testing, and obtain the test results of the storage device under test.

6. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the load testing method for the storage device according to any one of claims 1-4.

Images