Server hardware test terminal and method

Abstract

The invention discloses a server hardware testing terminal and method, and relates to the technical field of server hardware testing, and the method comprises the steps: obtaining server hardware configuration parameters and storage equipment specification information, collecting the number of processor cores, memory capacity and storage equipment read-write speed reference data through a system monitoring interface, building a hardware performance baseline file, and storing the baseline file in a server; obtaining a complete hardware resource list and a performance index range; the method comprises the following steps: constructing a multi-dimensional workload model according to information retrieval scene features, creating query request sets of different scales by adopting a random number generator, simulating a mixed load mode of full-text retrieval and database query, and determining resource consumption weights and execution time distribution of various query operations; and analyzing query request distribution characteristics in the workload model through a dynamic load balancing algorithm, if query requests are concentrated in a specific time period, adjusting a load distribution strategy, obtaining a uniformly distributed test load sequence, and judging the impact degree of a load peak value on hardware resources.

Description

Technical Field

[0001] This invention relates to the field of server hardware testing technology, and in particular to a server hardware testing terminal and method. Background Technology

[0002] Server hardware testing is a core aspect of the information technology field, directly impacting the efficient operation of critical applications such as data centers, cloud computing, and information retrieval. Server hardware performance determines the system's response speed and stability under high load scenarios. Especially in information retrieval applications, hardware performance is crucial for handling massive amounts of data and real-time queries. However, existing testing methods are limited in that they often fail to comprehensively simulate the complex workloads of information retrieval scenarios, leading to test results that are out of touch with actual application requirements. Many testing schemes focus only on the performance of individual hardware components, neglecting the synergistic effects between storage devices, memory, and processors, making it difficult to accurately reflect hardware performance bottlenecks in dynamic, multi-tasking environments.

[0003] In information retrieval scenarios, a core challenge in hardware testing is accurately evaluating the collaborative efficiency of storage devices, memory, and processors during complex query operations. The read / write speed of storage devices directly impacts data retrieval response time, while memory access latency and processor cache hit rate determine the system's throughput under high-concurrency queries. For example, in a typical enterprise search scenario, a user might simultaneously initiate full-text searches and database queries, requiring the system to quickly extract results from a large dataset. In this case, insufficient IOPS (Input / Output Operations Per Second) of the storage device can lead to data read latency, while inefficient memory access further exacerbates the pressure on the processor cache, significantly extending query response time. This lack of hardware coordination not only affects user experience but can also cause the system to crash under high load.

[0004] Therefore, designing a testing method that can comprehensively evaluate the collaborative performance of storage devices, memory, and processors in high-concurrency, large-scale data processing by simulating complex information retrieval scenarios has become a key issue in the field of server hardware testing. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a server hardware testing terminal and method to address the shortcomings of the prior art.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A server hardware testing method, comprising: Obtain server hardware configuration parameters and storage device specification information; collect benchmark data on the number of processor cores, memory capacity and storage device read / write speed through the system monitoring interface; establish a hardware performance baseline profile; and obtain a complete hardware resource list and performance index range. Based on the characteristics of information retrieval scenarios, a multi-dimensional workload model is constructed. A random number generator is used to create query request sets of different sizes to simulate a mixed load mode of full-text retrieval and database query, and to determine the resource consumption weight and execution time distribution of various query operations. By analyzing the distribution characteristics of query requests in the workload model using a dynamic load balancing algorithm, if query requests are concentrated in a specific time period, the load distribution strategy is adjusted to obtain a uniformly distributed test load sequence and determine the impact of load peaks on hardware resources. The memory access pattern is preprocessed using a cache optimization algorithm. A cache hit rate prediction model is established based on the data access path of the query request. If the predicted hit rate is lower than the preset threshold, the data layout is reorganized to obtain the optimized memory access strategy and cache configuration scheme. The system obtains the response time of input / output operations of the storage device under different load conditions, sorts and groups concurrent query requests through a query scheduling algorithm, and initiates a query queue reorganization mechanism to determine the optimal query execution order if the storage device response time exceeds a preset limit. Based on processor cache usage and memory access latency data, performance monitoring tools are used to track the hardware collaboration status in real time. If the processor cache hit rate decreases or the memory access latency increases, the collaboration performance evaluation process is triggered to determine the collaboration efficiency between hardware components. By comprehensively analyzing the collaborative test results of storage devices, memory access, and processor performance, a multi-dimensional performance evaluation matrix is ​​established to obtain the actual performance of the hardware and potential bottleneck locations in complex information retrieval scenarios, resulting in a complete server hardware collaborative performance evaluation report.

[0007] Preferably, the step of obtaining server hardware configuration parameters and storage device specification information involves collecting baseline data on the number of processor cores, memory capacity, and storage device read / write speeds through a system monitoring interface to establish a hardware performance baseline profile, thereby obtaining a complete hardware resource list and performance index range, including: The system monitoring interface is used to obtain raw data on the number of processor cores, memory capacity, and storage device read / write speed, which is then stored as the initial dataset. Extract the number of processor cores and memory capacity from the initial dataset, and combine them with storage device read / write speed data to generate a hardware configuration parameter table; Based on the hardware configuration parameter table, calculate the statistical characteristic values ​​of the number of processor cores, memory capacity, and read / write speed to determine the performance benchmark value; If the performance benchmark value deviates from the preset threshold, the data is re-collected through the system monitoring interface, the hardware configuration parameter table is updated, and the calibrated performance benchmark value is obtained. A hardware performance baseline profile is established using calibrated performance benchmark values, including the range of indicators such as the number of processor cores, memory capacity, and read / write speeds. A complete hardware resource list is generated by using the hardware performance baseline profile, which includes server configuration parameters and performance indicator ranges. Based on the hardware resource list, real-time data is collected periodically through the system monitoring interface, compared with the performance index range, to determine the hardware resource status and update the baseline file.

[0008] Preferably, the step of constructing a multi-dimensional workload model based on the characteristics of the information retrieval scenario, using a random number generator to create query request sets of different sizes, simulating a mixed load mode of full-text retrieval and database query, and determining the resource consumption weights and execution time distributions of various query operations includes: The query request features are collected from information retrieval scenarios, and the request type, frequency and data size are extracted using preset sampling rules to generate a query feature dataset. Based on the query feature dataset, a random number generator is used to construct a set of query requests of different sizes and types, which is then stored as a simulated load dataset. Using a simulated load dataset, a mixed load test of full-text search and database query was performed to obtain resource consumption and execution time data for each query operation; If the resource consumption data exceeds the preset threshold, adjust the size and type of the query request set, re-execute the mixed load test, and obtain calibrated resource consumption data and execution time data; Based on the calibrated resource consumption data, calculate the resource consumption weights for various query operations and determine the weight allocation table; By analyzing the execution time data, we can generate a time distribution model by analyzing the execution time distribution of query operations. A multi-dimensional workload model is constructed using a weighted allocation table and a time distribution model to determine the resource consumption weights and execution time distribution ranges of query operations.

