Performance testing method, device, storage medium, and computer program product

Abstract

Embodiments of the present invention provide a performance testing method, a device, a storage medium, and a computer program product.In the embodiments of the present invention, if there is a second storage device having a historical traffic behavior similar to that of a first storage device, and a traffic replay duration required by the second storage device is shorter than a traffic replay duration required by the first storage device when the same traffic demand information is satisfied, traffic satisfying the traffic demand information is acquired from historical traffic of the second storage device and is used as test traffic, and traffic replay is performed on the first storage device to perform performance testing on the first storage device. In this way, by evaluating whether historical traffic behaviors of storage devices are similar and required traffic replay durations, test traffic from other storage devices can be used to perform performance testing on a storage device under test. In this way, the efficiency of performing performance testing on a storage device can be effectively improved while test accuracy is guaranteed.

Description

[0001] A Performance Testing Method, Device, Storage Medium, and Computer Program Product. This disclosure claims priority to Chinese patent application number 202410371764.5, filed with the China Patent Office on March 28, 2024, entitled "A Performance Testing Method, Device, Storage Medium, and Computer Program Product," the entire contents of which are incorporated herein by reference. Technical Field: This disclosure relates to the field of computer technology, and more particularly to a performance testing method, device, storage medium, and computer program product. Background: Traffic replay is a testing technique that resends captured real traffic data to a test environment for playback. Traffic replay technology can be used to perform performance testing on storage devices such as block devices. Current performance testing solutions typically replay actual historical traffic on the storage device under test based on the device's log records. This results in excessively long playback times for traffic required by some storage devices under test, resulting in poor performance testing efficiency. SUMMARY OF THE INVENTION Various aspects of the present disclosure provide a performance testing method, device, storage medium, and computer program product for improving the efficiency of performance testing of storage devices. An embodiment of the present disclosure provides a performance testing method, comprising: receiving a performance testing instruction for a first storage device, the performance testing instruction including traffic demand information; if a second storage device exists with similar historical traffic behavior to the first storage device, and if the traffic demand information is met, the traffic playback duration required by the second storage device is shorter than the traffic playback duration required by the first storage device, then obtaining traffic that meets the traffic demand information from the historical traffic of the second storage device as test traffic; and replaying the test traffic on the first storage device to perform a performance test on the first storage device. An embodiment of the present disclosure also provides a computing device, comprising: a memory, a processor, and a communication component; the memory being configured to store one or more computer instructions; and the processor being coupled to the memory and the communication component for executing the one or more computer instructions to perform the aforementioned performance testing method. An embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the aforementioned performance testing method. An embodiment of the present disclosure further provides a computer program product, comprising a computer program. When the computer program is executed by a processor, the processor is caused to execute the aforementioned performance testing method.In an embodiment of the present disclosure, a performance test instruction for a first storage device may be received, the performance test instruction including traffic demand information. If a second storage device exists with similar historical traffic behavior to the first storage device and, when meeting the same traffic demand information, the required traffic playback duration on the second storage device is shorter than that on the first storage device, traffic that meets the demand information may be obtained from the historical traffic of the second storage device as test traffic. This test traffic may then be replayed on the first storage device to perform a performance test on the first storage device. In this way, by evaluating whether the historical traffic behavior between storage devices is similar and the required traffic playback duration, a more suitable test traffic flow may be found for the storage device under test, thereby utilizing the historical traffic flow from other storage devices to perform a performance test on the storage device under test. This effectively improves the efficiency of performance testing of storage devices while ensuring test accuracy. BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of this disclosure. The exemplary embodiments of this disclosure and their descriptions are provided to explain the disclosure and are not intended to unduly limit the disclosure. In the accompanying drawings: Figure 1 is a flowchart of a performance testing method provided by an exemplary embodiment of the present disclosure; Figure 2 is a logic diagram of a performance testing method provided by an exemplary embodiment of the present disclosure; Figure 3 is a logic diagram of an optional implementation of the performance testing method provided by an exemplary embodiment of the present disclosure; and Figure 4 is a schematic diagram of the structure of a computing device provided by another exemplary embodiment of the present disclosure. Specific Implementations: To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. The technical solutions provided by various embodiments of the present disclosure are described in detail below in conjunction with the drawings. Figure 1 is a flowchart of a performance testing method provided by an exemplary embodiment of the present disclosure. Figure 2 is a logic diagram of a performance testing method provided by an exemplary embodiment of the present disclosure. The method can be executed by a performance testing device, which can be implemented as a combination of software and / or hardware and can be integrated into a computing device.Referring to Figure 1 , the method includes: Step 100: Receiving a performance test instruction for a first storage device, the performance test instruction including traffic demand information; Step 101: If a second storage device exists with similar historical traffic behavior to the first storage device, and if the traffic demand information is met but the traffic playback duration required by the second storage device is shorter than that required by the first storage device, then obtaining traffic that meets the traffic demand information from the historical traffic of the second storage device as test traffic; Step 102: Replaying the test traffic on the first storage device to perform a performance test on the first storage device. The performance testing method provided in this embodiment is applicable to scenarios requiring performance testing of storage devices. For example, performance testing of storage devices can be performed before system or application deployment to prevent application failures or system crashes due to performance issues. Performance testing of storage devices can also be performed when introducing new technologies or storage solutions to assess whether their performance meets requirements. Of course, this embodiment is not limited to such scenarios. Storage devices include, but are not limited to, block storage devices, file storage devices, or object storage devices. This embodiment does not limit the types of storage devices, and further examples are not provided herein. Furthermore, the performance test in this embodiment may involve multiple aspects of the storage device, including, but not limited to, throughput, latency, concurrency, resource utilization, and stability. This embodiment does not limit the test aspects involved in the performance test, and further examples are not provided herein. In this embodiment, in step 100, a performance test instruction for a first storage device may be received. The first storage device here refers to the storage device to be performance tested. The performance test instruction may include traffic demand information. In this embodiment, the traffic demand information may be used to describe the traffic demand during the performance test. The traffic demand information may include traffic metrics to characterize the traffic demand. In this embodiment, the traffic metrics in the traffic demand information may include, but are not limited to, the amount of historical traffic to be replayed (which can be understood as the number of I / O operations) or the amount of access resulting from the historical traffic to be replayed. This embodiment does not limit the traffic metrics included in the traffic demand information, and further examples are not provided herein. Furthermore, in this embodiment, the traffic metrics in the traffic demand information can be flexibly adjusted to suit the actual testing requirements of the storage device. During research, the inventors discovered that, for a first storage device, the traffic playback time required to meet the historical traffic requirements on that device can be very long, resulting in excessively long testing times and low testing efficiency. To address this, the inventors proposed a new mechanism: a traffic borrowing mechanism.Specifically, this new mechanism proposes leveraging historical traffic on other storage devices that meets the traffic demand but requires a shorter playback duration to perform performance testing on the first storage device, thereby shortening the testing time for the first storage device. Furthermore, to ensure that this new mechanism does not affect the accuracy of testing the first storage device, the inventors have further proposed identifying suitable test traffic for the first storage device by evaluating the similarity of historical traffic behavior. This ensures that the test traffic identified for the first storage device in this embodiment not only has a shorter playback duration than the historical traffic on the first storage device that meets the traffic demand, but also maintains consistency in historical traffic behavior. Therefore, this new mechanism ensures that while ensuring test accuracy, it effectively improves the efficiency of performance testing on the first storage device. The following describes the technical implementation logic of this new mechanism introduced in this embodiment. Referring to Figure 1 , in step 101, historical traffic on the first storage device that meets the traffic demand is no longer directly used as test traffic. Instead, a search is performed to determine whether a second storage device with similar historical traffic behavior exists for the first storage device. There are several possibilities. One possibility is that a second storage device with historical traffic behavior similar to that of the first storage device is not found. For this possibility, this embodiment proposes using historical traffic on the first storage device that meets the traffic demand information as test traffic. Another possibility is that a second storage device with historical traffic behavior similar to that of the first storage device is found, but the traffic playback duration required by the second storage device to meet the traffic demand information is not shorter than the traffic playback duration required by the first storage device. For this possibility, this embodiment proposes using historical traffic on the first storage device that meets the traffic demand information as test traffic. Yet another possibility is that a second storage device with historical traffic behavior similar to that of the first storage device is found, and the traffic playback duration required by the second storage device to meet the traffic demand information is shorter than the traffic playback duration required by the first storage device. For this possibility, this embodiment proposes, with reference to FIG2 , obtaining traffic that meets the traffic demand information from the historical traffic of the second storage device as test traffic. In this embodiment, traffic behavior can be understood as the I / O operations that occur on the storage device. The numerous I / O operations that have occurred on the storage device. The operation forms the historical traffic on the storage device.During their research, the inventors discovered that similar historical traffic behaviors have similar impacts on storage device performance. This is primarily because similar historical traffic behaviors actually consume the same amount of storage device performance. An easily understood example scenario is that the I / O operations occurring on storage devices A and B are identical, but the time intervals between adjacent I / O operations on storage device A are relatively long, while the time intervals between adjacent I / O operations on storage device B are relatively short. Therefore, the duration of the historical traffic behaviors on storage devices A and B will differ. For example, these I / O operations may take three days to complete on storage device A, but only two hours on storage device B. However, it is clear that the historical traffic behaviors on storage devices A and B are actually identical, and the performance consumption of a single I / O operation on the storage devices is also aligned, resulting in the same overall performance consumption on the storage devices. Of course, the above is merely a typical and easily understood example. During research, the inventors discovered that subtle changes in historical traffic behavior have little impact on performance consumption. Therefore, when borrowing historical traffic with similar behavior from other storage devices to perform performance testing on the first storage device, the performance consumption caused by the borrowed historical traffic on the first storage device will be similar to the performance consumption caused by the historical traffic originally required to be replayed on the first storage device, thus maintaining the accuracy of the performance test. It is precisely based on this technical concept that, in the third possibility mentioned in step 101, the historical traffic on the second storage device that meets the traffic requirement information is used as the test traffic. In other words, it can be understood that the test traffic found for the first storage device in step 101 can ensure accurate replay of the historical traffic behavior on the first storage device, and the required traffic playback time is shortened. In this embodiment, various implementation methods can be used to determine whether a second storage device with similar historical traffic behavior exists for the first storage device. In one optional implementation, historical traffic behavior similarity is introduced as an evaluation metric to assess whether the historical traffic behavior between storage devices is similar. Based on this, in this optional implementation: the historical traffic behavior similarity between the first storage device and the second storage device can be calculated. If the calculated historical traffic behavior similarity exceeds a preset threshold, it can be determined that the historical traffic behavior of the first storage device is similar to that of the second storage device.Here, the second storage device whose historical traffic behavior needs to be compared with the first storage device can be any other available storage device, or it can be a subset of storage devices that have been preliminarily screened, without limitation. The preset threshold can be set based on actual testing requirements. For example, if higher test accuracy is desired, the preset threshold can be increased to eliminate the impact of storage devices with less similar historical traffic behavior on test accuracy. If a greater probability of shortening test time is desired, the preset threshold can be appropriately lowered to provide more storage devices for performance testing of the first storage device. In this optional implementation, an exemplary method for calculating historical traffic behavior similarity can include determining a target historical traffic behavior cluster in which the first storage device resides, and calculating the distance between the first storage device and a second storage device in the target historical traffic behavior cluster, thereby characterizing the historical traffic behavior similarity between the storage devices using this distance. The historical traffic behavior clusters are generated by clustering storage devices based on their historical traffic behavior. Each historical traffic behavior cluster contains at least one storage device. It should be understood that, due to clustering, the historical traffic behavior of each storage device in the same historical traffic behavior cluster will have a certain degree of similarity. Therefore, in this exemplary solution, the target historical traffic behavior cluster can be used to initially screen a portion of storage devices for the first storage device. Based on this, a further optimal storage device can be selected for the first storage device by calculating the distance. This not only effectively improves the efficiency of finding a second storage device with similar historical traffic behavior to the first storage device, but also ensures that the selected second storage device has even greater historical traffic behavior similarity with the first storage device. The following provides an exemplary clustering solution to illustrate the process of constructing historical traffic behavior clusters. This exemplary clustering solution proposes extracting feature vectors representing the historical traffic behavior of each storage device based on its corresponding log data. Based on the extracted feature vectors, the storage devices are clustered to generate at least one historical traffic behavior cluster. The storage devices referred to herein can be all storage devices present in the scenario, without limitation. The log data corresponding to a storage device contains historical traffic behavior records on that storage device. A historical traffic behavior record can contain multiple items describing the corresponding historical traffic behavior. In this exemplary clustering scheme, feature vectors are introduced to characterize historical traffic behavior. This allows the massive amount of historical traffic behavior records in the log data to be converted into lightweight feature vectors.Clustering storage devices based on lighter-weight feature vectors can reduce the clustering workload and effectively improve clustering efficiency, thereby further enhancing the efficiency of storage device performance testing. During their research, the inventors discovered that the historical traffic behavior records contained in the log data corresponding to a storage device are incremental. That is, as new I / O operations are performed on the storage device, the historical traffic behavior records in its log data are also continuously added. Therefore, in this exemplary clustering scheme, an optional solution is proposed: log data corresponding to any storage device can be acquired in batches. Based on this, in this optional solution, an initial clustering is performed based on the first batch of log data corresponding to each storage device to generate a basic clustering result—at least one historical traffic behavior cluster. However, during their research, the inventors discovered that the historical traffic behavior reflected in the first batch of log data may not be comprehensive or accurate. Therefore, they proposed that for any storage device, if the feature vector representing the storage device in any batch of log data acquired changes, the historical traffic behavior cluster for that storage device is redefined. In this way, the historical traffic behavior of the storage device can be more accurately identified. By dynamically fine-tuning the clustering results, the accuracy of the clustered historical traffic behavior clusters can be guaranteed, providing a more accurate basis for subsequent evaluation of the similarity of historical traffic behavior, thereby improving the accuracy of performance testing. In this optional solution, the triggering method for batch acquisition is not limited. That is, regardless of the triggering method, each time a new batch of log data is acquired, the storage device can determine whether the historical traffic behavior cluster in which it is located needs to be adjusted based on the new batch of log data. An exemplary triggering method may be: after completing the acquisition operation of the previous batch, the number of newly added historical traffic behavior records in the log data of the storage device is monitored; if the number of newly added historical traffic behavior records exceeds a triggering threshold, the acquisition operation of the current batch is triggered to acquire the newly added historical traffic behavior records in the log data of the storage device as the basis for extracting feature vectors for the storage device. It should be understood that this triggering method is exemplary and other triggering methods can be used here without limitation. For example, time can be used as a trigger condition, and further examples are not provided here. In this exemplary clustering scheme, the clustering algorithms that can be used include, but are not limited to, K-Means algorithm, Mean-Shift clustering algorithm, Gaussian mixture model (GMMs) or hierarchical clustering algorithm, etc., which can implement clustering functions.To further ensure clustering accuracy, feature vectors can be cleaned before clustering to remove duplicate data and handle missing or outliers, thereby improving clustering accuracy. Furthermore, feature vectors can be subjected to dimensionality reduction before clustering to reduce the number of features while retaining the key information of the feature variables, thereby improving clustering efficiency. The dimensionality reduction techniques used can include principal component analysis (PCA), linear discriminant analysis (LDA), or local linear embedding (LLE), though these are not limited here. As described above, historical traffic behavior clusters are determined based on the feature vectors of storage devices, which in turn represent the historical traffic behavior of the storage devices. Therefore, each historical traffic behavior cluster represents a category of historical traffic behavior. Based on this, an exemplary approach for determining which historical traffic behavior cluster a storage device belongs to may include calculating the distance (i.e., vector distance) between the storage device's feature vector and the cluster centers of each historical traffic behavior cluster, thereby assigning the storage device to the closest historical traffic behavior cluster. Furthermore, in some special cases, if the distances between the storage device's feature vector and the cluster centers of each historical traffic behavior cluster are relatively large, a new historical traffic behavior cluster may be created for the storage device. Furthermore, the number of storage devices included in each historical traffic behavior cluster may be regularly counted. If a large number of historical traffic behavior clusters contain only one or a few storage devices, a clustering operation may be re-initiated to reconstruct the historical traffic behavior clusters. Furthermore, in addition to dynamically updating the historical traffic behavior clusters assigned to storage devices in batches as described above, a lifecycle may be set for the feature vector corresponding to each storage device. Feature vectors from historical traffic behavior clusters that have exceeded their lifecycle may be periodically deleted. This triggers the recalculation of feature vectors for storage devices whose feature vectors have been deleted, ensuring the real-time nature of the feature vectors corresponding to the storage devices and, therefore, the accuracy of the distribution of storage devices within historical traffic behavior clusters. Furthermore, a scenario identifier can be configured for at least one historical traffic behavior cluster based on the proportion of each type of feature vector contained in the cluster. For example, if 80% of the feature vectors in a historical traffic behavior cluster reflect the data type MySQL, a scenario identifier of "MySQL database" can be configured for the cluster.The configuration of scenario identifiers not only categorizes historical traffic behavior clusters by scenario, but also provides testers with a test reference, allowing them to independently select appropriate test data for performance testing during traffic playback. For example, if the target historical traffic behavior cluster for a first storage device is configured with the scenario identifier data "MySQL database," then when performing performance testing on the first storage device, MySQL data outside the historical traffic behavior cluster can be added to the test data, or other types of data other than MySQL can be added to the test data for comparison to observe the performance of the first storage device in the database scenario. Accordingly, in this optional implementation, it is possible to efficiently and accurately determine for the first storage device whether a second storage device with similar historical traffic behavior exists. It should be understood that other implementations can also be used in this embodiment to determine whether a second storage device with similar historical traffic behavior exists for the first storage device, and the present invention is not limited to this. For example, after receiving a performance test instruction, the system can evaluate the similarity of historical traffic behavior between the first storage device and all other storage devices in the scenario to determine whether a second storage device with similar historical traffic behavior exists for the first storage device. This will not be further explained or illustrated here. Continuing with Figure 1, in step 101, if a second storage device with similar historical traffic behavior exists, the system can calculate the traffic playback duration required for the second storage device to meet the traffic demand information. If the required traffic playback duration on the second storage device is shorter than that required on the first storage device, the second storage device can be used as a reference for the first storage device. Traffic that meets the traffic demand information is then obtained from the second storage device's historical traffic as test traffic. The calculation logic for the traffic playback duration will not be further elaborated; any existing or future feasible calculation logic can be used and is not limited here. It should be understood that once traffic demand information is determined, traffic that meets the traffic demand can be identified from the historical traffic on the second storage device. The actual duration of this traffic is the traffic playback duration. This is because the traffic playback process is still based on the actual behavior of the historical traffic. Therefore, the traffic playback duration and the actual duration remain consistent. Optionally, in step 101, if multiple storage devices meet the requirements, one can be randomly selected as the second storage device. Alternatively, a traffic playback duration range can be first selected, and then any storage device that meets the traffic playback duration range can be selected as the second storage device.Alternatively, the required traffic replay durations can be sorted, and the storage device with the shortest traffic replay duration can be selected as the second storage device. Alternatively, the storage device closest to the cluster center within the target historical traffic behavior cluster in which the first storage device resides can be selected as the second storage device. In this case, the method for selecting the second storage device in this embodiment is not limited. Based on this, in step 102, test traffic can be replayed on the first storage device to perform a performance test on the first storage device. Traffic replay is the replay of I / O operations on the storage device to monitor the stress of different I / O operations on the storage device. A traffic replay environment can be established for the first storage device, and within the traffic replay environment corresponding to the first storage device, test traffic obtained from the second storage device can be used for traffic replay to perform a performance test on the first storage device. In summary, in this embodiment, if a second storage device exists with similar historical traffic behavior to a first storage device and, when meeting the same traffic requirement information, the required traffic playback duration on the second storage device is shorter than that required by the first storage device, traffic that meets the traffic requirement information can be obtained from the second storage device's historical traffic as test traffic. This traffic can then be replayed on the first storage device to perform a performance test on the first storage device. In this way, by evaluating the similarity of historical traffic behavior between storage devices and the required traffic playback duration, a more suitable test traffic can be found for the storage device under test, thereby utilizing historical traffic from other storage devices to perform a performance test on the storage device under test. This effectively improves the efficiency of storage device performance testing while ensuring test accuracy. In the above and following embodiments, various implementations can be used to extract feature vectors representing historical traffic behavior for multiple storage devices. In one exemplary implementation, for any storage device, temporal and / or spatial features can be extracted based on its corresponding log data. These features are then combined to generate a feature vector corresponding to the storage device. Temporal features can be used to describe the fluctuation patterns of historical traffic on the storage device in the temporal dimension, while spatial features can be used to describe the distribution patterns of historical traffic on the storage device in the spatial dimension. It should be noted that I / O operations occurring on a storage device typically have a sequential relationship. This sequential relationship may be caused by the I / O operations occurring at different times or by contextual dependencies between the I / O operations. The reasons for this sequential relationship will not be further explained here.It is important to emphasize that this sequential relationship can be understood as a temporal relationship, which is a sequential relationship in the time dimension. In this embodiment, when extracting feature vectors for storage devices, not only behavioral fluctuation patterns in the time dimension are considered, but also behavioral distribution patterns in the spatial dimension. This makes the feature vector's description of the storage device more comprehensive and accurate. In an optional implementation, content items describing historical traffic behavior in each historical traffic behavior record can be used to extract temporal and spatial features. Based on this, in this optional implementation, preset content items can be extracted from each historical traffic behavior record contained in the log data corresponding to the storage device. These preset content items in each extracted historical traffic behavior record are then used as the basis for feature extraction to extract temporal and spatial features for the storage device. During their research, the inventors discovered that historical traffic behavior records contained in log data are typically in binary data format. Therefore, they proposed deserializing these binary-formatted historical traffic behavior records to convert them from their original unreadable format into a readable format. The converted historical traffic behavior records are then stored in a file, allowing for the extraction of preset content items from the converted historical traffic behavior records. Preset content items may include, but are not limited to, operation type, access block device address, I / O size, I / O start time, and I / O end time. Figure 3 is a logical diagram of an optional implementation of a performance testing method provided by an exemplary embodiment of the present disclosure. Referring to Figure 3, this embodiment also constructs a feature extractor. Log data can be used as input to the feature extractor, which extracts feature vectors for storage devices, namely the aforementioned temporal and spatial features. Furthermore, the extracted feature vectors can be stored in a database, so that when clustering storage devices is required, the feature vectors can be retrieved from the database and input into a clustering model. The clustering model can be used to identify a second storage device with similar historical traffic behavior to the first storage device and a shorter traffic playback duration required to meet the traffic requirements. Test traffic that meets the traffic requirements is then extracted from the second storage device's historical traffic and fed into the playback model for traffic playback, thereby performing a performance test on the first storage device. The following describes the extraction processes for temporal and spatial features, respectively.An exemplary implementation for extracting time series features for a storage device may include: Based on preset content items in each historical traffic behavior record, at least one feature value used to characterize the performance consumption state may be calculated for each historical traffic behavior record. The same feature values ​​corresponding to each historical traffic behavior record may form a time series. The obtained at least one time series is input into a time series feature extraction model, and the time series feature extraction model is used to extract a first feature sequence for the storage device as a time series feature. The feature value used to characterize the performance consumption state can be flexibly adjusted to meet actual testing requirements for the storage device. Feature values ​​may include the number of input / output operations performed per unit time (IOPS) and / or the number of bytes transmitted during an I / O operation (BPS). Based on the preset content items in each historical traffic behavior record, the feature value corresponding to each historical traffic behavior record may be calculated according to calculation rules corresponding to the feature value. Taking the IOPS feature value as an example, for any historical traffic behavior record, based on the preset content items (IOPS number, IOPS end time, and IOPS start time) in the historical traffic behavior record, the IOPS corresponding to the historical traffic behavior record can be calculated using the formula: IOPS = IOPS number / (IOPS end time - IOPS start time). Combining the IOPS corresponding to multiple historical traffic behavior records in the log data can form an IOPS time series. To save space, the specific calculation methods for other feature values ​​are not detailed here. Based on the feature values ​​corresponding to each historical traffic behavior record in the log data, at least one time series can be combined. The at least one obtained time series is input into the time series feature extraction model, which uses its internal time series feature extraction algorithm to extract time series features from the time series that can describe the fluctuation patterns of historical traffic behavior in the temporal dimension. The time series feature extraction algorithm is an algorithm that extracts and processes features from time series data. Its purpose is to extract more meaningful time series features from the raw time series data. Time series feature extraction algorithms may include, but are not limited to, tsfresh, dtw-features, or tslearn. Time series features extracted based on the time series feature model may include basic features such as the number of peaks, average value, and maximum value of the time series, as well as complex features such as time series correlation and time-reversal symmetry statistics, but are not limited to these.In other words, the process of extracting time series features can also be understood as converting M*N log data into K*1 time series features. Here, M represents the number of historical traffic behavior records in the log data, N represents the number of types of preset content items, and K represents the number of extracted time series features. The "1" in K*1 represents one log data item. Furthermore, the value of K is much smaller than the value of M, which, to a certain extent, also serves as a dimensionality reduction function, providing fewer clustering samples for the subsequent clustering process, thereby improving clustering efficiency. An exemplary implementation of extracting spatial features for a storage device may include: Based on the preset content items under each historical traffic behavior record, a feature sequence representing the behavior distribution pattern along a feature dimension may be calculated. The spatial feature may include one or more feature dimensions. Based on the feature sequence corresponding to the feature dimension, a second feature sequence may be generated for the storage device as a spatial feature. The spatial feature describes the behavior distribution pattern of historical traffic on the storage device along the spatial dimension, while the feature dimension is an important indicator for describing the complexity and richness of the behavior distribution pattern along the spatial dimension. For each feature dimension, a feature sequence that characterizes the behavior distribution pattern within that feature dimension can be calculated based on the preset content items in each historical traffic behavior record. Spatial features for the storage device can then be generated based on the feature sequences corresponding to each of the multiple feature dimensions. In this embodiment, multiple, more lightweight feature sequences are extracted from the massive volume of historical traffic behavior records based on the preset content items. These feature sequences can describe the behavior distribution patterns within the spatial dimension from different perspectives, enabling the spatial features generated based on the feature sequences to more comprehensively and concisely reflect the historical traffic behavior on the storage device. Furthermore, multiple feature items and corresponding calculation rules can be preset for each feature dimension. Feature items provide a more granular division and definition of the feature dimension based on the complexity and richness of the behavior distribution patterns. In this way, when calculating feature sequences for each of the multiple preset feature dimensions, which are used to characterize the behavior distribution patterns within each feature dimension, characteristic values ​​can be calculated for the target feature items in the target feature dimension based on the preset content items in each historical traffic behavior record, in accordance with the calculation rules corresponding to the target feature items in the target feature dimension. Based on the characteristic values ​​calculated for each of the preset feature items in the target feature dimension, a feature sequence corresponding to the target feature dimension is generated. The characteristic values ​​for the target feature items can be used to reflect a behavior distribution pattern within the target feature dimension, where the target feature dimension is any one of the multiple feature dimensions.Target feature dimensions may include, but are not limited to, access type dimension, access volume dimension, access dependency dimension, access mode dimension, and access discreteness dimension. Several exemplary target feature dimensions are briefly described below:

