Server test method, electronic equipment, storage medium and program product

Abstract

The invention relates to a server testing method, electronic equipment, a storage medium and a program product, which are applied to the technical field of computer testing, and the method comprises the following steps: in the process of executing a pressure test on a tested server in a composite testing scene, based on the standard exceeding condition of the performance index of the tested server, according to a degradation strategy matched with the standard exceeding condition, determining the performance index of the tested server according to the degradation strategy matched with the standard exceeding condition; the access traffic injected into the tested server is adjusted, and the degradation strategy is used for performing overload protection on the tested server; converting the acquired running state data of the tested server into multi-dimensional feature data according to a plurality of performance dimensions; determining weights of different performance dimensions based on a test mode of a pressure test; and determining a test result of the tested server according to the weight and the multi-dimensional feature data.

Description

Technical Field

[0001] The present application relates to the field of computer testing technology, and in particular to a server testing method, electronic equipment, storage medium, and program product. Background Art

[0002] As a core component of network architecture, server stability directly impacts business continuity and user experience. Current server stability testing technologies primarily assess performance through load simulation and resource monitoring. However, these technologies still suffer from insufficient automation, inadequate load adjustment mechanisms, single performance indicators, and rigid evaluation methods, making them difficult to adapt to diverse business scenarios. Summary of the Invention

[0003] The first aspect of an embodiment of the present application provides a server testing method, which includes: in the process of performing a stress test on a server under test in a composite test scenario, based on the exceeding of performance indicators of the server under test, adjusting the access traffic injected into the server under test according to a degradation strategy that matches the exceeding situation, the degradation strategy is used to perform overload protection on the server under test; according to multiple performance dimensions, converting the collected operating status data of the server under test into multidimensional feature data; determining the weights of different performance dimensions based on the test mode of the stress test; and determining the test results of the server under test according to the weights and the multidimensional feature data.

[0004] The second aspect of the present application provides an electronic device comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of any method according to the first aspect.

[0005] A third aspect of the present application provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of any one of the methods in the first aspect when the computer program or instructions are executed by a processor.

[0006] A fourth aspect of the present application provides a computer program product, comprising a computer program or instructions, which implements the steps of any one of the methods according to the first aspect when the computer program or instructions are executed by a processor.

[0007] The server testing method provided in the embodiment of the present application simulates a complex testing environment. When conducting tests in this environment, it can automatically adjust the access traffic according to the load capacity of the server under test to ensure efficient and stable testing. By adjusting the weights of data of different dimensions in combination with the test mode and then evaluating them, it can adapt to the differentiated evaluation needs of different business scenarios and break through the limitations of existing technologies that rely on single indicators or fixed weights. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The above contents and other objects, features and advantages of the present application will become more apparent through the following description of the embodiments of the present application with reference to the accompanying drawings, in which:

[0009] Figure 1 The following schematically shows a hardware environment diagram of a server testing method according to an embodiment of the present application;

[0010] Figure 2 The following schematically shows a flow chart of a server testing method according to an embodiment of the present application;

[0011] Figure 3 A schematic diagram of adjusting access traffic according to an embodiment of the present application is shown schematically;

[0012] Figure 4 Schematically shows a schematic diagram of generating multi-dimensional feature data according to an embodiment of the present application;

[0013] Figure 5 The following schematically illustrates a method for determining the weights of various performance dimensions according to an embodiment of the present application;

[0014] Figure 6 A schematic diagram of evaluating server performance according to an embodiment of the present application is schematically shown;

[0015] Figure 7 A schematic block diagram of an electronic device according to an embodiment of the present application is schematically shown. DETAILED DESCRIPTION

[0016] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0017] It should be noted that the terms "first", "second", etc. in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0018] The method embodiments provided in the embodiments of the present application can be executed in a server, a mobile terminal, a computer terminal or a similar computing device. Taking running on a server as an example, Figure 1 The following schematically shows a hardware environment diagram of a server testing method according to an embodiment of the present application.

[0019] like Figure 1 As shown, the server may include one or more ( Figure 1 Only one is shown) a processor 102 (the processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. The server may also include a transmission device 106 and an input / output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above server. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0020] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the server testing method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0021] Transmission device 106 is used to receive or transmit data via a network. A specific example of such a network may include a wireless network provided by a computer terminal's communications provider. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0022] The server testing method in this embodiment may be executed by a server. Here, the server refers to the entire server, including the relevant components and processor within the server that need to execute the server testing method. The server testing method in this embodiment may also be executed by the processor 102. In some examples of this embodiment, the server testing method is described as being executed by a server.

[0023] The server testing method of this embodiment can be applied to the scenario of server stress testing. When testing in this environment, the access flow can be automatically adjusted according to the load capacity of the tested server to ensure that the test is carried out efficiently and stably.

[0024] In some examples, the current server stability testing is not sufficiently automated, the load adjustment mechanism is not sophisticated enough, the performance indicators used in performance evaluation are single, the evaluation methods are rigid, and it is difficult to adapt to the needs of different testing scenarios.

[0025] To solve the above problems, an embodiment of the present application provides a server testing method.

[0026] Figure 2 The flowchart of the server testing method according to an embodiment of the present application is schematically shown.

[0027] like Figure 2 As shown, a server testing method provided in an embodiment of the present application can be applied to a server stress testing scenario, including operations S210 to S240.

[0028] In operation S210 , during the stress test of the server under test in the composite test scenario, based on the exceeding of performance indicators of the server under test, the access traffic injected into the server under test is adjusted according to a degradation strategy matching the exceeding of performance indicators.

[0029] The server test scenarios include high concurrent access, network transmission fluctuations, hardware resource failures and other scenarios. In actual applications, a single test scenario is often difficult to fully expose potential problems of the server system. For example, only testing high concurrent access may verify the throughput and response speed of the system, but ignore the impact of network fluctuations on stability. If the network delay or packet loss rate suddenly increases in the actual environment, the system that has not undergone relevant testing may experience problems such as connection timeouts and data inconsistency. Similarly, only simulating hardware failures (such as disk damage) may verify the fault tolerance mechanism, but it does not cover the performance bottlenecks caused by hardware resource contention under high concurrency. Therefore, single-scenario testing is prone to "false reliability" and it is necessary to simulate a real and complex environment through multi-scenario combination testing.

[0030] In the embodiments of the present application, a composite test scenario is constructed by combining problem patterns of multiple test scenarios, and a stress test is performed on the server under test in this composite test scenario. The stress test mode includes a combination of one or more of a baseline load test mode, a peak impact test mode, a continuous high voltage test mode, and a fault injection test mode.