[0009] Preferably, the step of analyzing the distribution characteristics of query requests in the workload model using a dynamic load balancing algorithm, and adjusting the load allocation strategy if query requests are concentrated in a specific time period to obtain a uniformly distributed test load sequence, and determining the impact of load peaks on hardware resources, includes: The frequency and scale of query requests are obtained from time series data. The data is segmented using the sliding time window method, and the request distribution characteristics of each time period are statistically analyzed to obtain a distribution characteristic dataset. If the distribution feature dataset shows that the request frequency exceeds the preset threshold within a specific time period, the distribution ratio of query requests is adjusted through the consistent hashing algorithm to generate a balanced test load sequence. Based on the test load sequence, perform simulated load tests, collect CPU utilization and memory usage data of hardware resources, and obtain peak consumption datasets; By analyzing the peak consumption dataset, the load impact on hardware resources is analyzed, and a preset resource threshold is used for comparison to determine whether a resource bottleneck is triggered. If a resource bottleneck is triggered, the granularity of the time window segmentation is adjusted based on the peak consumption dataset, and the distribution feature dataset is regenerated. By using the regenerated distribution feature dataset, the allocation ratio of the consistent hashing algorithm is optimized to obtain the updated test load sequence; By using the updated test load sequence, a new round of load testing is performed to collect hardware resource consumption data and determine the final impact of the load peak on hardware resources.

[0010] Preferably, the step of preprocessing memory access patterns using a cache optimization algorithm, establishing a cache hit rate prediction model based on the data access path of the query request, and reorganizing the data layout if the predicted hit rate is lower than a preset threshold, results in an optimized memory access strategy and cache configuration scheme, including: Memory access path data is obtained from the query request, and the frequency characteristics of the access path are extracted using statistical analysis methods to obtain the path frequency dataset. Using the path frequency dataset, a cache hit rate prediction model based on logistic regression is constructed, and the predicted hit rate value is output. If the prediction hit rate is lower than the preset threshold, the data storage layout will be reorganized based on the path frequency dataset to generate an optimized storage layout scheme. By adopting the optimized storage layout scheme and updating the memory access paths, a new access path dataset is obtained. By adjusting cache configuration parameters using the new access path dataset, an optimized cache configuration scheme can be generated. Based on the optimized cache configuration scheme, perform memory access simulation tests, collect cache hit rate data, and determine the final cache hit rate; The applicability of the optimization scheme is verified by the final cache hit rate, and the optimized memory access strategy is obtained.

[0011] Preferably, the step of obtaining the input / output operation response time of the storage device under different load conditions involves sorting and grouping concurrent query requests using a query scheduling algorithm. If the storage device response time exceeds a preset limit, a query queue reorganization mechanism is initiated to determine the optimal query execution order, including: The response time data of input / output operations of storage devices under different load conditions are obtained, and the distribution characteristics of the response time are extracted using statistical analysis methods to obtain the response time dataset. Using response time datasets, a query request priority prediction model based on decision trees is constructed, and the priority ranking results are output. Based on the priority sorting results, concurrent query requests are grouped and processed to generate a query request group dataset; If the response time of the query request group dataset exceeds a preset threshold, the queue reorganization algorithm is used to adjust the execution order of the query requests to obtain an optimized query execution order. By optimizing the query execution order, the query scheduling configuration of the storage device is updated, and a new scheduling configuration scheme is generated. A new scheduling configuration scheme was adopted to perform input / output operation simulation tests on storage devices, collect actual response time data, and determine the final query response time. Based on the final query response time, the allocation strategy for concurrent query requests is adjusted to obtain an optimized query allocation scheme.

[0012] Preferably, based on processor cache usage and memory access latency data, a performance monitoring tool is used to track the hardware collaboration status in real time. If the processor cache hit rate decreases or the memory access latency increases, a collaborative performance evaluation process is triggered to determine the collaboration efficiency between hardware components, including: The processor cache hit rate and memory access latency data are collected in real time using performance monitoring tools to generate a hardware performance status dataset. If the cache hit rate in the hardware performance status dataset is lower than the preset threshold or the memory access latency exceeds the preset threshold, the hardware performance status dataset is analyzed using the support vector machine algorithm to determine the hardware co-efficiency level. Based on the hardware co-efficiency level, the k-means clustering algorithm is used to group the performance bottlenecks of processor cache and memory access, resulting in a performance bottleneck group dataset. By grouping datasets based on performance bottlenecks, the processor cache allocation strategy is adjusted to generate an optimized cache allocation configuration; The optimized cache allocation configuration is used to update the memory access scheduling parameters and generate a new memory access scheduling scheme. By using a new memory access scheduling scheme, hardware co-operation performance simulation tests are performed, and adjusted performance status data is collected to obtain an optimized hardware co-operation efficiency dataset. Based on the optimized hardware collaboration efficiency dataset, a decision tree algorithm is used to predict the performance trend of hardware collaboration and generate performance optimization and adjustment strategies.

[0013] Preferably, by comprehensively analyzing the collaborative test results of storage devices, memory access, and processor performance, a multi-dimensional performance evaluation matrix is ​​established to obtain the actual performance of the hardware and potential bottleneck locations in complex information retrieval scenarios, resulting in a complete server hardware collaborative performance evaluation report, including: The performance monitoring tool continuously collects data on storage device access speed, memory access latency, and processor computing performance from the hardware co-performance bottleneck dataset to generate a real-time performance status dataset. Using a real-time performance status dataset, the random forest algorithm is employed to analyze the collaborative efficiency among storage devices, memory, and processors, and to determine the hardware collaborative performance level. If the hardware collaboration performance level is lower than the preset threshold, the performance bottlenecks in the real-time performance status dataset are grouped by cluster analysis to obtain a performance bottleneck classification dataset. Based on the performance bottleneck classification dataset, adjust the access priority parameters of the storage devices to generate an optimized storage access configuration. By optimizing the storage access configuration, the memory access scheduling policy is updated, and a new memory access scheduling scheme is generated. A new memory access scheduling scheme was adopted to perform performance simulation tests on complex information retrieval scenarios, and the adjusted performance data was collected to obtain an optimized hardware co-performance dataset. Based on the optimized hardware co-performance dataset, the performance change trend is analyzed, and a dynamic adjustment strategy for performance optimization is generated.

[0014] A server hardware testing terminal includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor as described in the claims, wherein the processor executes the computer program to implement the steps of the server hardware testing method.

[0015] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a server hardware testing terminal and method. It constructs a unified performance evaluation and optimization framework through multi-dimensional workload modeling, dynamic load balancing, and cache optimization algorithms. It establishes a hardware performance baseline by collecting processor core count, memory capacity, and storage device read / write speeds through a system monitoring interface. It simulates a mixed load of full-text retrieval and database queries using a random number generator, analyzing resource consumption weights and execution time distribution. A dynamic load balancing algorithm optimizes query request distribution, reducing load peak impacts. A cache hit rate prediction model optimizes memory access strategies. A query scheduling algorithm reorganizes concurrent query queues, reducing storage device response latency. Real-time monitoring of processor cache and memory access latency evaluates hardware coordination efficiency. Finally, a multi-dimensional performance evaluation matrix reveals hardware performance bottlenecks and optimizes resource allocation, thereby significantly improving server query processing efficiency and system stability in complex information retrieval scenarios. Attached Figure Description