[0002] 1. The target feature dimension may include an access type dimension. Within this target feature dimension, feature items are pre-defined to characterize the distribution patterns of access types. Access types include, but are not limited to, read operations and write operations. The I / O operation type (I / O Type) on the storage device can be evaluated from the access type dimension to effectively reflect the storage device's response time, CPU utilization, and other factors. Feature items within the access type dimension may include, but are not limited to, read / write ratio, read / write count, and read / write frequency.

[0003] 2. The target feature dimension may include a volume dimension. Within this target feature dimension, feature items are pre-defined that can characterize the distribution of volume accesses resulting from historical traffic behavior. The size of I / O operation request data (I / O Size) on a storage device can be evaluated from the volume dimension to effectively reflect the I / O throughput and storage efficiency of the storage device. The size of each I / O operation request data entry on a storage device varies. Multiple I / O Size entries on a storage device are grouped into an I / O set. The I / O Size entries in this set are analyzed to obtain feature items that describe the distribution of volume accesses within the set. Feature items within the volume dimension may include, but are not limited to, the mean, maximum, minimum, variance, kurtosis, and skewness of the volume accesses.

[0004] 3. The target feature dimension may include an access dependency dimension. Within this target feature dimension, feature items are pre-set to characterize the distribution patterns of dependencies between historical traffic behaviors. In computer systems or applications, I / O operations may not be completely independent; contextual semantic information exists between different I / O operations, leading to interdependencies. Access dependencies include, but are not limited to, Read After Write (RAW), Write After Read (WAR), Read After Read (RAR), and Write After Write (WAW). Dependencies between I / O operations on storage devices can be evaluated from the access dependency dimension to effectively reflect the throughput, concurrency, and load of the storage device. The distribution patterns of dependencies between historical traffic behaviors can be determined by analyzing the proportion of various types of dependencies on the same access address. Feature items within the access dependency dimension may include, but are not limited to, the Read After Write ratio, the Write After Read ratio, the Read After Read ratio, and the Write After Write ratio. For example, if the "write-after-write ratio" is high, it indicates that data is constantly being replicated, which has a certain impact on automatic memory management (Gabage Collection, GC), affecting the stability of storage device operation. If the "read-after-write ratio" is high, it indicates that large-scale read-after-write occurs, involving a large amount of complex calculations on the storage device, and placing high performance requirements on the storage device itself.