[0031] Server stress testing requires that the testing process simulate real-world business scenarios, help identify server performance bottlenecks, verify the server's elastic scalability, and avoid excessive consumption of testing resources. Therefore, dynamic access traffic adjustment is necessary to meet the server's stability and reliability requirements in high-load, fluctuating test environments.

[0032] In the embodiments of this application, dynamic access traffic regulation is implemented through a degradation strategy, enabling overload protection for the server under test. Based on whether the server's performance indicators exceed the standards, a degradation strategy matching the exceeding standards is used to adjust the access traffic injected into the server under test. This automatically limits the flow when server performance exceeds the standards, preventing system crashes. This not only protects the stability of critical services, but also accurately isolates faulty modules and improves resource utilization.

[0033] In operation S220 , the collected operating status data of the tested server is converted into multi-dimensional feature data according to multiple performance dimensions.

[0034] The performance dimensions of a server can be divided into at least three dimensions: system performance, stability, and recoverability. A feature matrix is ​​established based on the three core dimensions of system performance (such as CPU utilization and memory throughput), stability (such as mean time between failures and frequency of abnormal restarts), and recoverability (such as failover time and data backup integrity). Multiple quantifiable secondary indicators can also be set under each dimension. Specifically, system performance includes processing capacity (such as the number of queries per second, the number of transactions per second, the number of concurrent connections and throughput, etc.), response efficiency (such as average / maximum response time, latency, etc.) and resource utilization (such as CPU, memory, disk I / O, network bandwidth occupancy), etc.; stability can be reflected through error rate, timeout rate, and service availability; recoverability can be reflected through data such as fault recovery time, service interruption duration, automatic recovery success rate, data recovery integrity, and retry / circuit breaker trigger efficiency.

[0035] In the embodiments of this application, during the test process, relevant server operating status data is collected and classified according to performance dimensions before extracting features, resulting in feature data in three dimensions. Based on this multi-dimensional feature data, subsequent evaluation of server performance can be conducted from multiple dimensions, and the evaluation results from these dimensions can be combined for an overall evaluation, making the evaluation results more objective and comprehensive.

[0036] In operation S230 , weights of different performance dimensions are determined based on a test mode of the stress test.

[0037] Stress testing generally includes benchmark load testing mode, peak impact testing mode, and continuous high-voltage testing mode. Benchmark testing simulates daily operating conditions and adopts a balanced weight distribution strategy, focusing on basic indicators such as CPU, memory, disk I / O, and network throughput. Response time and success rate are given higher weights to ensure user experience. The performance baseline established by this mode provides an important reference for subsequent tests. Peak testing targets sudden high-concurrency scenarios and significantly increases the weights of dimensions such as concurrent processing capabilities and network bandwidth. This mode also verifies the effectiveness of service degradation and circuit breaker mechanisms to ensure that core businesses are not affected. Continuous high-voltage testing focuses on evaluating system stability and increases the weights of long-term indicators such as memory leaks and thread blocking. By analyzing trend data such as the slope of memory usage growth, resource exhaustion risks can be quickly discovered.

[0038] Determining the weights of different performance dimensions based on the test model allows for more accurate simulation of real-world load characteristics and focuses on key performance bottlenecks. Different business scenarios place varying demands on servers. For example, high-concurrency systems prioritize throughput, while real-time systems prioritize low latency. Dynamically adjusting weights ensures that test results align with business objectives and avoids wasting resources on non-core metrics. This differentiated weighting helps expose the system's most vulnerable areas, enabling targeted optimization and improving testing efficiency and system reliability.

[0039] In operation S240 , a test result of the tested server is determined based on the weight and the multi-dimensional feature data.

[0040] In the embodiments of the present application, weights and multi-dimensional feature data are used to evaluate the performance of the server in terms of system performance, stability, recoverability and other performance dimensions, and a comprehensive evaluation of the server is performed based on the performance. The evaluation form can be scoring, grading, etc. Combining performance data and evaluation results, testers can make a comprehensive judgment on the performance of the server, accurately locate hardware bottlenecks, network defects or software vulnerabilities, guide targeted system optimization, and improve operation and maintenance efficiency. The test results can provide data support for server selection and capacity planning, realizing the leap from single-point detection to full life cycle management.

[0041] For example, the system calculates scores based on the product of weights and multidimensional feature data, employing a fuzzy comprehensive evaluation algorithm to compare standardized indicator data with preset thresholds, ultimately generating a 100-point score and a five-level AE rating. Testers can intuitively view radar charts and shortcoming analysis for each dimension through a visual dashboard. The system also automatically flags abnormal indicators that deviate from normal ranges, significantly improving problem location efficiency.

[0042] In the embodiment of the present application, a comprehensive quantitative evaluation of server performance is achieved by constructing a multi-dimensional server performance evaluation system. The system first establishes multiple evaluation dimensions including system performance, stability, and recoverability, and each dimension has several quantifiable secondary indicators. The system performance dimension covers hardware indicators such as computing power, memory bandwidth, and storage; the stability dimension focuses on reliability indicators such as mean time between failures and abnormal restart frequency; and the recoverability dimension evaluates disaster recovery capability indicators such as fault switching time and data backup integrity. A dynamic weight allocation mechanism is used in the evaluation process to adjust the weight ratio of each dimension according to different application scenarios. For example, for financial trading systems, the weights of stability and recoverability will be appropriately increased; while for big data analysis platforms, more emphasis is placed on the evaluation of system performance dimensions.

[0043] The server testing method provided in this application simulates a complex testing environment. When testing in this environment, it can automatically adjust the access traffic according to the load capacity of the server under test to adapt to the testing needs of different business scenarios. This method combines the test mode to adjust the weights of data in different dimensions and then evaluates them, breaking through the limitations of existing technologies that rely on single indicators or fixed weights, and improving the rationality of the evaluation results. Through cross-analysis of multi-dimensional feature data, the specific location of the performance bottleneck can be accurately identified, such as distinguishing whether it is insufficient CPU computing power or limited memory bandwidth; secondly, the test results can directly guide system optimization. For example, when the recoverability score is low, it indicates the need to strengthen the backup strategy or optimize the failover mechanism; finally, the evaluation data accumulated over a long period of time can provide a decision-making basis for server procurement and expansion, realizing the transition from single performance testing to full life cycle management. This server testing method can provide a strong guarantee for the stable operation of the business system.

[0044] The server testing method provided in this application will be described in detail below in conjunction with specific embodiments.