[0016] Figure 1 This is a flowchart of a server hardware testing terminal and method according to the present invention. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] like Figure 1 As shown, this embodiment of a server hardware testing terminal and method may specifically include: Step S101: Obtain server hardware configuration parameters and storage device specification information. Collect benchmark data on the number of processor cores, memory capacity, and storage device read / write speed through the system monitoring interface to establish a hardware performance baseline profile and obtain a complete hardware resource list and performance index range.

[0019] Raw data on the number of processor cores, memory capacity, and storage device read / write speeds are acquired through the system monitoring interface and stored as an initial dataset. The number of processor cores and memory capacity are extracted from the initial dataset and combined with storage device read / write speed data to generate a hardware configuration parameter table. Based on the hardware configuration parameter table, statistical characteristic values ​​of the number of processor cores, memory capacity, and read / write speeds are calculated to determine performance benchmark values. If the performance benchmark value deviates from a preset threshold, data is re-collected through the system monitoring interface to update the hardware configuration parameter table and obtain a calibrated performance benchmark value. Using the calibrated performance benchmark value, a hardware performance baseline profile is established, including the range of indicators for the number of processor cores, memory capacity, and read / write speeds. A complete hardware resource list, including server configuration parameters and performance indicator ranges, is generated from the hardware performance baseline profile. Based on the hardware resource list, real-time data is periodically collected through the system monitoring interface, compared with the performance indicator ranges, the hardware resource status is determined, and the baseline profile is updated.

[0020] For example, in server hardware performance monitoring scenarios, it's necessary to obtain raw data on the number of processor cores, memory capacity, and storage device read / write speeds through the system monitoring interface. The system monitoring interface can utilize tools provided by the operating system, such as the `lscpu` command in Linux to obtain the number of cores, the `free` command to obtain memory capacity, and the `iostat` or `fio` tools to obtain storage device read / write speeds. Assuming a server has an 8-core processor as detected by `lscpu`, 64GB of memory as displayed by the `free` command, and sequential read / write speeds of 500MB / s and 400MB / s respectively as shown by the `fio` test, this data constitutes the initial dataset, providing a foundation for subsequent analysis. The data collection frequency can be set to once per hour to ensure that the data reflects the real-time status of the hardware.

[0021] Specifically, a hardware configuration parameter table is extracted based on the initial dataset. The parameter table includes the number of processor cores (8), memory capacity (64GB), and storage read / write speeds of 500MB / s and 400MB / s. During the generation of this table, a script can automatically organize the data into a table, ensuring data structure and facilitating analysis. The generation of the parameter table facilitates unified management of hardware information and provides an intuitive basis for performance evaluation.

[0022] In one possible implementation, statistical characteristic values ​​are calculated to determine performance benchmark values.

[0023] For example, after collecting data continuously for a week, with a constant 8 processor cores and a stable 64GB of memory, the average storage read and write speeds were 490MB / s and 390MB / s, respectively, with standard deviations of 10MB / s and 8MB / s. The performance benchmark can be set as the average value, with read and write speed fluctuations within ±2 standard deviations, i.e., read speed 470-510MB / s and write speed 374-406MB / s. If the preset threshold requires a read speed of no less than 480MB / s, and an average read speed of 490MB / s meets the requirement, but some time points show speeds below 480MB / s, this indicates a deviation.

[0024] For example, to address deviations, data is re-collected through the system monitoring interface to update the hardware configuration parameter table. Assuming the newly collected data indicates a stable read speed of 495MB / s and a write speed of 395MB / s, the updated parameter table reflects a more accurate performance status. The calibrated performance baseline is set at a read speed of 480-510MB / s and a write speed of 380-410MB / s. This calibration ensures that the baseline values ​​are closer to actual operating conditions, avoiding misjudgments due to temporary fluctuations.

[0025] Specifically, a hardware performance baseline profile is established, including the number of processor cores (8), memory capacity (64GB), and read / write speeds ranging from 480-510MB / s and 380-410MB / s. The profile can be stored in JSON format for easy system retrieval and updates. The baseline profile provides a reference standard for performance monitoring, ensuring the hardware operates within expected ranges.

[0026] In one possible implementation, a hardware resource inventory is generated, including server configuration parameters and performance metric ranges. The inventory displays the server model, number of cores, memory capacity, and read / write speed range, along with hardware serial numbers and deployment locations. Real-time data is collected periodically, such as daily monitoring of read / write speeds via iostat, and compared to a baseline profile. If a read speed of 460MB / s is collected, below the baseline range, an alarm is triggered and logged, indicating potential hardware aging or excessive load issues. When updating the baseline profile, the range can be adjusted based on long-term data trends, such as adjusting the read speed range to 475-515MB / s to reflect changes in hardware performance.

[0027] Understandably, this approach ensures the visibility and controllability of hardware resource status through continuous monitoring and baseline updates. Regularly comparing real-time data with baseline profiles can promptly identify performance bottlenecks, improve system maintenance efficiency, and ensure stable server operation.

[0028] Step S102: Construct a multi-dimensional workload model based on the characteristics of the information retrieval scenario, use a random number generator to create query request sets of different sizes, simulate the mixed load mode of full-text retrieval and database query, and determine the resource consumption weight and execution time distribution of various query operations.

[0029] Query request features are collected from information retrieval scenarios. Request types, frequencies, and data sizes are extracted using preset sampling rules to generate a query feature dataset. A random number generator is used to construct a set of query requests of different sizes and types based on the query feature dataset, which is stored as a simulated load dataset. Using the simulated load dataset, a mixed load test of full-text search and database queries is performed to obtain resource consumption and execution time data for each query operation. If the resource consumption data exceeds a preset threshold, the size and type of the query request set are adjusted, and the mixed load test is re-executed to obtain calibrated resource consumption and execution time data. Based on the calibrated resource consumption data, the resource consumption weights of various query operations are calculated, and a weight allocation table is determined. The execution time distribution of query operations is analyzed using execution time data to generate a time distribution model. Using the weight allocation table and the time distribution model, a multi-dimensional workload model is constructed to determine the resource consumption weights and execution time distribution ranges of query operations.

[0030] For example, in information retrieval scenarios, collecting query request characteristics requires clearly defined sampling rules to ensure data comprehensiveness. Sampling rules can be based on request type (e.g., full-text search, database query), frequency (e.g., requests per second), and data size (e.g., the number of records returned by the query). Suppose a company's search engine system has sampling rules set to record request type, frequency, and data size once per minute, collecting data for one day. The results show that full-text searches account for 60%, database queries account for 40%, with an average of 10 requests per second, and the data size fluctuating between 100 and 1000 records. This data constitutes a query feature dataset, reflecting the system's load characteristics.