[0005] 4. The target feature dimension may include an access method dimension. Within this target feature dimension, feature items that can characterize the distribution patterns of access methods are pre-set. The access method dimension is the feature dimension that best reflects the distribution patterns of traffic behavior in the spatial dimension. Access methods can include sequential access, random access, and block-level access. The access methods of storage devices can be evaluated from this access method dimension to effectively reflect the data transfer speed and performance consumption of the storage device. Feature items within the access method dimension may include, but are not limited to, the ratio of sequential accesses to random accesses and the ratio of sequential accesses to total accesses. For example, when performing a select operation in a database, the search operation based on the B+ tree structure is a random search, followed by sequential retrieval after the search is found. The random search and sequential retrieval processes are continuous, resulting in the historical traffic behavior of the storage device being characterized by "random access + sequential access." Therefore, the ratio of sequential accesses to random accesses can be used to reflect the distribution patterns of access methods on the storage device.

[0006] 5. The target feature dimension may include an access distribution dimension. Within this target feature dimension, feature items are pre-defined that characterize the distribution pattern of historical traffic behavior concentration at various access addresses. The access distribution dimension can be used to evaluate the concentration of I / O operations on a storage device over a period of time, effectively reflecting the storage device's concurrent processing capabilities and data processing efficiency. Feature items within the access distribution dimension may include, but are not limited to, the concentration of historical traffic behavior at different access addresses. For example, I / O operations accessing access addresses can be abstracted into a dictionary that records the number of accesses to each access address on the storage device. By calculating the proportion of accesses to different access addresses relative to the total number of accesses to the storage device, the concentration of historical traffic behavior at different access addresses can be determined. A larger calculated proportion indicates a more concentrated historical traffic behavior and a more intensive access. Of course, target feature dimensions are not limited to the aforementioned scenarios and will not be elaborated upon here. On this basis, based on the feature items included in each feature dimension, the corresponding eigenvalues ​​of each feature item can be calculated. All eigenvalues ​​are combined to construct a P*1 spatial feature for the storage device, where P represents the number of feature items and the "1" in P*1 represents one log data item. In conjunction with the above, during the extraction of time series features for the storage device, K*1 time series features are ultimately extracted. The eigenvalues ​​corresponding to the spatial features and the eigenvalues ​​corresponding to the time series features are combined to obtain a (K+P)*1 feature sequence, which is the feature vector for the storage device. In summary, in this embodiment, based on the log data corresponding to the storage device, time series features and spatial features can be extracted for the storage device as its corresponding feature vector. This not only converts massive amounts of log data into lightweight feature vectors, but also ensures that the feature vectors comprehensively and accurately cover the storage device features. This not only reduces the amount of stored data but also reduces the workload of clustering and improves clustering accuracy, effectively increasing clustering efficiency and further improving the efficiency of storage device performance testing. It should be noted that the steps of the method provided in the above embodiment can be performed by the same device, or the method can be performed by different devices. For example, steps 100 to 102 can be performed by device A; for another example, steps 100 and 101 can be performed by device A, while step 102 can be performed by device B; and so on.In addition, some processes described in the above embodiments and accompanying figures include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed out of the order in which they appear herein or in parallel. Operation numbers such as 100 and 101 are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that terms such as "first" and "second" are used herein to distinguish between different messages, devices, modules, etc., and do not represent a specific order or limit the "first" and "second" to different types. Figure 4 is a schematic diagram of the structure of a computing device provided in yet another exemplary embodiment of the present disclosure. As shown in Figure 4, the computing device includes a memory 40, a processor 41, and a communication component 42. The processor 41 is coupled to the memory 40 and the communication component 42, and is configured to execute a computer program in the memory 40, to: receive, via the communication component 42, a performance test instruction for a first storage device, the performance test instruction including traffic demand information; if a second storage device exists with historical traffic behavior similar to that of the first storage device, and if the traffic demand information is met, the traffic playback duration required by the second storage device is shorter than the traffic playback duration required by the first storage device, then obtain, from the historical traffic of the second storage device, traffic that meets the traffic demand information as test traffic; and replay the test traffic on the first storage device to perform a performance test on the first storage device. In an optional embodiment, the processor 41 is further configured to: calculate a historical traffic behavior similarity between the first storage device and the second storage device; and if the historical traffic behavior similarity exceeds a preset threshold, determine that the historical traffic behavior of the first storage device and the second storage device are similar. In an optional embodiment, during the process of calculating the historical traffic behavior similarity between the first storage device and the second storage device, the processor 41 is further configured to: determine a target historical traffic behavior cluster in which the first storage device is located, where the historical traffic behavior cluster is generated by clustering storage devices based on their historical traffic behavior; and calculate the distance between the first storage device and the second storage device in the target historical traffic behavior cluster to represent the historical traffic behavior similarity. In an optional embodiment, during the clustering process, the processor 41 is further configured to: extract a feature vector representing the historical traffic behavior of the storage device based on the log data corresponding to the storage device; and cluster the storage devices based on the extracted feature vector to generate at least one historical traffic behavior cluster.In an optional embodiment, the processor 41 is further configured to: acquire log data corresponding to any storage device in batches; and if the feature vector representing the storage device in any batch of acquired log data changes, re-determine the historical traffic behavior cluster for the storage device. In an optional embodiment, during the process of acquiring log data corresponding to the storage device in batches, the processor 41 is further configured to: monitor the number of newly added historical traffic behavior records in the log data of the storage device after completing the acquisition operation for the previous batch; and if the number of newly added historical traffic behavior records exceeds a trigger threshold, trigger the execution of the acquisition operation for the current batch to acquire the newly added historical traffic behavior records in the log data of the storage device as a basis for extracting a feature vector for the storage device. In an optional embodiment, when extracting a feature vector representing historical traffic behavior for a storage device based on the log data corresponding to the storage device, the processor 41 is further configured to: extract time series features and / or spatial features for any storage device based on its corresponding log data, wherein the time series features are used to describe the fluctuation patterns of historical traffic behavior on the storage device in the time dimension, and the spatial features are used to describe the distribution patterns of historical traffic behavior on the storage device in the spatial dimension; and combine the time series features and spatial features to generate a feature vector corresponding to the storage device. In an optional embodiment, when extracting time series features and spatial features for any storage device based on its corresponding log data, the processor 41 is further configured to: extract preset content items from each historical traffic behavior record contained in the log data corresponding to the storage device; and extract time series features and spatial features for the storage device using the preset content items in each extracted historical traffic behavior record as a basis for feature extraction. In an optional embodiment, during the process of extracting time series features for the storage device, the processor 41 is further configured to: calculate at least one feature value for each historical traffic behavior record based on preset content items associated with each record, used to characterize the performance consumption state; wherein the feature values ​​of the same type corresponding to each historical traffic behavior record constitute a time series; and input the obtained at least one time series into a time series feature extraction model to extract a first feature sequence for the storage device using the time series feature extraction model as a time series feature. In an optional embodiment, the feature value includes the number of input / output operations performed per unit time and / or the number of bytes transferred during the input / output operations performed per unit time.In an optional embodiment, during the process of extracting spatial features for the storage device, the processor 41 is further configured to: calculate a feature sequence based on preset content items in each historical traffic behavior record, representing a behavior distribution pattern within a feature dimension. The spatial feature includes one or more feature dimensions; and generate a second feature sequence for the storage device based on the feature sequence corresponding to the feature dimension as a spatial feature. In an optional embodiment, each feature dimension is preset with multiple feature items and corresponding calculation rules. During the process of calculating the feature sequence representing the behavior distribution pattern within the feature dimension, the processor 41 is further configured to: calculate a feature value for the target feature item based on the preset content items in each historical traffic behavior record, according to the calculation rule corresponding to the target feature item in the target feature dimension. The feature value for the target feature item reflects a behavior distribution pattern within the target feature dimension; and generate a feature sequence corresponding to the target feature dimension based on the feature values ​​calculated for each preset feature item within the target feature dimension. The target feature dimension is any one of the multiple feature dimensions. In an optional embodiment, the target feature dimension includes an access type dimension, under which feature items are preset that can characterize the distribution pattern of access types; or, the target feature dimension includes an access volume dimension, under which feature items are preset that can characterize the distribution pattern of access volume caused by history; or, the target feature dimension includes an access dependency dimension, under which feature items are preset that can characterize the distribution pattern of dependencies between historical traffic behaviors; or, the target feature dimension includes an access method dimension, under which feature items are preset that can characterize the distribution pattern of access methods; or, the target feature dimension includes an access dispersion degree dimension, under which feature items are preset that can characterize the distribution pattern of the concentration degree of historical traffic behaviors at each access address. In an optional embodiment, feature items under the access type dimension include: read-write ratio, read-write count, and read-write frequency; feature items under the access volume dimension include: mean, maximum, minimum, variance, kurtosis, and skewness of the access volume; feature items under the access dependency dimension include: read-after-write ratio, write-after-read ratio, read-after-read ratio, and write-after-write ratio; feature items under the access mode dimension include: the ratio of sequential access count to random access count; and feature items under the access dispersion dimension include: the concentration of historical traffic behavior at different access addresses. Furthermore, as shown in FIG4 , the computing device also includes other components, such as a power supply component 43. FIG4 schematically illustrates only some components and does not imply that the computing device only includes the components shown in FIG4 .It is worth noting that the technical details of the computing device embodiments described above can be found in the descriptions of the computing device operations described in the aforementioned interface comparison test method embodiments. To save space, these details will not be repeated here, but this should not diminish the scope of protection of the present disclosure. The present disclosure also provides a computer program product comprising a computer program. When executed by a processor, the computer program can implement the steps of the aforementioned performance testing method. It should be noted that the technical solution of the computer program and the technical solution of the aforementioned performance testing method share the same concept. For details not described in detail in the technical solution of the computer program, reference can be made to the description of the technical solution of the aforementioned performance testing method. Accordingly, the present disclosure also provides a computer-readable storage medium storing the computer program. When executed, the computer program can implement the steps that can be performed by the computing device in the aforementioned method embodiments. The memory in FIG. 4 is used to store the computer program and can be configured to store various other data to support operations on the computing device. Examples of such data include instructions for any application or method operating on the computing device, contact data, phonebook data, messages, images, videos, and the like. The memory can be implemented using any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk. The communication component in FIG. 4 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies. The power supply component in Figure 4 provides power to various components of the device in which the power supply component is located.The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly resides. Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk drives, CD-ROMs, optical storage devices, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, may be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing device, produce means for implementing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means, which implement the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram. These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, such that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram. In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. oMemory is an example of computer-readable media. Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can implement information storage using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmitting medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the phrase "comprises a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the recited elements. The foregoing description is merely an example of the present disclosure and is not intended to limit the present disclosure. Various modifications and variations of the present disclosure will readily occur to those skilled in the art. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.