[0045] In an embodiment of the present application, an environmental parameter configuration matrix, a hardware fault simulation unit, a traffic pattern generator, a protocol compatibility test framework and a time series analysis engine are constructed, and a composite test scenario is constructed based on the environmental parameter configuration matrix, the hardware fault simulation unit, the traffic pattern generator, the protocol compatibility test framework and the time series analysis engine.

[0046] The environmental parameter configuration matrix includes concurrent connection ranges, network latency ranges, and packet loss rate thresholds. The concurrent connection ranges use a logarithmic scale to divide the test gradients. The network latency range includes both fixed delay and random jitter components. Logarithmic gradient division and random jitter simulation are used to replicate real-world network uncertainties. The hardware fault simulation unit includes a CPU frequency dynamic throttling module, a memory address space fault injector, and a disk bad sector simulation algorithm. The memory address space fault injector simulates faults based on address bit flip probabilities, while the disk bad sector simulation algorithm utilizes address mapping redirection technology. The traffic pattern generator can generate three basic load patterns: sinusoidal wave load curves, square wave shock loads, and random noise loads. It also features the ability to combine and superimpose patterns. The protocol compatibility testing framework supports multi-protocol testing for HTTP / HTTPS / WebSocket / TCP / UDP and includes a protocol signature fingerprinting module. The integrated time series analysis engine monitors system resource usage trends in real time and predicts critical failure points.

[0047] By constructing complex test scenarios, we can simulate complex environments such as high concurrent access, network transmission fluctuations, and hardware resource failures, effectively verifying server stability under extreme conditions. Integrated automated stress testing processes and dynamic adjustment mechanisms ensure accurate and efficient testing. These complex test scenarios can include benchmark load testing modes, peak impact testing modes, sustained high-voltage testing modes, and fault injection testing modes, comprehensively covering the extreme scenarios that servers may face to verify system robustness. This complex test scenario allows for granular parameter configuration. For example, the environmental parameter matrix covers concurrent connections (1,000-100,000), network latency (10ms-500ms), and packet loss rate (0.1%-5%). Logarithmic gradients and random jitter simulation are used to replicate the uncertainties of real networks. The hardware fault simulation unit supports low-level fault injection, such as dynamic CPU frequency reduction, memory address bit flips, and disk bad sector mapping, overcoming the limitations of existing hardware status monitoring technologies.

[0048] In an embodiment of the present application, the access traffic of the server under test is generated and regulated by a distributed load generator. The multi-node collaborative work architecture of the distributed load generator includes three types of core nodes, and the functions of each node are clearly divided into different parts according to the network simulation capabilities. The control node is responsible for unified scheduling of test tasks, aggregation of all results, and monitoring of node status. Although it does not directly participate in traffic generation, it achieves global test strategy synchronization by coordinating the network parameter configuration of each node (such as delay and packet loss rate); the load generation node serves as the core of traffic generation and simulates high-concurrency user behavior. Each node has an independent network parameter simulator built in, and heterogeneous network environments can be configured separately; the proxy node acts as a traffic transfer in complex topologies, simulating intermediate devices such as NAT and firewalls, and supports two-way network rule injection (such as modifying the TCP retransmission rate and limiting the MTU value) to enhance the authenticity of the network environment simulation. The three types of nodes work together to form a distributed pressure source, which can accurately reproduce high-concurrency scenarios under different network characteristics.

[0049] The server testing method provided in the embodiment of the present application is implemented based on the above-mentioned composite testing scenario.

[0050] The basic process of automated stress testing includes: first, clarifying the test objectives and designing multi-dimensional scenarios including benchmark load, peak impact, and durability testing; then, establishing an isolated test environment and deploying monitoring tools and load generators; then, executing phased testing, first preheating the system, then applying load according to preset strategies (such as step boost / pulse impact), and collecting response time, throughput, and resource indicators in real time; finally, generating an analysis report that includes performance inflection points, error rates, and resource trends to provide data support for optimization.

[0051] In the embodiment of the present application, the automated stress testing process first initializes the test parameters and sets the benchmark test (including the warm-up and data collection phases). The stress ramp rate is ≤100 TPS / s to ensure that valid data is obtained after the system is stable. Multi-dimensional test scenarios are achieved through parameter matrix mapping. For example, the benchmark load mode adopts a stepped load, with each stage lasting 1 / 4 of the total time and including a 60-second gradual rise, monitoring response time and resource utilization; the peak impact mode configures instantaneous pulse parameters, step surge parameters, and periodic impact parameters; the continuous high-pressure mode sets a 12-hour load maintenance of 80% of the theoretical capacity and sets the interval time for collecting full-link data. The network / hardware dimension integrates the number of concurrent connections, network latency, and fault injection strategies (such as triggering memory failures during the high-pressure phase). The stress ramp rate is dynamically calculated based on the benchmark performance, and the concurrency is adjusted in real time through the sliding window algorithm of the exponentially weighted moving average model. Combined with super-linear growth and sub-linear decay gradients, it accurately simulates real business traffic fluctuations.

[0052] Figure 3 The diagram schematically shows a method for adjusting access traffic according to an embodiment of the present application.

[0053] like Figure 3 As shown, after starting the stress test on the server under test, the operating status data of the server under test is collected, the performance indicators of the server under test are detected according to the operating status data, and based on the performance indicators, it is determined whether the access traffic needs to be dynamically adjusted during the test.

[0054] Operational status data includes response delay time, CPU usage, memory usage, disk I / O throughput, network packet loss rate, etc. Performance indicators obtained based on the operational status data include at least one of response time stability coefficient, resource usage balance, memory leak trend detection, disk I / O stability analysis, and network reliability.

[0055] In order to enrich the sources of test evaluation basis, multi-dimensional operating status data is obtained. The method for obtaining operating status data includes at least one of the following: based on the system-level monitoring probe deployed on the kernel module and user-mode agent program of the server under test, the system kernel status data is collected; based on the hardware sensor interface of the server under test, the hardware health status data is collected, such as reading the CPU temperature, fan speed and voltage fluctuation data; based on the network sniffer deployed on the server under test, the network transmission performance data, such as TCP retransmission rate and ICMP error message statistics, is collected; based on the performance monitoring unit of the processor in the server under test, the system scheduling efficiency data, such as context switching frequency and number of page fault interrupts, is collected.

