Network function test method and system of server, terminal and storage medium

Abstract

The invention belongs to the technical field of server detection, and particularly relates to a server network function test method and system, a terminal and a storage medium, and the method comprises the steps: defining a test target, and configuring probe interface parameters and a resource scheduling strategy; the probe reports the CPU, the memory and the network interface utilization rate of the server to the control node in real time, and the control node adjusts the distribution of the test task by calculating the real-time load coefficient and the dynamic weight of the node according to the configured resource scheduling strategy; executing a multi-dimensional test based on the test points distributed after the test task is adjusted; through configuring a resource scheduling strategy in the step S1 and combining calculation of a node real-time load coefficient and a dynamic weight in the step S2, dynamic allocation of a test task is realized. When the node load reaches the threshold value, task migration is triggered according to the dynamic scheduling logic, resource waste caused by fixed node configuration is avoided, test resources are made to incline towards low-load nodes, the test period is remarkably shortened, and the resource utilization rate is increased.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of server detection, and particularly relates to a network function test method, system, terminal and storage medium of a server. BACKGROUND

[0002] With the rapid development of information technology, the role of servers in the network is increasingly important, and their performance and stability directly affect the quality of various network services. Therefore, comprehensive and efficient testing of server network functions has become a key link to ensure the quality of network services. However, the existing network function test methods for servers have many shortcomings and cannot meet the requirements of modern network environments for testing efficiency and accuracy.

[0003] Firstly, the resource utilization of traditional test methods is low. They usually rely on fixed configuration test nodes and cannot dynamically adjust resource allocation according to the real-time load of the server. This leads to unreasonable resource allocation during testing, long testing time and serious resource waste. For example, when the load of some nodes is too high, the test task cannot be migrated in time, resulting in low test efficiency.

[0004] Secondly, the existing test methods have a single test dimension. Most tools only focus on basic indicators such as throughput and delay, and lack comprehensive evaluation of multi-dimensional aspects such as network protocol compatibility and error recovery capability. This makes the test results unable to fully reflect the real performance of the server in the network environment, and it is difficult to find potential performance bottlenecks and compatibility problems. SUMMARY

[0005] In view of the above shortcomings of the prior art, the application provides a network function test method, system, terminal and storage medium of a server.

[0006] In a first aspect, the application provides a network function test method of a server, comprising: S1, defining a test target, configuring probe interface parameters and resource scheduling strategies; S2, the probe reports the CPU, memory and network interface utilization of the server to the control node in real time, and the control node adjusts the test task allocation through the real-time load coefficient and dynamic weight of the computing node according to the configured resource scheduling strategy; S3, performing multi-dimensional testing based on the test points allocated after the test task adjustment, including basic performance testing, protocol compatibility testing and error injection testing; S4, the control node monitors the test progress in real time, and when the delay of any node exceeds the threshold configured in step S1, automatically triggers task migration according to the dynamic scheduling logic in step S2, and after the test is completed, generates a test report combining the multi-dimensional test data in step S3, and compares it with historical data to identify performance bottlenecks.

[0007] Further improvement of the technical solution, step S1 includes: S11, define test target, including target traffic and duration; S12, configure probe interface parameters, including assigning independent IP address and protocol type to each probe; S13, set resource scheduling strategy, including load threshold and initial weight, and the initial weight calculation formula is: ; Wherein, The initial weight of the ith test node is used as the initial basis for task allocation; The hardware configuration weight is set according to the node hardware performance, and the value of 10 is taken for 10G network card node, the value of 6 is taken for 1G network card node, and the value of 8 is taken for 5G module node; The historical test efficiency factor is the ratio of the average task completion speed of the ith node in the past test to the average task completion speed of the system, ranging from 0.8 to 1.2, and the higher the value, the higher the historical test efficiency; 、 The weight coefficient is set as CPU utilization > 80%, memory utilization > 70%, and when the server load reaches or exceeds any threshold, the resource scheduling mechanism is triggered.

[0008] Further improvement of the technical solution, step S2 includes: S21, the probe real-time collects the CPU utilization, memory utilization and network interface utilization of the server, and uploads to the control node through the configured multi-interface module; S22, calculate the node real-time load coefficient, the formula is: ; Wherein, The node real-time load coefficient ranges from 0 to 1; The preset CPU maximum computing power is; The CPU idle computing power is; The memory usage is; The network bandwidth utilization is; 、 、 The weight factor is; S23, according to the resource scheduling strategy configured in step S1, when Trigger task migration preparation, and calculate the node dynamic weight at the same time: ; Wherein, The node dynamic weight at time t is; The node real-time load is normalized to 0-1; average load of all nodes; is a load feedback coefficient, ranging from 0.3 to 0.7; S24, according to the dynamic weight distribution test task, the formula is: ; wherein, is the amount of test tasks allocated to the jth test node; is the dynamic weight of the jth test node at time t; is the sum of the dynamic weights of all n test nodes at time t, used for normalizing the weight proportion of a single node; is the total amount of test tasks to be allocated at present; is the upward rounding symbol; the weight is recalculated and adjusted every 60 seconds.