Claims

Claims 1. A performance testing method, wherein: The method includes: receiving a performance test instruction for a first storage device, wherein the performance test instruction includes traffic demand information; if there is a second storage device with similar historical traffic behavior to the first storage device, and when the traffic demand information is met, the traffic playback duration required by the second storage device is shorter than the traffic playback duration required by the first storage device, then obtaining the traffic that meets the traffic demand information from the historical traffic of the second storage device as the test traffic; and replaying the test traffic on the first storage device to perform a performance test on the first storage device.

2. The method according to claim 1, wherein: The method further includes: calculating a historical traffic behavior similarity between the first storage device and the second storage device; and determining that the historical traffic behavior of the first storage device is similar to that of the second storage device if the historical traffic behavior similarity exceeds a preset threshold.

3. The method according to claim 2, wherein: The calculating the historical traffic behavior similarity between the first storage device and the second storage device includes: determining a target historical traffic behavior cluster in which the first storage device is located, wherein the historical traffic behavior cluster is generated by clustering storage devices based on historical traffic behaviors; and calculating the distance between the first storage device and the second storage device in the target historical traffic behavior cluster to characterize the historical traffic behavior similarity.

4. The method according to claim 3, wherein: The clustering process includes: extracting a feature vector for characterizing historical traffic behavior for the storage device based on log data corresponding to the storage device; and clustering the storage device based on the extracted feature vector to generate at least one historical traffic behavior cluster.