[0056] In an embodiment of the present application, a sliding window is used to calculate the ratio of the 99th percentile to the median, and a dynamically adjusted abnormality threshold is set to calculate the response time stability coefficient; the resource utilization balance is evaluated by calculating the ratio of the standard deviation of the multi-core CPU load to the average value, and the calculation includes the load migration statistics between CPU cores; a linear regression model using a piecewise linear fitting method is established to analyze the memory usage growth rate to detect memory leakage trends; the density of abnormal events in which the read and write delays exceed the threshold considering the request size distribution characteristics is statistically analyzed to analyze the disk IO stability; the network reliability is evaluated by calculating the continuous deviation between the effective throughput and the theoretical bandwidth including the retransmission message ratio factor.

[0057] By deploying kernel monitoring probes and hardware sensor interfaces, we collect low-level hardware status and network protocol details, such as CPU temperature, memory address faults, and TCP retransmission rates. This addresses the limited monitoring dimensions of existing technologies and provides multi-dimensional correlation support for stability analysis. A network sniffer using zero-copy ring buffer technology and a nanosecond-level time series database enables efficient data collection and storage, supporting real-time analysis and rapid retrieval of massive amounts of monitoring data, and improving data processing efficiency.

[0058] When it is detected that at least one performance indicator of the tested server exceeds a threshold, a degradation strategy is determined according to the type of the at least one performance indicator and the magnitude of the value exceeding the threshold.

[0059] For example, when the CPU utilization rate is greater than 90% and lasts for 10 seconds, request throttling is automatically triggered and elastic expansion is started. For another example, when the average API latency is greater than 500ms, the circuit breaker mechanism is enabled and cached data or a static degradation page is returned. Based on the degradation strategy, the access traffic of non-core services of the tested server is reduced. The degradation strategy indicates the method and rate of reduction of access traffic. The multi-level degradation strategy is layered according to load pressure. The core is to reduce losses while ensuring core services. Through dynamic policy matching, the impact of degradation on user experience can be minimized, system crashes can be prevented, and rapid self-healing of faults can be achieved.

[0060] This approach significantly improves server stability under high load or abnormal conditions through an intelligent non-core service traffic degradation mechanism. A whitelist mechanism, triggered by dynamic performance thresholds, accurately identifies non-core services requiring degradation and automatically applies differentiated degradation strategies based on the degree of metric overload and deterioration trends. For sudden loads, it applies progressive traffic restrictions, while for sustained overloads, it rapidly switches to alternative paths or triggers circuit breakers. This approach avoids the undue impact of "one-size-fits-all" degradation on services while ensuring that core services always have the necessary resources.

[0061] In an embodiment of the present application, based on the non-core service whitelist in the degradation policy, the non-core services in the tested server that need to reduce access traffic are determined, and the non-core service whitelist is determined based on the type of at least one performance indicator and the value exceeding the threshold. The access traffic of the non-core service is reduced based on the reduction method and reduction rate indicated by the degradation policy, and the reduction method includes at least one of reducing the access traffic in the existing access path, switching the access path of the access traffic, and initiating a fuse mechanism in the access path. The reduction rate is determined based on the value of at least one performance indicator exceeding the threshold and the rate of increase.

[0062] For example, a first-level strategy is used to handle mild stress. For example, if the CPU exceeds 80%, non-core functions such as logging and monitoring will be disabled, and request paths will be optimized (e.g., switching caches). A second-level strategy is used to handle moderate stress. For example, if the CPU exceeds 85%, non-essential services such as recommendations and advertising will be shut down, and backup links (e.g., distributed caches) will be switched. A third-level strategy is used to handle critical conditions. For example, if the CPU exceeds 90%, only core functions such as payment and ordering will be retained, and circuit breakers will be initiated (e.g., rejecting non-core requests). Based on the non-core service whitelist in the degradation strategy, the non-core services on the tested server that require reduced access traffic are identified. The non-core service whitelist is determined based on the type of at least one performance indicator and the value that exceeds the threshold.

[0063] In an embodiment of the present application, an access traffic feedback control loop can be established to accurately control the access traffic. In the process of reducing the access traffic, the error of the access traffic reduction rate relative to the expected reduction rate is determined; based on the error, the access traffic reduction rate is adjusted to reduce the error. A feedback control loop is established to collect system load indicators as control variables, and a two-level delay compensation mechanism is set up to eliminate the impact of measurement lag on control accuracy. This feedback control loop is a closed-loop mechanism of "real-time monitoring-intelligent analysis-automatic adjustment-effect verification". It monitors performance indicators (such as response time, error rate) and resource status (such as CPU / memory) in real time, analyzes the cause of the error through a preset dynamic analysis model, automatically adjusts load parameters (such as concurrency) or system configuration (such as thread pool size), and then verifies the optimization effect through the next round of testing, forming a continuous iterative stability assurance mechanism.

[0064] A fuzzy PID controller is designed, using a self-tuning algorithm to adjust the request generation rate, and an overload protection mechanism is configured. When the system approaches a critical state, a multi-level degradation strategy is triggered to achieve precise load control. The controller output of the access flow is expressed as:

[0065]

[0066] Where, is the controller output, corresponding to the adjustment of the request generation rate, is the proportional gain coefficient, which determines the response strength of the system to the current error. is the integral gain coefficient, which eliminates the cumulative effect of steady-state error, is the differential gain coefficient, which damps the trend of the forecast error change. is the error function, which is the difference between the expected load and the actual load, is the time variable, is the integral term of the error, accumulating historical errors, It is the differential term of the error, reflecting the rate of change of the error.

[0067] Core load metrics such as concurrency, requests, data, and resource load can serve as key variables for feedback control. Concurrency metrics include the number of concurrent users, active connections (TCP / UDP), and thread / process occupancy; request metrics include transactions per second (TPS), API call frequency, and request size distribution; data metrics include cache hit rate, database read / write volume, and queue backlog length; and resource load metrics include CPU utilization, memory utilization, disk IOPS / throughput, and network bandwidth utilization.

[0068] The server testing method provided in the embodiments of this application simulates a real network environment and tests the server, obtaining operational status data reflecting the performance and issues of the tested server. This operational status data can be used as a basis for performance bottleneck analysis, capacity planning, fault prediction and prevention, and service quality assessment.

[0069] In the embodiment of the present application, in order to achieve an all-round and multi-dimensional evaluation of the server under test, the acquired operating status data is subjected to dimensional conversion.

[0070] Figure 4 The diagram schematically shows a method for generating multi-dimensional feature data according to an embodiment of the present application.

[0071] like Figure 4 As shown, in an embodiment of the present application, the collected operating status data is divided into system performance indicators, stability indicators and recoverability indicators according to the performance dimension, and the feature data of the system performance indicators, stability indicators and recoverability indicators are extracted respectively to obtain multi-dimensional feature data.