[0009] Further improvements of the technical solution are that step S3 includes: S31, performing basic performance testing, sending standardized test traffic containing TCP / UDP data streams through probes, and collecting throughput , delay time, throughput The calculation formula is: ; wherein, is the total amount of data transmitted during the test, in bytes, which is counted in real time by the probe; is the test duration; S32, conducting protocol compatibility testing, simulating mixed traffic containing TCP, UDP and HTTP / 3, and calculating the protocol conflict probability: ; wherein, is the instantaneous flow of the kth protocol, in bps; is the average length of the data packet of the kth protocol, in bits; is the server network interface bandwidth, in bps; is the conflict detection time window; is the number of concurrent protocol types; S33, performing error injection testing, randomly injecting network errors in the test traffic, and dynamically adjusting the error injection intensity , the formula is: ; wherein, is the initial error injection intensity; is the error recovery rate of the server within 10 seconds, in units of successfully recovered error number / second; The average error recovery rate of the server history; The maximum error recovery rate of the server theory; S34, implement burst traffic test, according to formula Generate traffic, wherein, The traffic climbing rate coefficient is, ; The maximum bandwidth of burst traffic in the test is set according to the test target; The initial minimum bandwidth of burst traffic in the test is the starting point of traffic climbing; The traffic climbing time is; The stable duration is; send test traffic through the probe.

[0010] Further improvement of the technical solution is that step S4 includes: S41, the control node monitors the progress of the multi-dimensional test in step S3 in real time through the Prometheus monitoring tool, and collects the node delay and load change rate in real time; S42, calculate the dynamic threshold, the formula is: ; wherein, The average value of the delay in the history test is; The standard deviation of the delay in the history test, which is used to assist in judging whether the node delay is abnormal; S43, when any node delay exceeds the threshold value configured in step S1 or the load change rate exceeds the set value, automatically trigger task migration according to the dynamic scheduling logic in step S2, and the load change rate trigger condition formula is: ; wherein, The change rate of the node load with time is; The load change rate threshold is.

[0011] Further improvement of the technical solution is that step S4 further includes: S44, after the test, generate a test report containing basic indicators, protocol compatibility indicators and error recovery capability indicators according to the multi-dimensional test data in step S3, and calculate the server stability score , the formula is: ; wherein, The throughput compliance rate is; The delay jitter rate is; The error recovery success rate is; 、 、 The index weight is; The sensitivity coefficient is; The reference threshold is.

[0012] The further improvement of the technical solution is that step S4 further comprises: S45, comparing the current test report with the historical data, identifying the performance bottleneck by calculating the bottleneck index, and the formula is: Among them, is the current test performance data; is the historical test performance data. In a second aspect, the application provides a network function test system of a server, comprising: A hardware layer, the hardware layer comprising a test probe and a control node; the test probe is deployed at the edge of a server cluster, integrates a multi-interface communication module and an FPGA acceleration chip, and is used for collecting the CPU utilization, memory utilization and network interface utilization of the server in real time, sending standardized test traffic and mixed traffic of multiple protocols, and injecting network errors in the test traffic; the control node is constructed based on a Linux system, interacts with the test probe through a RESTful API, is used for receiving the data reported by the test probe, adjusting the test task allocation according to a preset resource scheduling strategy, monitoring the test progress in real time and triggering task migration when the node delay exceeds a threshold value; A software layer, the software layer comprising a task scheduling engine, a test script engine and a data storage and analysis module; the task scheduling engine is developed by using a Go language, is used for realizing a dynamic load balancing algorithm and task priority queue management, calculating the real-time load coefficient and dynamic weight of the node; the test script engine supports Python and Lua scripts, and is used for customizing a test scene; the data storage and analysis module stores the test data by using an InfluxDB, and generates a multi-dimensional visual report by combining Grafana, supports historical data comparison and abnormal early warning.

[0013] In a third aspect, the application provides a terminal, comprising: A processor and a memory, wherein The memory is used for storing a computer program, The processor is used for calling and running the computer program from the memory, so that the terminal executes the method of the terminal described above.

[0014] In a fourth aspect, the application provides a computer storage medium, the computer readable storage medium stores instructions, when the instructions are run on a computer, the computer executes the method described in the above aspects.

[0015] The beneficial effects of the application are: Improve resource utilization efficiency: by configuring a resource scheduling strategy in step S1, combining the real-time load coefficient and dynamic weight ​The calculation of the test task realizes dynamic allocation of the test task. When the node load reaches a threshold (such as CPU utilization > 80%), task migration is triggered according to the dynamic scheduling logic, avoiding resource waste caused by fixed node configuration, making test resources tilt to low-load nodes, significantly shortening the test period, and improving resource utilization.

[0016] Implement multi-dimensional comprehensive testing: Step S3 covers basic performance testing (throughput, delay), protocol compatibility testing (TCP / UDP / HTTP / 3 mixed traffic), error injection testing, and burst traffic testing, which comprehensively evaluates the server network function through multi-dimensional indicators (such as protocol conflict probability, error recovery rate). Compared with traditional single-index testing, it can more accurately capture potential compatibility problems and performance bottlenecks, and improve test coverage.