5. The method according to claim 4, wherein: The method further includes: acquiring log data corresponding to any storage device in batches; and re-determining a historical traffic behavior cluster for the storage device if a feature vector corresponding to the storage device represented by the log data acquired in any batch changes.

6. The method according to claim 5, wherein: The obtaining of the log data corresponding to the storage device in batches includes: after completing the acquisition operation of the previous batch, monitoring the number of new historical traffic behavior records in the log data of the storage device; if the number of new historical traffic behavior records monitored exceeds a trigger threshold, triggering the execution of the current batch acquisition operation to obtain the new historical traffic behavior records in the log data of the storage device as a basis for extracting feature vectors for the storage device.

7. The method according to any one of claims 4 to 6, wherein: Extracting a feature vector for characterizing historical traffic behavior for the storage device based on the log data corresponding to the storage device includes: extracting time series features and / or spatial features for any storage device based on its corresponding log data, wherein the time series features are used to describe the behavioral fluctuation patterns of historical traffic on the storage device in the time dimension, and the spatial features are used to describe the behavioral distribution patterns of historical traffic on the storage device in the spatial dimension; The temporal feature and the spatial feature are combined to generate a feature vector corresponding to the storage device.

8. The method according to claim 7, wherein: The extracting of temporal features and spatial features for any storage device based on its corresponding log data includes: extracting preset content items from each historical traffic behavior record contained in the log data corresponding to the storage device; and extracting the temporal features and the spatial features for the storage device using the preset content items under each extracted historical traffic behavior record as a basis for feature extraction.