[0031] In one possible implementation, a simulated load dataset is constructed using a random number generator based on the query feature dataset. The random number generator generates requests according to the collected proportions, such as 60% full-text search and 40% database queries, at a frequency of 8-12 times per second, with the data size randomly distributed between 100-1000 records. The generated dataset contains 10,000 simulated requests, stored in JSON format for easy testing. The simulated load dataset ensures that the test scenario closely resembles reality.

[0032] For example, a mixed load test was performed using a simulated load dataset. The test environment was a server equipped with a 16-core processor and 128GB of memory. Full-text search was performed using Elasticsearch, and database queries were performed using MySQL. The test results showed that the average execution time for full-text search was 50 milliseconds, consuming 20% ​​of CPU resources; the average execution time for database queries was 80 milliseconds, consuming 30% of CPU resources. If the preset CPU threshold is 25%, the database query exceeded the threshold. Adjusting the request set and reducing the database query ratio to 30%, after retesting, the database query resource consumption dropped to 22%, meeting the threshold.

[0033] In one possible implementation, resource consumption weights are calculated based on calibrated data. Full-text search has a weight of 0.4, and database query has a weight of 0.6, generating a weight allocation table. Analyzing execution time data and plotting a time distribution model reveals that full-text search times are concentrated between 40-60 milliseconds, while database query times are concentrated between 70-90 milliseconds. Based on the weight allocation table and the time distribution model, a multi-dimensional workload model is constructed, determining that the resource consumption weight for full-text search is 0.4, with a time distribution of 40-60 milliseconds; and the weight for database query is 0.6, with a time distribution of 70-90 milliseconds.

[0034] Understandably, the weight allocation table and time distribution model provide a basis for optimizing query scheduling.

[0035] For example, scheduling algorithms can prioritize resource allocation for database queries, reducing bottlenecks under high load. The model can also be used to predict system performance under different loads, ensuring reasonable resource allocation and improving retrieval efficiency.

[0036] Step S103: Analyze the distribution characteristics of query requests in the workload model using a dynamic load balancing algorithm. If the query requests are concentrated in a specific time period, adjust the load distribution strategy to obtain a uniformly distributed test load sequence and determine the impact of load peaks on hardware resources.

[0037] The frequency and scale of query requests are obtained from time-series data. A sliding time window method is used to segment the data, and the request distribution characteristics of each time period are statistically analyzed to obtain a distribution characteristic dataset. If the distribution characteristic dataset shows that the request frequency exceeds a preset threshold within a specific time period, the allocation ratio of query requests is adjusted using a consistent hashing algorithm to generate a balanced test load sequence. Based on the test load sequence, simulated load tests are performed, and CPU utilization and memory usage data of hardware resources are collected to obtain a peak consumption dataset. The load impact on hardware resources is analyzed using the peak consumption dataset, and a preset resource threshold is used for comparison to determine whether a resource bottleneck has been triggered. If a resource bottleneck is triggered, the granularity of the time window segmentation is adjusted based on the peak consumption dataset, and a new distribution characteristic dataset is generated. Using the regenerated distribution characteristic dataset, the allocation ratio of the consistent hashing algorithm is optimized to obtain an updated test load sequence. A new round of load testing is performed using the updated test load sequence, and hardware resource consumption data is collected to determine the final impact of the load peak on hardware resources.

[0038] Specifically, in information retrieval scenarios, time-series data reflects the dynamic changes in query requests and can be used to analyze system load patterns.

[0039] For example, segmenting time series data using the sliding time window method can effectively capture the fluctuations in request frequency and scale. The core of the sliding time window is to divide a continuous time series into fixed-length time segments and statistically analyze the request distribution within each segment. Suppose a company's search engine system generates 10 to 20 query requests per second, with the data size varying between 200 and 800 records. Setting the time window to 5 minutes and the sliding step to 1 minute, the statistical results show that the request frequency during the weekday morning peak (8-10 AM) reaches 18 times per second, exceeding the preset threshold of 15 times per second, while the frequency is lower during other time periods, approximately 12 times per second. This distribution characteristic dataset reveals load peaks, providing a basis for subsequent optimization.

[0040] In one possible implementation, a consistent hashing algorithm is used to adjust the distribution ratio of query requests based on the distributed characteristic dataset in order to balance the load.

[0041] For example, during high-frequency periods, full-text search requests accounted for 70%, while database queries accounted for 30%. The consistent hashing algorithm dynamically distributes requests across multiple servers by mapping them to a node ring. Assuming the test environment contains four servers, the initial allocation caused one server to become overloaded, with CPU utilization reaching 35%, exceeding the 25% threshold. Through algorithmic adjustments, the database query ratio was reduced to 20%. After redistribution, the CPU utilization of the single server dropped to 22%, and the load became more balanced. The generated test load sequence contained 10,000 requests, simulating peak scenarios to ensure the test closely resembled real-world conditions.

[0042] Specifically, simulated load tests were performed based on a test load sequence to collect hardware resource data. The test environment consisted of a server with a 16-core processor and 128GB of memory, running Elasticsearch and MySQL. Test results showed that at peak times, CPU utilization reached 30% and memory usage reached 60GB, without triggering the preset bottleneck thresholds of 35% CPU and 70GB memory. The peak consumption dataset indicates that the system remained stable under high load, but memory usage was close to the critical value.

[0043] It should be noted that if memory usage remains close to the threshold, it may lead to performance degradation. Therefore, the time window granularity was adjusted to 3 minutes, and the distribution characteristic dataset was regenerated. It was found that peak request volumes were concentrated between 500 and 600 records. The consistent hashing algorithm was further optimized to distribute requests more evenly, reducing the memory usage of a single server to 55GB.

[0044] In one possible implementation, the updated test load sequence is used for a new round of load testing to collect final resource consumption data. Results show that CPU utilization stabilized at 20% to 25%, memory usage decreased to 50GB, and the load impact was significantly reduced.

[0045] Preferably, this method optimizes resource utilization by dynamically adjusting the time window and allocation ratio, reduces the risk of bottlenecks during peak periods, and improves the stability of the system under dynamic loads.

[0046] It should be noted that the analysis and optimization based on the distributed characteristic dataset can also provide a reference for scheduling strategies, such as prioritizing the allocation of more computing resources to high-frequency requests, thereby further improving query efficiency.

[0047] Step S104: The memory access pattern is preprocessed using a cache optimization algorithm. A cache hit rate prediction model is established based on the data access path of the query request. If the predicted hit rate is lower than a preset threshold, the data layout is reorganized to obtain the optimized memory access strategy and cache configuration scheme.