[0017] Improve test accuracy and dynamic adaptability: The hardware layer uses an integrated FPGA acceleration chip probe to collect data in real time, ensuring that the test data accuracy reaches the microsecond level; the dynamic adjustment of error injection intensity and burst traffic makes the test scene closer to the real network environment, improving the credibility of the test results.

[0018] Intelligent monitoring and bottleneck identification: Step S4 realizes abnormal early warning through real-time monitoring by Prometheus combined with dynamic thresholds; the calculation of stability score S and bottleneck index quantifies server performance and accurately locates bottlenecks, improving efficiency compared with manual analysis, and helping to quickly optimize server network functions.

[0019] Flexible and scalable system architecture: The hardware layer supports concurrent testing of multiple interfaces (wired / wireless / 5G), the software layer supports Python / Lua script customization scenarios, and the data storage and analysis module supports historical data comparison and visualization, which can adapt to different sizes of server clusters and diverse testing needs, improving the scalability of traditional testing systems. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0021] Figure 1 The method of an embodiment of the present application is a schematic flowchart.

[0022] Figure 2 The schematic block diagram of the system of an embodiment of the present application is shown.

[0023] Figure 3A structural schematic diagram of a terminal provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] In order to make the objectives, characteristics and advantages of the present application more obvious and easy to understand, the technical solutions of the present application will be described clearly and completely below in combination with the drawings in the specific embodiments. Obviously, the embodiments described below are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0025] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used in the specification of the present application are only for the purpose of describing the specific embodiments and are not intended to limit the present application.

[0026] Figure 1 A schematic flowchart of a network function test method of a server provided by the present application is shown. In the flowchart, Figure 1 The execution subject can be a network function test system of a server. According to different requirements, the order of steps in the flowchart can be changed, and some steps can be omitted.

[0027] As Figure 1 shown, the method comprises: S1, defining a test target, configuring probe interface parameters and resource scheduling strategies; S2, the probe reports the CPU, memory and network interface utilization of the server to the control node in real time, and the control node adjusts the test task allocation through the real-time load coefficient and dynamic weight of the computing node according to the configured resource scheduling strategy; S3, performing multi-dimensional testing based on the test points allocated after the test task adjustment, including basic performance testing, protocol compatibility testing and error injection testing; S4, the control node monitors the test progress in real time, and when the delay of any node exceeds the threshold configured in step S1, automatically triggers task migration according to the dynamic scheduling logic in step S2, and after the test is completed, generates a test report combining the multi-dimensional test data in step S3, and compares it with historical data to identify performance bottlenecks.

[0028] In order to facilitate the understanding of the present application, the principle of the network function test method of the server provided by the present application will be further described below in combination with the process of testing the network function of the server in the embodiments.

[0029] Firstly, step S1 comprises: S11, define test target, including target traffic and duration; S12, configure probe interface parameters, including assigning each probe an independent IP address and protocol type; S13, set resource scheduling strategy, including load threshold and initial weight, the initial weight calculation formula is: ; Where, is the initial weight of the ith test node, which is the initial basis for task allocation; is the hardware configuration weight, which is set according to node hardware performance, with a value of 10 for 10G network card nodes, 6 for 1G network card nodes, and 8 for 5G module nodes; is the historical test efficiency factor, which is the ratio of the average task completion speed of the ith node to the system average task completion speed in past tests, ranging from 0.8 to 1.2, with higher values indicating higher historical test efficiency; 、 is the weight coefficient; the load threshold is set to CPU utilization > 80%, memory utilization > 70%, and when the server load reaches or exceeds any threshold, the resource scheduling mechanism is triggered.

[0030] Specifically, S11, define test target, including target traffic and duration: According to the test requirements of server network function, the specific parameters of test target are determined: Target traffic: set according to the actual application scenario of the server, for example, for data center servers, the target traffic can be set to 10Gbps (10G network environment); for edge computing servers, the target traffic can be set to 1Gbps (1G network environment); for 5G base station associated servers, the target traffic can be set to 5Gbps (adapted to 5G module bandwidth).

[0031] Duration: set according to test accuracy requirements, the duration of basic stability test can be set to 24 hours, the duration of high-intensity stress test can be set to 1 hour, and the duration of burst traffic impact test can be set to 30 minutes (including traffic climbing, stable, and descending phases).

[0032] By clearly defining target traffic and duration, it is ensured that the test scenario is consistent with the actual running environment of the server, avoiding the disconnection between test results and real performance.

[0033] S12, configure probe interface parameters, including assigning each probe an independent IP address and protocol type: Independent IP address allocation: adopt local area network private IP address segment (such as 192.168.1.0 / 24) to allocate unique IP for each probe, for example: Probe 1 IP: 192.168.1.10; Probe 2 IP: 192.168.1.11.

[0034] Similarly, ensure that there is no IP conflict between the probes and the control node (IP set to 192.168.1.1) and the servers (IP set to 192.168.1.20-192.168.1.50).