9. The method according to claim 8, wherein: Extracting the timing features for the storage device includes: calculating at least one characteristic value for characterizing the performance consumption state for each historical traffic behavior record based on preset content items under each historical traffic behavior record, wherein the same characteristic values ​​corresponding to each historical traffic behavior record constitute a time series; inputting the obtained at least one time series into a timing feature extraction model, so as to use the timing feature extraction model to extract a first feature sequence for the storage device as the timing feature.

10. The method according to claim 9, wherein: The characteristic value includes the number of times the input / output operation is performed per unit time, and / or the number of bytes transmitted by the input / output operation performed per unit time.

11. The method according to claim 8, wherein: Extracting the spatial features for the storage device includes: calculating a feature sequence for characterizing the behavior distribution law under a feature dimension based on preset content items under each historical traffic behavior record, where the spatial features include one or more feature dimensions; and generating a second feature sequence for the storage device as the spatial feature according to the feature sequence corresponding to the feature dimension.

12. The method according to claim 11, wherein: Multiple feature items and calculation rules corresponding to the feature items are preset under each feature dimension. The calculation is used to characterize the feature sequence of the behavior distribution law under the feature dimension, including: according to the calculation rule corresponding to the target feature item under the target feature dimension, based on the preset content items under the various historical traffic behavior records, calculating the feature value for the target feature item, the feature value under the target feature item is used to reflect a behavior distribution law under the target feature dimension; based on the feature values ​​calculated for various feature items preset under the target feature dimension, generating a feature sequence corresponding to the target feature dimension; wherein the target feature dimension is any one of the multiple feature dimensions.