[0048] Memory access path data is obtained from query requests. Statistical analysis methods are used to extract frequency features of the access paths, resulting in a path frequency dataset. Using this dataset, a logistic regression-based cache hit rate prediction model is constructed, outputting a predicted hit rate value. If the predicted hit rate is lower than a preset threshold, the data storage layout is reorganized based on the path frequency dataset, generating an optimized storage layout scheme. The optimized storage layout scheme is then used to update the memory access paths, resulting in a new access path dataset. Using this new dataset, cache configuration parameters are adjusted to generate an optimized cache configuration scheme. Based on the optimized scheme, memory access simulation tests are performed, and cache hit rate data is collected to determine the final cache hit rate. The final cache hit rate is used to verify the applicability of the optimized scheme, resulting in an optimized memory access strategy.

[0049] Specifically, in information retrieval scenarios, the memory access path data of query requests reflects the patterns of user data access, and analyzing the frequency characteristics of these paths helps to optimize caching strategies.

[0050] For example, statistical analysis methods can be used to extract frequency characteristics of access paths from query requests. Suppose a corporate search engine system processes 1000 query requests per minute, involving 100 different access paths. Statistical results show that 10% of the paths account for 60% of the access frequency, indicating a hotspot access pattern. The path frequency dataset records the number of times each path is accessed, such as path A being accessed 200 times per minute and path B being accessed 50 times per minute. This dataset provides a foundation for subsequent cache hit rate prediction. Based on the path frequency dataset, a logistic regression model is constructed to predict the cache hit rate.

[0051] For example, the model takes input features such as path frequency and access time interval, and outputs a predicted cache hit rate. Suppose the prediction shows a hit rate of 70% under the current cache configuration, which is lower than the preset threshold of 80%. This indicates that the cache is not effectively covering high-frequency paths, and the storage layout needs to be optimized.

[0052] In one possible implementation, the data storage layout is reorganized based on the path frequency dataset, prioritizing the storage of high-frequency paths A and B in the cache area to generate an optimized storage layout scheme.

[0053] For example, data in path A can be migrated from a mechanical hard drive to a solid-state drive to reduce access latency. An optimized storage layout is then used to update the memory access paths, generating a new access path dataset.

[0054] For example, the new dataset shows that the access latency for path A decreased from 10 milliseconds to 5 milliseconds, while the access frequency for path B slightly increased. Based on the new dataset, adjust cache configuration parameters, such as increasing the cache size to 2GB and setting a shorter cache expiration time, to generate an optimized cache configuration scheme.

[0055] Specifically, the caching configuration prioritizes high-frequency paths to ensure that frequently accessed data remains in the cache. Based on the optimized caching configuration, memory access simulation tests are performed to collect cache hit rate data.

[0056] For example, the test environment consisted of a server with a 32-core processor and 256GB of memory, running a Redis caching system. Test results showed that the cache hit rate increased to 85%, exceeding the threshold of 80%. The applicability of the optimization scheme was verified through the final cache hit rate.

[0057] Preferably, the new memory access strategy dynamically adjusts cache allocation based on high-frequency paths, which significantly improves query efficiency, reduces access latency, and ensures the stability of the system under high load scenarios.

[0058] Step S105: Obtain the input / output operation response time of the storage device under different load conditions, sort and group concurrent query requests through a query scheduling algorithm, and if the response time of the storage device exceeds the preset limit, start the query queue reorganization mechanism to determine the optimal query execution order.

[0059] Response time data for input / output operations of the storage device under different load conditions are obtained. Statistical analysis methods are used to extract the distribution characteristics of the response time, resulting in a response time dataset. Using this dataset, a decision tree-based query request priority prediction model is constructed, outputting priority ranking results. Based on the priority ranking results, concurrent query requests are grouped, generating query request group datasets. If the response time of a query request group dataset exceeds a preset threshold, a queue reorganization algorithm is used to adjust the execution order of the query requests, resulting in an optimized query execution order. Based on the optimized query execution order, the query scheduling configuration of the storage device is updated, generating a new scheduling configuration scheme. Using the new scheduling configuration scheme, input / output operation simulation tests of the storage device are performed, collecting actual response time data to determine the final query response time. Based on the final query response time, the allocation strategy for concurrent query requests is adjusted, resulting in an optimized query allocation scheme.

[0060] Specifically, in information retrieval scenarios, the response time of input / output operations on storage devices directly impacts query efficiency. When obtaining response time data, performance metrics under different loads can be collected using monitoring tools.

[0061] For example, in an enterprise search engine system, 2000 queries are processed per minute during peak hours, and only 500 during off-peak hours. The collected data includes the response time for each query, such as an average response time of 15 milliseconds during peak hours and 8 milliseconds during off-peak hours. This data constitutes a response time dataset, reflecting the impact of load on performance. Statistical analysis methods can extract distribution characteristics, such as the mean, median, and 90th percentile of the response time.

[0062] For example, analysis shows that the 90th percentile response time during peak periods is 20 milliseconds, indicating latency in some queries. Based on the response time dataset, a decision tree model is built to predict query request priorities. The decision tree outputs a priority ranking based on features such as query type, data volume, and load level.

[0063] For example, queries involving complex aggregations have higher priority than simple lookup queries.

[0064] Specifically, the model might mark queries involving full-text search as high priority, while single-field queries would be low priority. For example, a query request involving 10MB of data might be predicted as high priority and require priority scheduling. Concurrent query requests are then grouped based on the priority ranking.

[0065] For example, high-priority queries are assigned to the fast response group, and low-priority queries are assigned to the normal group. The grouped dataset records the response time for each group; for example, the fast response group averages 10 milliseconds, and the normal group averages 18 milliseconds. If the response time of the fast response group exceeds the threshold of 15 milliseconds, the queue reorganization algorithm is triggered.

[0066] Preferably, the algorithm adjusts the execution order based on priority and data dependency, such as moving high-priority queries to the head of the queue to generate an optimized query execution order. The optimized execution order is then used to update the query scheduling configuration of the storage device.

[0067] For example, the scheduling strategy can be adjusted to prioritize high-priority queries, allocating more thread resources to the fast response group. The new scheduling configuration might set the thread pool size to 16 and the priority queue depth to 100. Simulated tests are performed using a server equipped with a 64-core processor and 512GB of memory, running a distributed storage system. Actual response time data collected might show the fast response group's response time reduced to 12 milliseconds. Based on the final response time, the concurrent query allocation strategy can be adjusted.

[0068] For example, the concurrency limit for high-priority queries can be increased from 50 to 80 to ensure rapid response to frequently accessed queries. Optimized query allocation schemes may further subdivide query types, such as allocating queries with high real-time requirements to dedicated storage nodes. This approach improves query efficiency by dynamically adjusting resource allocation.

[0069] One possible implementation involves optimizing the grouping strategy by incorporating historical access patterns.

[0070] For example, if analysis reveals that a certain type of query occurs frequently during peak weekday hours, more cache resources can be pre-allocated.

[0071] It should be noted that the scheduling configuration needs to be updated regularly to adapt to changes in load.