[0035] Protocol type configuration: Configure the corresponding protocol for the probe according to the network protocol supported by the test target, for example: Basic performance test configuration TCP (port 8080) and UDP (port 5001) protocols; Additional protocol compatibility test HTTP / 3 (based on QUIC protocol, port 443); 5G module test requires configuration of 5G NR protocol (compliant with 3GPP standard).

[0036] The probe realizes concurrent communication of multiple protocols through a multi-interface module (supports RJ45, SFP+, 5G antenna interface), ensuring that the interface type (such as gigabit network card, 5G module) matches the server.

[0037] S13, set resource scheduling strategy, including load threshold and initial weight: Load threshold setting: Set CPU utilization threshold to 80%: when the server CPU core occupancy rate exceeds 80% (such as 6.4 cores and above in a busy state in an 8-core CPU), trigger resource scheduling; Set memory utilization threshold to 70%: when the proportion of used memory to total memory exceeds 70% (such as using more than 22.4GB in a 32GB memory), trigger resource scheduling; When any threshold is triggered, the control node immediately starts task migration preparation (such as calculating dynamic weight and screening idle nodes).

[0038] Initial weight calculation: ; wherein, (Hardware configuration weight accounts for a higher proportion of historical efficiency, and high-performance nodes are given priority to undertake tasks); (Hardware configuration weight): 10 for gigabit network card nodes, 6 for gigabit network card nodes, and 8 for 5G module nodes; (Historical test efficiency factor): calculated according to the past 3 test data of the node, for example: the average completion speed of node A in the past test is 1.2 times the average value of the system, then ; the average completion speed of node B in the past test is 0.8 times the average value of the system, then .

[0039] The initial weight of the 10G network card node A is The initial weight of the 10G network card node A is ; The initial weight of the 10G network card node B is The initial weight of the 10G network card node B is .

[0040] Through the initial weight calculation, the node with better hardware performance and higher historical efficiency obtains higher initial task allocation priority, which lays a foundation for subsequent dynamic scheduling.

[0041] Secondly, step S2 comprises: S21, the probe collects the CPU utilization, memory utilization and network interface utilization of the server in real time, and uploads to the control node through the configured multi-interface module; S22, the real-time load coefficient of the computing node is calculated, and the formula is: ; Wherein, The real-time load coefficient of the computing node is 0 to 1; The preset maximum CPU computing power is The CPU idle computing power is The memory usage is The network bandwidth utilization is 、 、 The weight factor is S23, according to the resource scheduling strategy configured in step S1, when Trigger task migration preparation, and calculate the dynamic weight of the computing node: ; Wherein, The dynamic weight of the node at time t is The real-time load of the node is normalized to 0-1; The average load of all nodes is The load feedback coefficient is 0.3 to 0.7; S24, according to the dynamic weight, the test task is distributed, and the formula is: ; Wherein, The test task amount allocated to the jth test node is The dynamic weight of the jth test node at time t is The total weight of all n test nodes at time t is used to normalize the weight proportion of a single node; The total amount of test tasks to be allocated at present is Upward rounding symbol; recompute weights and adjust allocations every 60 seconds.

[0042] Specifically, S21, the probe real-time collects the CPU utilization rate, memory utilization rate and network interface utilization rate of the server, and uploads to the control node through the configured multi-interface module: Data acquisition method: the FPGA acceleration chip integrated in the test probe collects the server core indicators in real time through a hardware-level data capture mechanism: CPU utilization rate: by reading the performance counter of the server CPU (such as Intel's RAPL interface), the occupancy rate of each core is counted every 100 ms, and the average value is taken as the current CPU utilization rate (accurate to 0.1%); Memory utilization rate: the used memory (MemUsed) and total memory (MemTotal) are obtained through system calls (such as Linux's / proc / meminfo), and the ratio (MemUsed / MemTotal) is calculated, and updated every 200 ms; Network interface utilization rate: the number of received / sent data packets and bytes per second is counted through the network card driver (such as DPDK), compared with the maximum bandwidth of the interface (such as 10Gbps for a gigabit network card), and the real-time bandwidth utilization rate (Bcurr / Bmax) is calculated, sampled every 50 ms.

[0043] Data upload mechanism: the probe uses the TCP protocol (port 8090) to encapsulate the collected data into JSON format (example: {"node_id":"server_01", "cpu_usage":65.2, "mem_usage":58.7, "net_usage":42.3}) through the multi-interface module (such as RJ45 Ethernet interface, 5G module) configured by S12, and uploads it to the control node (IP: 192.168.1.1) every 500 ms, ensuring that the control node can real-time monitor the server load status.

[0044] S22, calculate the node real-time load coefficient through the above formula: : preset CPU maximum computing power (unit: GHz), set according to server hardware configuration (such as 8-core 2.5GHz CPU ); : CPU idle computing power (unit: GHz), calculated by real-time monitoring of idle core number (such as 2 cores idle in 8-core, then ); : memory usage rate (i.e. memory utilization rate collected in S21, range 0-1); : Network bandwidth utilization (i.e. network interface utilization collected in S21, range 0-1); Weight factor (CPU load weight is the highest, in line with the characteristics of the server performance bottleneck more from the computing resources).