13. The method according to claim 12, wherein: The target feature dimension includes an access type dimension, under which feature items that can characterize the distribution law of access types are preset; or, the target feature dimension includes a visit volume dimension, under which feature items that can characterize the distribution law of visit volume caused by historical traffic behavior are preset; or, the target feature dimension includes an access dependency dimension, under which feature items that can characterize the distribution law of dependencies between historical traffic behaviors are preset; or, the target feature dimension includes an access method dimension, under which feature items that can characterize the distribution law of access methods are preset; or, the target feature dimension includes an access dispersion degree dimension, under which feature items that can characterize the distribution law of the concentration degree of historical traffic behaviors at each access address are preset.

14. The method according to claim 13, wherein: The characteristic items under the access type dimension include: Read Write ratio, read and write times, and read and write frequency; the characteristic items under the access volume dimension include: the mean, maximum, minimum, variance, kurtosis, and skewness of the access volume; the characteristic items under the access dependency dimension include: the read-after-write ratio, the write-after-read ratio, the read-after-read ratio, and the write-after-write ratio; the characteristic items under the access mode dimension include: the ratio of sequential access times to random access times; the characteristic items under the access discreteness dimension include: the concentration degree of historical traffic behavior on different access addresses.

15. A computing device, wherein: The system comprises a memory, a processor and a communication component; the memory is used to store one or more computer instructions; the processor is coupled to the memory and the communication component, and is used to execute the one or more computer instructions to perform the performance testing method according to any one of claims 1 to 14.

16. A computer-readable storage medium storing computer instructions, wherein: When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the performance testing method according to any one of claims 1 to 14.

17. A computer program product, wherein: The method comprises a computer program, wherein when the computer program is executed by a processor, the processor is caused to execute the performance testing method according to any one of claims 1 to 14. 18

Images