[0072] It should be noted that the system performance indicators, stability indicators, and recoverability indicators can be data indicators such as request success rate, timeout request ratio, error response type distribution, etc., and according to actual needs, the system performance indicators, stability indicators, and recoverability indicators can be further subdivided into various types of indicators. In the embodiments of this application, the system performance indicators, stability indicators, and recoverability indicators are used for schematic illustration, but are not limited to these three dimensions.

[0073] After classifying the data by performance dimension, the min-max normalization method is adopted and the original data distribution characteristics are retained to ensure the comparability of indicators of different dimensions; the correlation coefficient matrix between data of different performance dimensions is calculated to eliminate the influence of multicollinearity and improve the rationality of weight distribution.

[0074] Key methods for extracting characteristic data for system performance, stability, and recoverability indicators include K-means clustering, PCA dimensionality reduction, call chain tracing, error pattern mining, and log template matching. Multiple methods can also be combined to comprehensively characterize system features. Based on this multidimensional characteristic data, system performance can be comprehensively evaluated from multiple perspectives, addressing the limited monitoring dimensions of existing technologies and providing multi-dimensional correlation support for stability analysis.

[0075] By assigning different weights to data from different performance dimensions in combination with the test mode, we can more objectively evaluate the performance of the server under that test mode.

[0076] Figure 5 The figure schematically shows a diagram for determining the weights of various performance dimensions according to an embodiment of the present application.

[0077] like Figure 5 As shown, in an embodiment of the present application, the weight of the performance dimension is determined based on the performance index of different performance dimensions of the tested server in the test mode, and the performance index represents the degree of influence of the performance dimension on the test result in the test mode.

[0078] By quantifying the performance index of the tested server under different stress scenarios, we establish an adaptive relationship between performance dimensions and business scenarios. The performance index is a quantitative value calculated using standardized test data, reflecting the intensity of the dimension's impact on the overall system performance. For example, in a high-concurrency test mode, if the server's performance index in the throughput dimension reaches 0.92 (out of a maximum score of 1.0), but the performance index in the memory leak dimension is only 0.65, this indicates that throughput has a more significant impact on the results of this test mode, and therefore a higher proportion should be assigned when allocating weights (e.g., a 40% weight for throughput and a 15% weight for memory leaks). This dynamic weighting mechanism ensures a strong correlation between test results and real-world business scenarios, and can also expose the system's weakest links in specific scenarios. For example, if a server's computing performance index in a CPU-intensive test is only 0.5, it directly indicates that algorithm optimization or hardware upgrades are needed.

[0079] By quantifying the performance index of the tested server under different stress scenarios and dynamically adjusting the weights of performance dimensions, a more accurate server performance evaluation can be achieved, making the evaluation system scenario-adaptive. This method can automatically adjust the weight of each dimension based on the actual business load characteristics, ensuring that the evaluation results are highly consistent with real business needs. The introduction of the performance index allows the evaluation process to not only reflect the absolute performance of the server, but also reveal the key bottleneck dimensions in different business scenarios. For example, in high-frequency trading scenarios, the weight of network latency is greatly increased, while storage throughput becomes the dominant factor in batch data processing. This dynamic weighting mechanism effectively avoids the misjudgment that may result from traditional static weighting evaluations, enabling the operation and maintenance team to accurately optimize for specific business needs, improving the scientific nature of resource scheduling and the targeted nature of system tuning.

[0080] In an embodiment of the present application, the performance index includes weight indices of different performance dimensions and performance indices of different performance dimensions under the test mode. Specifically, the weight indices of different performance dimensions are determined based on the test mode; the performance index of each performance dimension is determined based on the correlation index between the data of different performance dimensions in the multidimensional feature data. The correlation index reflects the degree of mutual influence between different dimensions. Based on these correlation indices, the system will use a weighted average algorithm to calculate the performance index of the response time dimension, in which data with strongly correlated dimensions will be given a higher weight. Specifically, the performance index of data of different performance dimensions can be analyzed based on the hierarchical analysis method. The product of the weight index and the performance index of each performance dimension is calculated to obtain the weight of the performance dimension.

[0081] Taking web server testing as an example, assume that response time has a strong correlation with CPU utilization (correlation index 0.85), a moderate correlation with memory usage (correlation index 0.6), and a weak correlation with disk I / O (correlation index 0.3). In a stress test, suppose the actual performance score for CPU utilization is 0.8, memory usage is 0.7, and disk I / O is 0.9. The performance index for response time is calculated as: (0.85 × 0.8 + 0.6 × 0.7 + 0.3 × 0.9) / (0.85 + 0.6 + 0.3) = 0.77. If the response time weight index is 0.4, its final weight is 0.4 × 0.77 = 0.308.

[0082] The calculation method based on the correlation index can more accurately reflect the actual performance of each performance dimension and can achieve more accurate and intelligent server performance evaluation. By adaptively adjusting the weight index through the test mode, it can ensure that the evaluation standard fits the actual business scenario needs; at the same time, the correlation index is used to analyze the mutual influence between performance dimensions, and the hierarchical analysis method is used to scientifically quantify the contribution of each dimension, so that the performance index calculation is more in line with the actual system operation characteristics. Finally, through the fusion calculation of the weight index and the performance index, it not only takes into account the priority differences of business scenarios, but also reflects the synergy or constraint relationship between performance dimensions. This dual dynamic adjustment mechanism greatly improves the accuracy and operability of the evaluation results. It can not only identify obvious performance shortcomings, but also discover potential cross-dimensional bottlenecks, providing a more comprehensive and reliable decision-making basis for performance optimization, and significantly improving operation and maintenance efficiency.

[0083] Figure 6 The figure schematically shows a schematic diagram of evaluating server performance according to an embodiment of the present application.

[0084] like Figure 6 As shown, server performance is evaluated based on multi-dimensional feature data. Different weights are assigned to each performance dimension in combination with the test mode to provide an accurate profile and comprehensive assessment of server performance. After obtaining a comprehensive server score, the test results need to be converted into actionable conclusions and optimization recommendations.

[0085] For example, during a stress test of a financial trading system, the system calculated a comprehensive server performance score based on multi-dimensional feature data and dynamic weighting. The test collected core metrics such as transaction latency, concurrent processing volume, and error rate. These metrics were categorized by performance dimension, feature data extracted for each, and weighted accordingly based on the "low latency, high reliability" test model. The weighted calculation yielded an overall performance score of 82. While transaction latency met the target but approached the threshold, it was marked as an observation. The error rate also performed well. The test report also revealed that when concurrency exceeded 1000 TPS, the error rate rose sharply to 1.5%. This inflection point analysis provided critical support for setting throttling limits in the production environment. Ultimately, the maximum concurrency threshold for the production environment was set at 950 TPS to provide a safety margin.