[0072] Preferably, the system can dynamically adjust the priority model through machine learning to adapt to new query patterns. This multi-level optimization scheme, through data-driven and dynamic adjustments, ensures efficient system operation under high load.

[0073] Step S106: Based on processor cache usage and memory access latency data, use performance monitoring tools to track the hardware collaboration status in real time. If the processor cache hit rate decreases or the memory access latency increases, trigger the collaboration performance evaluation process to determine the collaboration efficiency between hardware components.

[0074] A hardware performance status dataset is generated by using performance monitoring tools to collect processor cache hit rate and memory access latency data in real time. If the cache hit rate in the hardware performance status dataset is lower than a preset threshold or the memory access latency exceeds a preset threshold, the dataset is analyzed using a support vector machine algorithm to determine the hardware co-operation efficiency level. Based on the hardware co-operation efficiency level, a k-means clustering algorithm is used to group the performance bottlenecks of processor cache and memory access, resulting in a performance bottleneck group dataset. Using the performance bottleneck group dataset, the processor cache allocation strategy is adjusted to generate an optimized cache allocation configuration. Using the optimized cache allocation configuration, the memory access scheduling parameters are updated to generate a new memory access scheduling scheme. Hardware co-operation performance simulation tests are performed using the new memory access scheduling scheme, and the adjusted performance status data is collected to obtain an optimized hardware co-operation efficiency dataset. Based on the optimized hardware co-operation efficiency dataset, a decision tree algorithm is used to predict the hardware co-operation performance trend and generate a performance optimization adjustment strategy.

[0075] For example, in enterprise-level distributed storage systems, performance monitoring tools can collect processor cache hit rate and memory access latency data in real time, forming a hardware performance status dataset. Performance monitoring tools obtain cache hit rate through hardware counters.

[0076] For example, in high-load scenarios, the processor processes 100 million instructions per second with a cache hit rate of 85%, while in low-load scenarios, the hit rate is 95%. Memory access latency data is obtained by tracking the completion time of memory requests.

[0077] For example, the average latency is 50 nanoseconds under high load and 30 nanoseconds under low load. These data constitute a hardware performance status dataset, reflecting the system's operating status under different loads.

[0078] Specifically, if the cache hit rate is below a preset threshold of 90% or the memory access latency exceeds 40 nanoseconds, the system analyzes the dataset using a support vector machine (SVM) algorithm to determine the hardware co-efficiency level. Based on features such as cache hit rate, memory access latency, and instruction throughput, the SVM classifies performance into three levels: high efficiency, medium efficiency, and low efficiency.

[0079] For example, a hit rate of 85% and a latency of 50 nanoseconds under high load might be classified as inefficient. The analysis process trains a model using historical performance data to identify patterns in performance bottlenecks.

[0080] In one possible implementation, the k-means clustering algorithm is used to group performance bottlenecks based on hardware co-efficiency levels. The algorithm takes cache hit rate and memory access latency as input, classifying bottlenecks into two groups: cache-intensive and memory-access-intensive.

[0081] For example, cache-intensive bottlenecks show hit rates as low as 80%, while memory access-intensive bottlenecks show latency as high as 60 nanoseconds. Grouped datasets provide a basis for subsequent optimization, identifying which hardware resources need to be prioritized for adjustment.

[0082] For example, by grouping datasets based on performance bottlenecks, processor cache allocation strategies can be adjusted. Cache-intensive bottlenecks may require increasing the proportion of L2 cache allocation.

[0083] For example, the L2 cache can be increased from 2MB to 4MB to reduce cache misses. After generating the optimized cache allocation configuration, the memory access scheduling parameters are updated.

[0084] For example, setting the memory prefetching strategy to a more aggressive mode increases the amount of data prefetched from 64KB to 128KB, generating a new memory access scheduling scheme.

[0085] Specifically, the new memory access scheduling scheme was validated in simulated tests. The test environment consisted of a server equipped with a 128-core processor and 1TB of memory, running a distributed storage system. The collected performance data showed that the optimized cache hit rate increased to 92%, and memory access latency decreased to 35 nanoseconds, forming an optimized hardware co-operation efficiency dataset. These data reflect more rational resource allocation and more stable system performance.

[0086] In one possible implementation, a decision tree algorithm predicts hardware co-operation performance trends based on an optimized hardware co-operation efficiency dataset. The decision tree, characterized by cache hit rate, memory access latency, and load level, outputs performance optimization tuning strategies.

[0087] For example, forecasts indicate that cache hit rates may further decline under high load, suggesting dynamically increasing cache allocation to 6MB and limiting memory access for low-priority tasks. Adjustment strategies should combine historical trends and real-time data to ensure long-term efficient system operation.

[0088] For example, for high-load scenarios, optimization strategies may further refine cache allocation.

[0089] For example, the dedicated cache for hot data can be expanded from 1MB to 2MB to improve the hit rate.

[0090] It should be noted that regularly updating scheduling parameters can adapt to load changes.

[0091] For example, performance data is analyzed weekly to dynamically adjust prefetching strategies and cache allocation. This data-driven optimization approach ensures efficient system operation in complex scenarios.

[0092] Step S107: By comprehensively analyzing the collaborative test results of storage devices, memory access, and processor performance, a multi-dimensional performance evaluation matrix is ​​established to obtain the actual performance of the hardware and potential bottleneck locations in complex information retrieval scenarios, resulting in a complete server hardware collaborative performance evaluation report.

[0093] A performance monitoring tool continuously collects data on storage device access speed, memory access latency, and processor computing performance from a hardware co-operation performance bottleneck dataset, generating a real-time performance status dataset. Using this dataset, a random forest algorithm is employed to analyze the collaborative efficiency between storage devices, memory, and the processor, determining the hardware co-operation performance level. If the hardware co-operation performance level is below a preset threshold, cluster analysis is used to group performance bottlenecks in the real-time performance status dataset, resulting in a performance bottleneck classification dataset. Based on this classification dataset, the access priority parameters of the storage devices are adjusted to generate an optimized storage access configuration. Using this optimized configuration, the memory access scheduling policy is updated, generating a new memory access scheduling scheme. Using this new scheme, performance simulation tests are performed on a complex information retrieval scenario, collecting adjusted performance data to obtain an optimized hardware co-operation performance dataset. Based on this optimized dataset, performance trends are analyzed to generate a dynamic adjustment strategy for performance optimization.

[0094] For example, in enterprise-level distributed storage systems, performance monitoring tools continuously collect data on storage device access speed, memory access latency, and processor computing performance to create a real-time performance status dataset. Storage device access speed reflects the storage system's responsiveness, such as the number of input / output operations per second (IOPS). Memory access latency measures the time it takes for memory requests to complete, such as average latency. Processor computing performance is evaluated by the number of instructions executed per second (CPS). Assuming a high-load scenario, the collected data shows a storage device access speed of 5000 operations per second, a memory access latency of 45 nanoseconds, and a processor processing 120 million instructions per second. This data constitutes a real-time performance status dataset, reflecting the collaborative operating status of the hardware.