[0045] Through normalization processing, CPU, memory, network load are uniformly mapped to the range of 0-1, and the comprehensive load coefficient is obtained by weighted summation (range 0-1), the higher the value, the heavier the node load.

[0046] S23, trigger task migration preparation and calculate node dynamic weight: Task migration trigger condition: when the node real-time load coefficient calculated by S22 (i.e. 0.8), the control node determines that the node load is too high, and immediately triggers task migration preparation (such as suspending new task allocation, marking migratable tasks).

[0047] : Initial weight calculated in S13 (such as the initial weight of server A is 6.48); : Node real-time load (i.e. , normalized to 0-1); : Average load of all nodes (such as the of 5 nodes are 0.9, 0.7, 0.6, 0.5, 0.4 respectively, then ); : Load feedback coefficient, taking the middle value to balance the load sensitivity.

[0048] The dynamic weight of the node with lower load than the average value will be higher than the initial weight (encouraging to undertake more tasks); the dynamic weight of the node with higher load than the average value will be reduced (reducing task allocation), achieving load balancing.

[0049] : Dynamic weight of the jth node (such as the of node A); : Sum of dynamic weights of all n nodes (such as the sum of 5 nodes is 30); : Total amount of test tasks to be allocated currently (such as 100 test cases); : Ceiling function symbol (ensuring the task amount is an integer).

[0050] The dynamic weight is recalculated and the task allocation is adjusted every 60 seconds to ensure that the task distribution remains balanced after the load changes.

[0051] Next, step S3 includes: S31, perform basic performance testing, send standardized test traffic containing TCP / UDP data streams through probes, and collect throughput , delay time, throughput The calculation formula is: ; Wherein, is the total amount of data transmitted during the test, in bytes, which is counted in real time by the probe; is the test duration; S32, carry out protocol compatibility test, simulate mixed traffic containing TCP, UDP and HTTP / 3, and calculate protocol conflict probability: ; Wherein, is the instantaneous flow of the kth protocol, in bps; is the average length of the data packet of the kth protocol, in bits; is the server network interface bandwidth, in bps; is the conflict detection time window; is the number of concurrent protocol types; S33, carry out error injection test, randomly inject network errors in test traffic, and dynamically adjust error injection strength , the formula is: ; Wherein, is the initial error injection strength; is the error recovery rate of the server within 10 seconds, in units of successful error recovery number / second; is the historical average error recovery rate of the server; is the theoretical maximum error recovery rate of the server; S34, implement burst traffic test, generate traffic according to the formula , wherein, is the traffic climbing rate coefficient, ; is the maximum bandwidth of burst traffic in the test, which is set according to the test target; is the initial minimum bandwidth of burst traffic in the test, which is the starting point of traffic climbing; is the traffic climbing time; is the stable duration; send test traffic through probes.

[0052] Specifically, S31, perform basic performance testing: Test traffic generation: The test probe generates standardized TCP / UDP data streams through the FPGA acceleration module, where TCP traffic adopts Iperf3 tool configuration (window size 64KB, congestion control algorithm CUBIC), and UDP traffic has a fixed packet size (1024 bytes) and a sending rate that increases from 100Mbps to the target traffic (e.g., 10Gbps) in steps.

[0053] Data collection and calculation: The probe's built-in counter real-time counts the total data volume transmitted during the test, accurate to 1 byte; The test duration is recorded by the timer, unit: seconds (accurate to 0.001 seconds); For example: transmitting 10000000 bytes of data in 10 seconds, the throughput is bytes / second (i.e., 8Mbps).

[0054] Delay time collection: Through the timestamp synchronization between the probe and the server (NTP protocol calibration, error <1us), the round-trip time (RTT) of the data packet from sending to receiving is recorded, sampled every 100ms, and the average value is taken as the delay time.

[0055] S32, protocol compatibility test: Mixed traffic simulation: The probe generates mixed traffic of multiple protocols according to the preset proportion (e.g., TCP:UDP:HTTP / 3=5:3:2), where TCP is used to simulate reliable data transmission (e.g., file download), UDP is used to simulate real-time streaming (e.g., video transmission), and HTTP / 3 is used to simulate modern Web communication.

[0056] : The instantaneous traffic of the kth protocol (e.g., TCP=5Gbps, UDP=3Gbps, HTTP / 3=2Gbps); : The average length of the data packet of the kth protocol (TCP=1500 bytes=12000 bits, UDP=1000 bytes=8000 bits, HTTP / 3=2000 bytes=16000 bits); : Server network interface bandwidth (e.g. bps); : Conflict detection time window (fixed at seconds); : Number of concurrent protocol types (here ).

[0057] For example: substituting the above parameters, we get , reflecting the conflict risk when multiple protocols are concurrent.

[0058] S33, error injection test is performed: Error type and injection method: probe randomly injects network errors in traffic, including checksum error (TCP / UDP packet check bit tampering), fragment loss (randomly discarding 1-5% IP fragments), out-of-order transmission (disrupting packet sending order), and injection position is controlled by a pseudo-random number generator (seed fixed).

[0059] burst traffic Generated by piecewise function: the probe sends burst traffic through the SFP+ interface, and records the server's processing capacity (such as whether there are packet loss or delay spikes) during the traffic climbing (0-5 seconds), stable (5-60 seconds), and falling (60-65 seconds) stages.