[0086] The complete steps of the server measurement method provided by this application are described below through an embodiment.

[0087] Taking the e-commerce order processing server as an example, during stress testing in an e-commerce promotion scenario, a composite stress test was performed on the order processing server. If CPU utilization exceeded 90% for three minutes, a pre-set three-level downgrade strategy was triggered: first, request traffic to non-core services (such as product recommendations and user profile analysis) was reduced by 50%, while retaining core processes such as order creation and payment. Simultaneously, 20% of compute nodes were automatically scaled out. This strategy dynamically adjusted routing weights through the service mesh, ensuring that the CPU load was reduced to a safe threshold (below 75%) within five minutes while protecting core services. The entire process was monitored in real time to ensure precise execution of downgrade operations. Multi-dimensional operational data collected during the test was converted into standardized metrics through feature engineering: CPU utilization (0.92), memory usage (0.85), order processing latency (1.2 seconds / request), and error rate (0.5%). Based on the "high concurrency" test mode, the system automatically assigned performance weights to the following performance dimensions: processing latency (40%), error rate (30%), resource utilization (20%), and throughput (10%). A weighted calculation yielded an overall performance score of 86 out of 100, with latency being flagged as a critical improvement due to significant overshoot. Based on this comprehensive performance score, a final test report was generated, demonstrating that the system maintained core functionality under peak traffic conditions, but exhibited latency sensitivity. This case study demonstrates how dynamic degradation and multi-dimensional evaluation can achieve precise performance optimization, providing reliable support for real-world promotional events.

[0088] In some embodiments of the present application, in order to improve the scenario adaptability of the evaluation results, a stability level scoring system can also be established, defining five stability level intervals and setting overlapping buffer areas to avoid score jumps caused by sudden changes in boundary values. The five stability level intervals and their uses are as follows: <40 points, indicating frequent core function failures, used to force the termination of the test and prioritize the repair of fatal defects; 40-59 points, the function is available but has obvious shortcomings (such as large response fluctuations under continuous high pressure), used to locate optimization points; 60-79 points, meeting basic requirements, no critical failures, serving as the threshold for entering the next test phase; 80-89 points, stable performance in all scenarios, can be used as a benchmark for similar system optimization; 90-100 points, withstanding extreme pressure without abnormalities, serving as the acceptance standard for core business systems. This stability level interval can quantitatively evaluate system stability, support test advancement, optimization priority division and acceptance decision-making.

[0089] In this embodiment, load-response surface plots, resource usage heat maps, and multi-scenario comparison radar charts are generated, supporting interactive data drilling to intuitively display the performance characteristics and weaknesses of the tested server. Association rule mining technology is used to uncover correlations between operational status data and issues, generating optimization recommendation reports that accurately locate hardware bottlenecks, network defects, or software vulnerabilities, guiding targeted system optimization and improving operational efficiency.

[0090] On the basis of the above embodiments, in order to simulate the real working environment of the server, random faults can also be injected at irregular intervals during the test process to test the server's self-healing ability to cope with faults. During the stress test, simulated fault data is randomly injected into the composite test scenario; the operating status of the self-healing mechanism of the tested server is obtained. The effectiveness of the server's self-healing mechanism can be verified, and the test process can be traced back and root cause analysis can be performed based on the records. Simulated fault data can be obtained based on the parameter settings of the fault injection mode, or it can be obtained based on the hardware fault simulation unit. While injecting fault data, a process record file is generated to save the complete request-response timestamp and resource monitoring data for subsequent analysis.

[0091] The fault injection testing model constructs a three-dimensional fault matrix covering the infrastructure layer (CPU / memory / disk), the middleware layer (database / cache), and the network layer. Adopting a "single point first, then combined" injection principle, it encompasses both transient and persistent faults. The fault injection testing model verifies the system's fault tolerance, focusing on fault detection sensitivity, circuit breaker accuracy, traffic scheduling correctness, and data consistency.

[0092] The fault injection test mode of the test scenario module includes at least one of the following: designing a CPU overload fault scenario, dynamically adjusting the CPU usage to a continuous range of 90%-100%, and the scenario includes core binding and frequency limit parameters; simulating memory exhaustion failures, allocating anonymous memory at a specified rate until the OOM mechanism is triggered; constructing a disk space exhaustion scenario, writing filler files in real time until the remaining space is <1%, and setting automatic cleanup trigger conditions; creating a network isolation fault, randomly disconnecting a specified percentage of network connections, and the fault includes two modes: TCP connection reset and physical link disconnection; configuring a service process abnormal termination scenario, randomly terminating key processes according to Poisson distribution, and recording the process status recovery time.

[0093] The hardware fault simulation unit includes a CPU frequency dynamic reduction module, a memory address space fault injector, and a disk bad sector simulation algorithm. The memory address space fault injector implements fault simulation based on the probability of address bit flipping to verify the effectiveness of the memory error correction mechanism.

[0094] After the fault is injected, an anomaly monitoring thread is started to capture error codes in the system log and record kernel panic events and hardware alarm signals. This anomaly monitoring thread sets up a multi-level priority alarm mechanism to distinguish between critical faults and minor anomalies. The purpose of distinguishing between critical faults and minor anomalies is to improve the controllability of the testing process and the accuracy of result analysis, which is specifically reflected in three aspects: First, real-time response priority. Critical faults (such as kernel panic, hardware alarms, and complete service interruptions) must immediately trigger an alarm and may terminate the test (to avoid data loss caused by system crashes). Minor anomalies (such as individual request timeouts and temporary fluctuations in resource utilization) are only recorded without interrupting the process to ensure test continuity; Second, problem location and focus. In subsequent analysis, critical faults are directly related to core system stability defects (such as hardware compatibility and underlying protocol vulnerabilities). They are the primary optimization targets. Minor anomalies reflect marginal performance issues (such as scheduling delays and cache hit rate fluctuations) and assist in improving detailed optimization; Third, evaluation differentiation. When generating stability scores, critical faults will significantly lower the score, while minor anomalies will only have a slight impact. This ensures that the score can truly reflect the system's risk resistance and provides a clear basis for verifying the effectiveness of fault recovery strategies (such as circuit breaker mechanisms and backup switching).

[0095] In an embodiment of the present application, adjusting the evaluation results based on abnormal events includes: in response to detecting an abnormal event of the server under test, obtaining the alarm level and occurrence frequency of the abnormal event, the abnormal event including at least one of the kernel abnormality, hardware abnormality and service interruption of the server under test; adjusting the test results based on the alarm level and occurrence frequency of the abnormal event.