[0095] Specifically, the Random Forest algorithm analyzes real-time performance state datasets to evaluate the collaborative efficiency among storage devices, memory, and processors. Random Forest uses multiple decision trees to make a comprehensive judgment, using storage device access speed, memory access latency, and processor computing performance as characteristics to output a collaborative performance level.

[0096] For example, under high load, if the access speed is less than 6000 times per second and the latency exceeds 40 nanoseconds, the algorithm may classify it as medium efficiency. The analysis process uses historical data to train the model, identify patterns in collaborative efficiency, and ensure accurate classification.

[0097] In one possible implementation, if the collaborative performance level is below a preset threshold, such as medium or low efficiency, cluster analysis groups the performance bottlenecks. Using the K-means clustering algorithm, with access speed and latency as input, the bottlenecks are classified into storage-intensive and compute-intensive types.

[0098] For example, storage-intensive bottlenecks show access speeds of only 4,000 times per second, while compute-intensive bottlenecks show processor instruction execution rates dropping to 80 million instructions per second. The grouped performance bottleneck classification datasets provide a basis for optimization, identifying hardware resources that need priority adjustment.

[0099] For example, based on a performance bottleneck classification dataset, adjust the storage device access priority parameters. Storage-intensive bottlenecks may require increasing the storage queue depth for high-priority tasks, such as from 10 requests to 20, generating an optimized storage access configuration. This configuration reduces the storage resource consumption of low-priority tasks and improves access speed.

[0100] Specifically, the optimized storage access configuration guides the update of memory access scheduling policies.

[0101] For example, to address storage-intensive bottlenecks, a more efficient memory prefetching strategy can be implemented, such as increasing the prefetched data size from 32KB to 64KB, generating a new memory access scheduling scheme. This scheme ensures that memory data is available more quickly and reduces latency.

[0102] In one possible implementation, the new memory access scheduling scheme undergoes performance simulation testing under complex information retrieval scenarios. The test environment is a server equipped with a 256-core processor and 2TB of memory, running a distributed storage system. Data collected shows that the optimized access speed increases to 7000 times per second, and latency decreases to 38 nanoseconds, forming an optimized hardware-coordinated performance dataset. This data reflects more rational resource allocation and more efficient system operation.

[0103] For example, based on an optimized hardware co-performance dataset, a decision tree algorithm analyzes performance trends, using access speed, latency, and load levels as characteristics to generate dynamic adjustment strategies. If it predicts that access speed may decrease under high load, it suggests dynamically increasing the storage queue depth to 25 requests and limiting memory access for low-priority tasks. This strategy combines historical and real-time data to ensure long-term efficient system operation.

[0104] Specifically, performance data is analyzed regularly, such as updating scheduling parameters every three days, and dynamically adjusting storage access priorities and memory prefetching strategies. This data-driven optimization ensures efficient operation in complex scenarios and significantly improves system stability and responsiveness.

[0105] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A server hardware testing method, characterized in that, include: Obtain server hardware configuration parameters and storage device specification information; collect benchmark data on the number of processor cores, memory capacity and storage device read / write speed through the system monitoring interface; establish a hardware performance baseline profile; and obtain a complete hardware resource list and performance index range. Based on the characteristics of information retrieval scenarios, a multi-dimensional workload model is constructed. A random number generator is used to create query request sets of different sizes to simulate a mixed load mode of full-text retrieval and database query, and to determine the resource consumption weight and execution time distribution of various query operations. By analyzing the distribution characteristics of query requests in the workload model using a dynamic load balancing algorithm, if query requests are concentrated in a specific time period, the load distribution strategy is adjusted to obtain a uniformly distributed test load sequence and determine the impact of load peaks on hardware resources. The memory access pattern is preprocessed using a cache optimization algorithm. A cache hit rate prediction model is established based on the data access path of the query request. If the predicted hit rate is lower than the preset threshold, the data layout is reorganized to obtain the optimized memory access strategy and cache configuration scheme. The system obtains the response time of input / output operations of the storage device under different load conditions, sorts and groups concurrent query requests through a query scheduling algorithm, and initiates a query queue reorganization mechanism to determine the optimal query execution order if the storage device response time exceeds a preset limit. Based on processor cache usage and memory access latency data, performance monitoring tools are used to track the hardware collaboration status in real time. If the processor cache hit rate decreases or the memory access latency increases, the collaboration performance evaluation process is triggered to determine the collaboration efficiency between hardware components. By comprehensively analyzing the collaborative test results of storage devices, memory access, and processor performance, a multi-dimensional performance evaluation matrix is ​​established to obtain the actual performance of the hardware and potential bottleneck locations in complex information retrieval scenarios, resulting in a complete server hardware collaborative performance evaluation report.

2. The server hardware testing method according to claim 1, characterized in that, The process involves acquiring server hardware configuration parameters and storage device specifications, collecting baseline data on the number of processor cores, memory capacity, and storage device read / write speeds through the system monitoring interface, establishing a hardware performance baseline profile, and obtaining a complete hardware resource list and performance indicator range, including: The system monitoring interface is used to obtain raw data on the number of processor cores, memory capacity, and storage device read / write speed, which is then stored as the initial dataset. Extract the number of processor cores and memory capacity from the initial dataset, and combine them with storage device read / write speed data to generate a hardware configuration parameter table; Based on the hardware configuration parameter table, calculate the statistical characteristic values ​​of the number of processor cores, memory capacity, and read / write speed to determine the performance benchmark value; If the performance benchmark value deviates from the preset threshold, the data is re-collected through the system monitoring interface, the hardware configuration parameter table is updated, and the calibrated performance benchmark value is obtained. A hardware performance baseline profile is established using calibrated performance benchmark values, including the range of indicators such as the number of processor cores, memory capacity, and read / write speeds. A complete hardware resource list is generated by using the hardware performance baseline profile, which includes server configuration parameters and performance indicator ranges. Based on the hardware resource list, real-time data is collected periodically through the system monitoring interface, compared with the performance index range, to determine the hardware resource status and update the baseline file.

3. The server hardware testing method according to claim 1, characterized in that, The process involves constructing a multi-dimensional workload model based on the characteristics of information retrieval scenarios. This model uses a random number generator to create query request sets of different sizes, simulating a mixed load mode of full-text retrieval and database queries. It determines the resource consumption weights and execution time distributions for various query operations, including: The query request features are collected from information retrieval scenarios, and the request type, frequency and data size are extracted using preset sampling rules to generate a query feature dataset. Based on the query feature dataset, a random number generator is used to construct a set of query requests of different sizes and types, which is then stored as a simulated load dataset. Using a simulated load dataset, a mixed load test of full-text search and database query was performed to obtain resource consumption and execution time data for each query operation; If the resource consumption data exceeds the preset threshold, adjust the size and type of the query request set, re-execute the mixed load test, and obtain calibrated resource consumption data and execution time data; Based on the calibrated resource consumption data, calculate the resource consumption weights for various query operations and determine the weight allocation table; By analyzing the execution time data, we can generate a time distribution model by analyzing the execution time distribution of query operations. A multi-dimensional workload model is constructed using a weighted allocation table and a time distribution model to determine the resource consumption weights and execution time distribution ranges of query operations.