[0060] Then, step S4 includes: S41, the control node monitors the progress of the multi-dimensional test in step S3 in real time through the Prometheus monitoring tool, and collects the delay and load change rate of each node in real time; S42, calculate the dynamic threshold, the formula is: ; wherein, is the average value of the delay in the historical test; is the standard deviation of the delay in the historical test, which is used to assist in determining whether the node delay is abnormal; S43, when any node delay exceeds the threshold value configured in step S1 or the load change rate exceeds the set value, automatically trigger task migration according to the dynamic scheduling logic in step S2, and the load change rate trigger condition formula is: ; wherein, is the rate of change of node load over time; is the load change rate threshold.

[0061] Further, step S4 further includes: S44, after the test, generate a test report containing basic indicators, protocol compatibility indicators, and error recovery capability indicators based on the multi-dimensional test data in step S3, and calculate the server stability score , the formula is: ; wherein, is the throughput compliance rate; is the delay jitter rate; is the error recovery success rate; , , is the indicator weight; is the sensitivity coefficient; is the baseline threshold.

[0062] Finally, step S4 also includes: S45, compare the current test report with historical data, identify performance bottlenecks by calculating the bottleneck index, the formula is: ; Where, is the current test performance data; is the historical test performance data. Specifically, S41, the control node monitors the test progress and data collection in real time through the Prometheus monitoring tool The control node deploys the Prometheus monitoring tool (version v2.30.3), and realizes real-time monitoring of the multi-dimensional test in step S3 through the following ways: Monitoring index configuration: through the scrape configs configuration item of Prometheus, set to pull data from the / metrics interface of the test probe every 10 seconds, and collect indexes including: Node latency (node_latency_ms): unit is milliseconds, accurate to 0.01 ms; Load change rate (load_change_rate): unit is % / second, reflecting the change amount of node load coefficient per second; Test progress (test_progress): unit is %, that is, the ratio of the number of completed test cases to the total number of cases.

[0063] Data storage and visualization: the collected data is stored in the time series database of Prometheus (default retention period is 15 days), and real-time monitoring panels are generated through Grafana plugins to intuitively display the change curves of various indexes.

[0064] Delay trigger: when the real-time delay of the node (after being collected and denoised by Prometheus) exceeds the fixed threshold (such as 30 ms) configured in step S1 or the dynamic threshold (24.89 ms) calculated in S42, trigger task migration; Load change rate trigger: the formula of the load change rate trigger condition is: .

[0065] When any of the trigger conditions is met, the control node migrates 50% of the unfinished tasks of the overloaded node to the node with load coefficient <0.3 according to the dynamic scheduling logic in step S2 (such as the dynamic weight calculation result in S23), and the migration process synchronizes the task state through the SSH protocol to ensure that there is no task loss.

[0066] Test report content: integrate the multi-dimensional test data of step S3 to form a structured report, including: Basic performance indicators: throughput (such as 9.2Gbps), average delay (21ms), packet loss rate (0.1%); Protocol compatibility indicators: protocol conflict probability under TCP / UDP / HTTP / 3 mixed traffic (6.3%), connection success rate of each protocol (all ≥99.8%); Error recovery capability indicators: recovery success rate in error injection test (95%), maximum recovery time (200ms).

[0067] : Throughput compliance rate, actual throughput / target traffic 10Gbps; : Delay jitter rate, delay standard deviation / average delay; : Error recovery success rate; If the stability score S is calculated to be about 0.86, it is determined to be stable (the range of stability score S is 0-1, ≥0.8 is determined to be stable).

[0068] The bottleneck index calculated by the above formula is about 0.025 (<0.3, no significant bottleneck), when the bottleneck index is >0.3, the bottleneck point (such as insufficient network card performance) is located in combination with specific indicators (such as network bandwidth utilization rate >95% continuously), and optimization suggestions are proposed in the report.

[0069] As shown in Figure 2 , the present application provides a network function test system of a server, comprising: A hardware layer, the hardware layer comprising a test probe and a control node; the test probe is deployed at the edge of a server cluster, integrated with a multi-interface communication module and an FPGA acceleration chip, used for real-time collection of CPU utilization, memory utilization and network interface utilization of the server, sending of standardized test traffic and multi-protocol mixed traffic, and injection of network errors in the test traffic; the control node is built based on a Linux system, interacts with the test probe through a RESTful API, used for receiving data reported by the test probe, adjusting test task allocation according to a preset resource scheduling strategy, real-time monitoring of test progress and triggering of task migration when node delay exceeds a threshold value; The software layer includes a task scheduling engine, a test script engine and a data storage and analysis module; the task scheduling engine is developed by using Go language, is used for realizing a dynamic load balancing algorithm and a task priority queue management, calculating a real-time load coefficient and a dynamic weight of a computing node; the test script engine supports Python and Lua scripts, and is used for customizing a test scene; the data storage and analysis module stores test data by using InfluxDB, and generates a multidimensional visual report by combining Grafana, and supports historical data comparison and abnormality early warning.