[0096] For example, suppose that during a test, the server under test detected multiple abnormal events, including one critical kernel crash, two major hardware anomalies, and three minor service interruptions. Based on the level and frequency of the abnormal events, the total abnormal impact value reached 10 points. By deducting 2 points for every 1 point of impact value, the test score dropped from the initial 90 points to 70 points. This adjustment reflects the significant impact of abnormal events on the test results, especially critical kernel crashes and major hardware anomalies, which can seriously affect system stability. It is recommended to prioritize analyzing kernel logs and hardware monitoring data, and retesting after fixing critical issues to ensure the accuracy of the evaluation results. For occasional anomalies, consider extending the test cycle to obtain more reliable data.

[0097] In some embodiments of the present application, in addition to dynamically adjusting access traffic based on performance indicator matching with a degradation strategy, performance indicators can also be predicted based on their changing trends, and access traffic can be adjusted based on the predicted results. Specifically, a sliding window is used to extract sequence segments from the time series of the performance indicators, where the sequence segments include performance indicators within a preset time range. Based on the changing trends of the performance indicators predicted using the sequence segments, a degradation strategy is matched to adjust the access traffic injected into the server under test.

[0098] For example, a sliding window can be used to extract a preset duration (e.g., 5-minute segments) from a performance metric time series, allowing real-time analysis of trends in key metrics such as CPU usage, memory usage, and response latency. If a performance metric is predicted to exceed a threshold (e.g., CPU usage consistently exceeding 80%), the system automatically implements a degradation strategy (e.g., throttling, circuit breaking, or service degradation) to dynamically adjust the access traffic injected into the server under test.

[0099] This method can prevent server overloads under certain test modes and proactively intervene at the earliest stages of performance degradation, avoiding system overload crashes while maintaining core service availability and creating a time window for operations and maintenance. By injecting transient and persistent faults (such as CPU overload, memory exhaustion, and network isolation) into stress testing, the system's self-healing mechanisms are monitored and the recovery time parameters are quantitatively assessed, filling a gap in existing technology for analyzing system fault tolerance.

[0100] In some embodiments of the present application, during a test, the response time of the server under test in processing access traffic is monitored. In response to the response delay generated by the server under test in processing the access traffic, a target compensation method is determined based on the type of response delay; and delay compensation is performed based on the target compensation method.

[0101] Types of response delays include network transmission delays, service processing delays, database delays, etc. For network transmission delays (such as TCP retransmissions), link optimization or CDN acceleration compensation is used; for service processing delays (such as thread pool blocking), computing resources are dynamically expanded or request buffer queues are enabled; for database delays (such as slow queries), cache preheating or query optimization is triggered. Based on the identified delay type, the system automatically matches the target compensation method. For example, when it detects that the 95th percentile response delay exceeds 500ms, it immediately starts automatic horizontal expansion and injects a current limiting strategy (such as reducing traffic by 30%), ultimately returning the compensated delay to within the 200ms threshold. This mechanism ensures that delay fluctuations do not affect the user experience through real-time classification compensation, while avoiding excessive waste of resources.

[0102] In an embodiment of the present application, at least two levels of delay compensation mechanisms can be set to eliminate the impact of measurement lag on control accuracy; the two-level delay compensation mechanism is hierarchical according to the severity of the delay. The first level (instantaneous delay compensation) mechanism is: when a short-term response delay is detected (such as a single request delay exceeding the threshold by 10% but lasting <1s), it automatically triggers fast compensation - dynamically adjusts the timeout retry strategy (such as shortening the retry interval to 1 / 2 of the original), temporarily increases the priority of the core interface, and reduces the impact of instantaneous fluctuations on user experience. The second level (continuous delay compensation) mechanism is: if the delay lasts for >3s or exceeds the threshold for 5 consecutive times, deep compensation is started - automatically expanding the backend instance (such as adding 20% ​​container nodes), switching to the backup link (such as switching from local cache to distributed cache), or downgrading non-core functions (such as pausing the data statistics module), giving priority to ensuring the response stability of core services, and recording compensation logs for subsequent optimization analysis.

[0103] According to the server testing method provided in this application, a composite test scenario is constructed to simulate a real server operating environment, which solves the problem of single scenarios in existing technologies and can effectively test the stability of servers under complex conditions such as mixed protocol interactions, sudden traffic impacts, and hardware-level failures. This method sets up an automated dynamic adjustment mechanism, which matches the degradation strategy based on performance indicators to solve the problem of extensive dynamic adjustment in existing technologies, avoids system crashes caused by improper load, improves the reliability of test data, and protects the tested server from overload while matching the test mode. This method also provides a dynamic weight allocation method to adapt to the differentiated evaluation needs of different business scenarios, breaking through the limitations of existing technologies that rely on single indicators or fixed weights, and improving the rationality of evaluation results.

[0104] This approach deeply integrates fault injection testing, dynamic load balancing, and multi-dimensional assessment to form a complete closed loop encompassing "scenario construction - stress testing - data collection - analysis and evaluation - optimization recommendations," creating a next-generation server stability testing framework. Through standardized processes and quantitative metrics, it reduces manual testing costs and improves testing efficiency. It is suitable for the R&D and O&M of high-performance servers in cloud computing, big data, and other scenarios, ensuring business continuity and user experience.

[0105] Figure 7 A schematic block diagram of an electronic device suitable for implementing a server testing method according to an embodiment of the present application is schematically shown.

[0106] Figure 7A schematic block diagram of an example electronic device 700 that can be used to implement the method of an embodiment of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0107] like Figure 7 As shown, an electronic device 700 according to an embodiment of the present application includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage unit 708 into a random access memory (RAM) 703. The processor 701 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 701 may also include onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for performing different actions of the method flow according to the embodiment of the present application.

[0108] Various programs and data required for the operation of the electronic device 700 are stored in the RAM 703. The processor 701, ROM 702, and RAM 703 are connected to each other via a bus 704. The processor 701 performs various operations of the method flow according to the embodiment of the present application by executing the programs in the ROM 702 and / or RAM 703. It should be noted that the programs may also be stored in one or more memories other than the ROM 702 and the RAM 703. The processor 701 may also perform various operations of the method flow according to the embodiment of the present application by executing the programs stored in one or more memories.

[0109] According to an embodiment of the present application, electronic device 700 may further include an input / output (I / O) interface 705, which is also connected to bus 704. Electronic device 700 may also include one or more of the following components connected to I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 708 including a hard disk; and a communication section 709 including a network interface card such as a LAN card or modem. Communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to I / O interface 705 as needed. Removable media 711, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 710 as needed, so that computer programs read from the removable media can be installed into storage section 708 as needed.