4. The server hardware testing method according to claim 1, characterized in that, The process involves analyzing the distribution characteristics of query requests in the workload model using a dynamic load balancing algorithm. If query requests are concentrated in a specific time period, the load allocation strategy is adjusted to obtain a uniformly distributed test load sequence. The impact of load peaks on hardware resources is then assessed, including: The frequency and scale of query requests are obtained from time series data. The data is segmented using the sliding time window method, and the request distribution characteristics of each time period are statistically analyzed to obtain a distribution characteristic dataset. If the distribution feature dataset shows that the request frequency exceeds the preset threshold within a specific time period, the distribution ratio of query requests is adjusted through the consistent hashing algorithm to generate a balanced test load sequence. Based on the test load sequence, perform simulated load tests, collect CPU utilization and memory usage data of hardware resources, and obtain peak consumption datasets; By analyzing the peak consumption dataset, the load impact on hardware resources is analyzed, and a preset resource threshold is used for comparison to determine whether a resource bottleneck is triggered. If a resource bottleneck is triggered, the granularity of the time window segmentation is adjusted based on the peak consumption dataset, and the distribution feature dataset is regenerated. By using the regenerated distribution feature dataset, the allocation ratio of the consistent hashing algorithm is optimized to obtain the updated test load sequence; By using the updated test load sequence, a new round of load testing is performed to collect hardware resource consumption data and determine the final impact of the load peak on hardware resources.

5. A server hardware testing method according to claim 1, characterized in that, The process involves preprocessing memory access patterns using a caching optimization algorithm, establishing a cache hit rate prediction model based on the data access path of the query request, and reorganizing the data layout if the predicted hit rate is lower than a preset threshold. This yields an optimized memory access strategy and cache configuration scheme, including: Memory access path data is obtained from the query request, and the frequency characteristics of the access path are extracted using statistical analysis methods to obtain the path frequency dataset. Using the path frequency dataset, a cache hit rate prediction model based on logistic regression is constructed, and the predicted hit rate value is output. If the prediction hit rate is lower than the preset threshold, the data storage layout will be reorganized based on the path frequency dataset to generate an optimized storage layout scheme. By adopting the optimized storage layout scheme and updating the memory access paths, a new access path dataset is obtained. By adjusting cache configuration parameters using the new access path dataset, an optimized cache configuration scheme can be generated. Based on the optimized cache configuration scheme, perform memory access simulation tests, collect cache hit rate data, and determine the final cache hit rate; The applicability of the optimization scheme is verified by the final cache hit rate, and the optimized memory access strategy is obtained.

6. A server hardware testing method according to claim 1, characterized in that, The process involves obtaining the input / output operation response time of the storage device under different load conditions, sorting and grouping concurrent query requests using a query scheduling algorithm, and initiating a query queue reorganization mechanism if the storage device response time exceeds a preset limit to determine the optimal query execution order. This includes: The response time data of input / output operations of storage devices under different load conditions are obtained, and the distribution characteristics of the response time are extracted using statistical analysis methods to obtain the response time dataset. Using response time datasets, a query request priority prediction model based on decision trees is constructed, and the priority ranking results are output. Based on the priority sorting results, concurrent query requests are grouped and processed to generate a query request group dataset; If the response time of the query request group dataset exceeds a preset threshold, the queue reorganization algorithm is used to adjust the execution order of the query requests to obtain an optimized query execution order. By optimizing the query execution order, the query scheduling configuration of the storage device is updated, and a new scheduling configuration scheme is generated. A new scheduling configuration scheme was adopted to perform input / output operation simulation tests on storage devices, collect actual response time data, and determine the final query response time. Based on the final query response time, the allocation strategy for concurrent query requests is adjusted to obtain an optimized query allocation scheme.

7. A server hardware testing method according to claim 1, characterized in that, The process involves using performance monitoring tools to track the hardware collaboration status in real time based on processor cache usage and memory access latency data. If the processor cache hit rate decreases or memory access latency increases, a collaborative performance evaluation process is triggered to determine the collaboration efficiency between hardware components, including: The processor cache hit rate and memory access latency data are collected in real time using performance monitoring tools to generate a hardware performance status dataset. If the cache hit rate in the hardware performance status dataset is lower than the preset threshold or the memory access latency exceeds the preset threshold, the hardware performance status dataset is analyzed using the support vector machine algorithm to determine the hardware co-efficiency level. Based on the hardware co-efficiency level, the k-means clustering algorithm is used to group the performance bottlenecks of processor cache and memory access, resulting in a performance bottleneck group dataset. By grouping datasets based on performance bottlenecks, the processor cache allocation strategy is adjusted to generate an optimized cache allocation configuration; The optimized cache allocation configuration is used to update the memory access scheduling parameters and generate a new memory access scheduling scheme. By using a new memory access scheduling scheme, hardware co-operation performance simulation tests are performed, and adjusted performance status data is collected to obtain an optimized hardware co-operation efficiency dataset. Based on the optimized hardware collaboration efficiency dataset, a decision tree algorithm is used to predict the performance trend of hardware collaboration and generate performance optimization and adjustment strategies.

8. A server hardware testing method according to claim 1, characterized in that, The method involves comprehensively analyzing the collaborative test results of storage devices, memory access, and processor performance to establish a multi-dimensional performance evaluation matrix. This yields the actual performance of the hardware and potential bottleneck locations in complex information retrieval scenarios, resulting in a complete server hardware collaborative performance evaluation report, including: The performance monitoring tool continuously collects data on storage device access speed, memory access latency, and processor computing performance from the hardware co-performance bottleneck dataset to generate a real-time performance status dataset. Using a real-time performance status dataset, the random forest algorithm is employed to analyze the collaborative efficiency among storage devices, memory, and processors, and to determine the hardware collaborative performance level. If the hardware collaboration performance level is lower than the preset threshold, the performance bottlenecks in the real-time performance status dataset are grouped by cluster analysis to obtain a performance bottleneck classification dataset. Based on the performance bottleneck classification dataset, adjust the access priority parameters of the storage devices to generate an optimized storage access configuration. By optimizing the storage access configuration, the memory access scheduling policy is updated, and a new memory access scheduling scheme is generated. A new memory access scheduling scheme was adopted to perform performance simulation tests on complex information retrieval scenarios, and the adjusted performance data was collected to obtain an optimized hardware co-performance dataset. Based on the optimized hardware co-performance dataset, the performance change trend is analyzed, and a dynamic adjustment strategy for performance optimization is generated.

9. A server hardware testing terminal, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor as described in the claims, characterized in that, When the processor executes the computer program, it implements the steps of the server hardware testing method as described in any one of claims 1 to 8.

Images