[0070] Figure 3 A structure schematic diagram of a terminal 300 is provided for an embodiment of the present application, and the terminal 300 can be used to execute the network function test method of the server provided by the embodiment of the present application.

[0071] The terminal 300 can include a processor 310, a memory 320 and a communication module 330. These components communicate through one or more buses, and those skilled in the art can understand that the structure of the server shown in the figure does not constitute a limitation on the present application, and it can be a bus structure or a star structure, and can include more or fewer components than shown in the figure, or combine certain components, or different component arrangements.

[0072] The memory 320 can be used to store execution instructions of the processor 310, and the memory 320 can be realized by any type of volatile or non-volatile storage terminal or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic storage, a flash memory, a magnetic disk or an optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the terminal 300 can execute part or all of the steps in the following method embodiments.

[0073] The processor 310 is the control center of the storage terminal, connects each part of the entire electronic terminal by using various interfaces and lines, executes or runs the software programs and / or modules stored in the memory 320, and calls the data stored in the memory, so as to execute various functions of the electronic terminal and / or process data. The processor can be composed of an integrated circuit (IC), for example, can be composed of a single packaged IC, or can be composed of a plurality of packaged ICs connected together. For example, the processor 310 can only include a central processing unit (CPU). In the embodiment of the present application, the CPU can be a single operation core, or can include a plurality of operation cores.

[0074] The communication module 330 is configured to establish a communication channel, so that the storage terminal can communicate with other terminals. The storage terminal receives user data sent by other terminals or sends user data to other terminals.

[0075] The present application also provides a computer storage medium, wherein the computer storage medium can store a program, and the program can include some or all steps in the embodiments provided by the present application when executed. The storage medium can be a magnetic disc, an optical disc, a read-only memory (ROM) or a random access memory (RAM) and the like.

[0076] Those skilled in the art can clearly understand that the technology in the embodiments of the present application can be realized by means of software and necessary general hardware platforms. Based on such understanding, the technical solutions in the embodiments of the present application can be embodied in the form of a software product, which is stored in a storage medium such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disc or an optical disc, and the like, and includes a plurality of instructions for causing a computer terminal (which can be a personal computer, a server, or a second terminal, a network terminal and the like) to execute all or part of the steps of the method described in the embodiments of the present application.

[0077] In the present specification, the same or similar parts among various embodiments can be referred to each other. In particular, for the terminal embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0078] In the several embodiments provided by the present application, it should be understood that the disclosed system and method can be implemented in other ways. For example, the system embodiments described above are merely schematic. For example, the division of the modules is merely a logical function division. In actual implementation, another division manner can be used. For example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the systems or modules shown or discussed can be indirect coupling or communication connection through some interfaces. The coupling or communication connection can be electrical, mechanical or in other forms.

[0079] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed to multiple network modules. Part or all of the modules can be selected as needed to achieve the purpose of the embodiment.

[0080] In addition, each functional module in various embodiments of the application can be integrated into one processing module, or each module can exist physically alone, or two or more modules can be integrated into one module.

[0081] Although the application has been described in detail with reference to the preferred embodiments, the application is not limited to the preferred embodiments. Those skilled in the art can make various equivalent modifications or replacements to the embodiments of the application without departing from the spirit and essence of the application, and these modifications or replacements should be within the scope of the application. Any person skilled in the art within the technical scope disclosed by the application can easily think of changes or replacements, which should be covered within the protection scope of the application.

Claims

1. A network function test method of a server, characterized by, Comprise: S1, define test target, configure probe interface parameters and resource scheduling strategy; S2, probe real-time reporting server CPU, memory, network interface utilization to control node, control node according to the configured resource scheduling strategy, through the calculation node real-time load coefficient and dynamic weight adjustment test task allocation; S3, based on the test task adjustment after the distribution of test point executes multidimensional test, including basic performance test, protocol compatibility test and error injection test; S4, control node real-time monitoring test progress, and when any node delay exceeds the threshold value configured in step S1, according to the dynamic scheduling logic in step S2, automatically trigger task migration, and after the test, combine the multidimensional test data in step S3 to generate test report, and compare with historical data to identify performance bottleneck.

2. The network function testing method of a server according to claim 1, wherein, Step S1 includes: S11, define test target, including target traffic and duration; S12, configure probe interface parameters, including assigning independent IP address and protocol type for each probe; S13, set resource scheduling strategy, including load threshold and initial weight, the initial weight calculation formula is: ； wherein, is the initial weight of the i-th test node, which is the initial basis for task allocation; is the hardware configuration weight, which is set according to the node hardware performance, and the value of a 10-gigabit network card node is 10, the value of a 1-gigabit network card node is 6, and the value of a 5G module node is 8; is the historical test efficiency factor, which is the ratio of the average task completion speed of the i-th node in the past test to the average task completion speed of the system, and the range is 0.8 to 1.2, and the higher the value, the higher the historical test efficiency; , is the weight coefficient; the load threshold is set to CPU utilization > 80% and memory utilization > 70%, and when the server load reaches or exceeds any threshold, the resource scheduling mechanism is triggered.