[0110] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently and not be incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the server testing method according to the embodiments of this application.

[0111] According to an embodiment of the present application, a computer-readable storage medium may be a non-volatile computer-readable storage medium, and may include, for example, but not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present application, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present application, a computer-readable storage medium may include the ROM 702 and / or RAM 703 described above and / or one or more memories other than ROM 702 and RAM 703.

[0112] The embodiments of the present application also include a computer program product, which includes a computer program containing program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the server testing method provided in the embodiments of the present application.

[0113] The computer program executes the above functions defined in the system / device of the embodiment of the present application when the computer program is executed by the processor 701. According to the embodiment of the present application, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0114] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal on a network medium, downloaded and installed via the communication portion 709, and / or installed from a removable medium 711. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0115] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from a removable medium 711. When the computer program is executed by the processor 701, the above-described functions defined in the system of the embodiment of the present application are performed. According to the embodiment of the present application, the systems, devices, means, modules, units, etc. described above can be implemented by computer program modules.

[0116] According to an embodiment of the present application, the program code for executing the computer program provided by the embodiment of the present application can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0117] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0118] Those skilled in the art will appreciate that the features described in the various embodiments of this application may be combined and / or coupled in various ways, even if such combinations or couplings are not explicitly described in this application. In particular, the features described in the various embodiments of this application may be combined and / or coupled in various ways without departing from the spirit and teachings of this application. All such combinations and / or couplings fall within the scope of this application.

[0119] The embodiments of the present application have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present application. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present application, those skilled in the art may make various substitutions and modifications, and these substitutions and modifications should all fall within the scope of the present application.

Claims

1. A server testing method, characterized in that: The method comprises: During the stress test of the server under test in the composite test scenario, based on the exceeding of the performance indicators of the server under test, the access traffic injected into the server under test is adjusted according to a degradation strategy that matches the exceeding of the performance indicators, and the degradation strategy is used to protect the server under test from overload; Converting the collected operating status data of the tested server into multi-dimensional feature data according to multiple performance dimensions; Determining weights of different performance dimensions based on a test mode of the stress test; A test result of the tested server is determined according to the weight and the multi-dimensional feature data.

2. The method according to claim 1, characterized in that The step of adjusting the access traffic injected into the server under test according to the degradation strategy matching the exceeding condition includes: When it is detected that at least one performance indicator of the tested server exceeds a threshold, a degradation strategy is determined according to the type of the at least one performance indicator and the magnitude of the value exceeding the threshold; The access traffic of the non-core service of the tested server is reduced based on the degradation strategy, and the degradation strategy indicates the reduction method and reduction rate of the access traffic.

3. The method according to claim 2, characterized in that Reducing the access traffic of the non-core service of the tested server based on the degradation strategy includes: Determine, based on the non-core service whitelist in the degradation strategy, non-core services in the tested server for which access traffic needs to be reduced, wherein the non-core service whitelist is determined according to a type of at least one performance indicator and a value exceeding a threshold; The access traffic of the non-core service is reduced based on the reduction method and reduction rate indicated by the degradation strategy, the reduction method includes at least one of reducing the access traffic in the existing access path, switching the access path of the access traffic and initiating a fuse mechanism in the access path, and the reduction rate is determined according to the numerical size and the increase rate of the at least one performance indicator exceeding the threshold.

4. The method according to claim 2, characterized in that The method further comprises: In the process of reducing the access traffic, determining an error of a decreasing rate of the access traffic relative to an expected decreasing rate; The rate of reduction of the access traffic is adjusted based on the error to reduce the error.

5. The method according to claim 1, wherein The step of converting the collected operating status data of the tested server into multi-dimensional feature data according to multiple performance dimensions includes: Dividing the collected operating status data into system performance indicators, stability indicators, and recoverability indicators according to performance dimensions; The characteristic data of the system performance index, the stability index and the recoverability index are extracted respectively to obtain the multi-dimensional characteristic data.

6. The method according to claim 1, wherein Determining the weights of different performance dimensions based on the test mode of the stress test includes: Based on the performance index of different performance dimensions of the tested server in the test mode, the weight of the performance dimension is determined, and the performance index represents the degree of influence of the performance dimension on the test result in the test mode.

7. The method according to claim 6, characterized in that The determining the weights of the performance dimensions based on the performance indexes of the tested server in different performance dimensions in the test mode includes: determining weight indices for different performance dimensions based on the test pattern; Determining a performance index for each performance dimension based on a correlation index between data of different performance dimensions in the multidimensional feature data; The product of the weight index and the performance index of each performance dimension is calculated to obtain the weight of the performance dimension.

8. The method according to claim 1, characterized in that The method further comprises: During the stress test, randomly injecting simulated fault data into the composite test scenario; Obtain the self-healing mechanism operation status of the tested server.

9. The method according to claim 8, characterized in that The method further comprises: In response to detecting an abnormal event of the server under test, obtaining an alarm level and an occurrence frequency of the abnormal event, wherein the abnormal event includes at least one of a kernel abnormality, a hardware abnormality, and a service interruption of the server under test; The test results are adjusted based on the alarm level and frequency of occurrence of the abnormal event.

10. The method according to claim 1, characterized in that The operating status data includes at least one of system kernel status data, hardware health status data, network transmission performance data, and system scheduling efficiency data of the server under test, and the method further includes at least one of the following: Collecting the system kernel status data based on the system-level monitoring probe of the kernel module and user-mode agent program deployed on the server under test; Collecting the hardware health status data based on the hardware sensor interface of the server under test; Collecting the network transmission performance data based on a network sniffer deployed on the server under test; The system scheduling efficiency data is collected based on a performance monitoring unit of a processor in the server under test.

11. The method according to claim 1, wherein The method further comprises: intercepting a sequence segment from the time series of the performance indicator through a sliding window, wherein the sequence segment includes the performance indicator within a preset time range; Based on the change trend of the performance indicator predicted by using the sequence fragments, the access traffic injected into the tested server is adjusted by matching the degradation strategy.

12. The method according to claim 1, characterized in that The method further comprises: In response to a response delay generated when the tested server processes the access traffic, determining a target compensation method according to a type of the response delay; Delay compensation is performed on the response delay based on the target compensation method.

13. An electronic device comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 12.

14. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instructions are executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

15. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instructions are executed by a processor, the steps of the method according to any one of claims 1 to 12 are implemented.

Images