3. The network function testing method of a server according to claim 2, wherein, Step S2 includes: S21, probe real-time acquisition server CPU utilization, memory utilization and network interface utilization, and upload to control node through configured multi-interface module; S22, calculate node real-time load coefficient, formula is: ； wherein, is a real-time load coefficient of the node, ranging from 0 to 1; is a preset maximum computing power of the CPU; is an idle computing power of the CPU; is a memory usage rate; is a network bandwidth utilization rate; , , is a weight factor; S23, when the resource scheduling strategy configured in step S1 triggers task migration preparation, and the dynamic weight of the computing node is calculated: simultaneously ； wherein, is the node dynamic weight for time t; is the node real-time load, normalized to 0-1; is the average load of all nodes; is the load feedback coefficient, with a value range of 0.3 to 0.7; S24, distribute test task according to dynamic weight, formula is: ； wherein, the amount of test tasks assigned to the jth test node; the dynamic weight of the jth test node at time t; the sum of dynamic weights of all n test nodes at time t, used for normalizing the weight proportion of a single node; the total amount of test tasks to be currently assigned; the ceiling symbol; the weight is recalculated and adjusted every 60 seconds.

4. The network function testing method of a server according to claim 1, wherein, Step S3 includes: S31, perform basic performance test, send standardized test traffic containing TCP / UDP data stream through probe, and collect throughput , delay time, throughput The calculation formula is: ； wherein, Total data transferred during the test, in bytes, as measured by the probe in real time; Test duration; S32, carry out protocol compatibility test, simulate multi-protocol mixed traffic containing TCP, UDP and HTTP / 3, and calculate protocol conflict probability: ； wherein, is the instantaneous flow rate of the kth protocol, in bps; is the average packet length of the kth protocol, in bits; is the server network interface bandwidth, in bps; is the collision detection time window; is the number of concurrent protocols; S33, perform error injection test, randomly inject network errors in test traffic, and dynamically adjust error injection strength , the formula is: ； wherein, is the initial error injection intensity; is the error recovery rate of the server in 10 seconds, in units of successful recovered errors per second; is the historical average error recovery rate of the server; is the theoretical maximum error recovery rate of the server; S34, perform burst traffic test, according to formula Generate traffic, where, is the traffic ramp rate coefficient, ; is the maximum bandwidth of burst traffic in the test, set according to the test target; is the initial minimum bandwidth of burst traffic in the test, as the starting point of traffic ramping; is the traffic ramping time; is the stable duration; send test traffic through the probe.

5. The network function testing method of a server according to claim 1, wherein, Step S4 includes: S41, control node real-time monitoring progress of multidimensional test in step S3 through Prometheus monitoring tool, real-time acquisition of each node delay, load change rate; S42, calculate a dynamic threshold, the formula is: ; wherein, is the average of the delay in the historical test; is the standard deviation of the delay in the historical test, which is used to assist in determining whether the node delay is abnormal; S43, when any node delay exceeds the threshold configured in step S1 or the load change rate exceeds the set value, the task migration is automatically triggered according to the dynamic scheduling logic in step S2, and the load change rate trigger condition formula is: ; wherein, is the change rate of the node load with time; is the load change rate threshold.

6. The network function testing method of a server according to claim 5, wherein, Step S4 also includes: S44, after the test ends, the multi-dimensional test data combined in step S3 are used to generate a test report containing the basic index, the protocol compatibility index, and the error recovery capability index, and a server stability score is calculated , the formula is: ; wherein, is the throughput compliance rate; is the delay jitter rate; is the error recovery success rate; , , is the index weight; is the sensitivity coefficient; is the reference threshold value.

7. The network function testing method of a server according to claim 6, wherein, Step S4 also includes: S45, compare the current test report with historical data, identify performance bottleneck by calculating bottleneck index, formula is: ； wherein, is current test performance data; is historical test performance data.

8. A network function testing system of a server, characterized by, Comprise: Hardware layer, hardware layer includes test probe and control node; Test probe is deployed at the edge of server cluster, integrates multi-interface communication module and FPGA acceleration chip, is used for real-time acquisition of server CPU utilization, memory utilization and network interface utilization, sends standardized test traffic and multi-protocol mixed traffic, and injects network error in test traffic; Control node is based on Linux system construction, interacts with test probe through RESTful API, is used for receiving test probe reported data, adjusting test task allocation according to preset resource scheduling strategy, real-time monitoring test progress and triggering task migration when node delay exceeds threshold value; Software layer, software layer includes task scheduling engine, test script engine and data storage and analysis module; Task scheduling engine is developed by using Go language, is used for realizing dynamic load balancing algorithm and task priority queue management, calculating node real-time load coefficient and dynamic weight; Test script engine supports Python and Lua script, is used for customizing test scene; The data storage and analysis module uses InfluxDB to store test data and combines Grafana to generate multi-dimensional visual reports, supporting historical data comparison and abnormal early warning.

9. A terminal, characterized by Comprise: a processor; a memory for storing execution instructions of the processor; wherein the processor is configured to perform the method of any one of claims 1-7.

10. A computer readable storage medium storing a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-7.

Images