Distributed load test system and method

Abstract

The invention discloses a distributed load test system and method. The system comprises a user operation interface which is configured to receive a pressure measurement task and generate a task request based on the pressure measurement task; the cluster scheduling module is configured to distribute a test task corresponding to the task request to a plurality of load-balanced working nodes of the distributed load test platform based on a task concurrency demand; and the test execution management module is configured to execute the distributed test tasks by utilizing the working nodes to generate test data. The technical problem that the prior art has defects in the aspects of cluster scheduling, centralized management, test result processing, real-time monitoring and the like is solved.

Description

Technical Field

[0001] The present invention relates to the technical fields of software engineering and performance testing, and in particular, to a distributed load testing system and method based thereon. Background Art

[0002] With the rapid development of Internet technology and the continuous improvement of application complexity, the performance testing of distributed systems has become a key link to ensure service reliability and user experience. Traditional load testing technologies usually rely on single machines or small-scale clusters, and manually configure and execute test tasks one by one, resulting in problems such as low test efficiency, insufficient resource utilization, and lagging result feedback. In recent years, distributed load testing systems have gradually become the mainstream solution, but the technical bottlenecks in aspects such as cluster scheduling, centralized management, test result processing, and real-time monitoring have not been effectively solved.

[0003] In view of the above problems, no effective solution has been proposed yet. Summary of the Invention

[0004] Embodiments of the present invention provide a distributed load testing system and method based thereon, so as to at least solve the technical problems existing in the prior art in aspects such as cluster scheduling, centralized management, test result processing, and real-time monitoring.

[0005] According to one aspect of the embodiments of the present invention, a distributed load testing system is provided, including: a user operation interface configured to receive a stress testing task and generate a task request based on the stress testing task; a cluster scheduling module configured to allocate test tasks corresponding to the task request to a plurality of load-balanced working nodes of the distributed load testing platform based on task concurrency requirements; and a test execution management module configured to use the working nodes to execute the allocated test tasks and generate test data.

[0006] According to another aspect of the embodiments of the present invention, a distributed load testing method is further provided, including: receiving a stress testing task and generating a task request based on the stress testing task; allocating test tasks corresponding to the task request to a plurality of load-balanced working nodes of the distributed load testing platform based on task concurrency requirements; and using the working nodes to execute the allocated test tasks and generate test data.

[0007] In an embodiment of the present invention, a stress testing task is received, and a task request is generated based on the stress testing task; based on the task concurrency requirement, the test tasks corresponding to the task request are assigned to multiple load-balanced worker nodes of the distributed load testing platform; the assigned test tasks are executed by the worker nodes to generate test data. Through the above modules. Through the above solution, the technical problems existing in the prior art in aspects such as cluster scheduling, centralized management, test result processing, and real-time monitoring are solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The drawings described herein are used to provide a further understanding of the present invention, and constitute a part of this application. The schematic embodiments of the present invention and their descriptions are used to explain the present invention, and do not constitute an improper limitation of the present invention. In the drawings:

[0009] Figure 1 is an architecture diagram of a distributed load testing system according to an embodiment of the present invention;

[0010] Figure 2 is another architecture diagram of a distributed load testing system according to an embodiment of the present invention;

[0011] Figure 3 is an operation flowchart of a stress testing platform based on JMeter according to an embodiment of the present invention;

[0012] Figure 4 is a flowchart of a method for calculating task load based on a load-based scheduling algorithm according to an embodiment of the present invention;

[0013] Figure 5 shows a schematic structural diagram of an electronic device suitable for implementing the embodiments of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0014] In order to enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0015] It should be noted that the terms "first", "second", etc. in the specification, claims and above-mentioned drawings of the present invention are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present invention described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0016] Figure 1 is an architecture diagram of a distributed load testing system according to an embodiment of the present invention, as Figure 1 shown, the system includes: a user operation interface 12, configured to receive a stress testing task and generate a task request based on the stress testing task; a cluster scheduling module 14, configured to allocate the test task corresponding to the task request to multiple load-balanced worker nodes of the distributed load testing platform based on the task concurrency requirement; a test execution management module 16, configured to use the worker nodes to execute the allocated test task and generate test data.

[0017] In some embodiments, the system further includes a test script management module, configured to centrally manage the test scripts corresponding to the task request, control the version of the test scripts, and edit the test scripts.

[0018] In some embodiments, the test execution management module is further configured to start, pause, and stop the test script through a visualization interface, and dynamically adjust the load parameters of the test script.

[0019] In some embodiments, the cluster scheduling module is further configured to: elastically expand the worker nodes based on the container orchestration platform Kubernetes, calculate the task load based on the load scheduling algorithm, and automatically allocate and recycle the elastically expanded worker nodes according to the task load.

[0020] In some embodiments, the test script management module is further configured to: obtain the version-controlled test script, dynamically adjust the number of concurrent users and the test duration of the test script according to the parameters issued by the cluster scheduling module, and generate the test data; mark the generated test data with a timestamp and a node identifier and send it to the data collection and visualization module.

[0021] In some embodiments, the system further includes an anomaly detection and warning module, which is configured to: perform anomaly detection by using a machine learning model based on time series or a machine learning model based on anomaly point detection; and send a warning message corresponding to the anomaly through an instant messaging tool when an anomaly is detected.

[0022] The platform provided in this embodiment replaces the cumbersome operation of manually maintaining multiple test nodes through an automated node management mechanism, significantly reducing the operation and maintenance complexity; in addition, this platform provides a unified visual control interface to realize the real-time coordination and task scheduling of multiple JMeter instances, getting rid of the decentralized management mode that relies on scripts; finally, this platform is built with an intelligent data aggregation engine that automatically collects, integrates, and analyzes distributed test results, supports the generation of multi-dimensional visual reports, eliminates the inefficient links of manual data processing, and can quickly locate performance bottlenecks and complete optimization iterations.

[0023] The embodiment of the present application also provides another JMeter-based stress testing platform. With the development of Internet applications, system performance and stability are crucial to the user experience. Stress testing is a necessary means to verify the behavior of the system under high load. Currently, the open-source JMeter tool is widely used for performance testing and load testing. However, the existing JMeter has deficiencies in aspects such as cluster scheduling, test management, and result visualization. Especially when performing unified management in a large-scale concurrent scenario, there is a lack of an efficient and flexible stress testing platform. To solve the above problems, the embodiment of the present application provides a JMeter-based stress testing platform, as Figure 2 shown, its core includes the following modules: a cluster scheduling module 14, a test script management module 15, a test execution management module 16, a data collection and visualization module 17, and an anomaly detection and warning module 18.

[0024] 1) Cluster scheduling module.

[0025] The cluster scheduling module is used to manage multiple JMeter nodes through a scheduler. The scheduler distributes tasks to multiple load-balanced JMeter worker nodes based on the concurrent requirements of the tasks to achieve large-scale concurrent requests. The cluster scheduling module adopts efficient resource allocation algorithms, such as Round Robin and load-based scheduling, to ensure the load balance of each node and optimize resource utilization.

[0026] 2) Test script management module.

[0027] The platform provides a centralized test script management function, allowing users to upload, edit, and manage JMeter test scripts. It supports version control to enable testers to easily switch between different test scenarios. The test script management module uses Git as the version control tool to ensure that all change records and version histories are traceable and provides automatic merge and conflict resolution functions.

[0028] 3) Test execution management module.

[0029] Users can start, pause, and stop tests through the platform's visual interface. The execution process includes distributing the deployment script to each JMeter node and dynamically adjusting load parameters during execution. The test execution management module introduces a control interface based on REST API to enable users to automate the management of test execution programmatically.

[0030] 4) Data collection and visualization module.

[0031] The data collection and visualization module is used to collect test data in real time and visually display test results in the form of charts, including response time, success rate, throughput, etc. This embodiment provides various statistical methods, such as percentile analysis, average value, and maximum value, to help users deeply analyze system performance bottlenecks. The data collection module uses Kafka for high-concurrency data transmission to ensure the real-time and reliability of test data under large-scale loads. For visualization, Grafana is used as the front-end display tool to enable users to view test results through customized dashboards.

[0032] 5) Anomaly detection and warning module.

[0033] An anomaly detection mechanism is introduced to identify abnormal fluctuations and trigger warnings by analyzing real-time test data. Warning messages can be notified to relevant personnel through emails or instant messaging tools to respond to system anomalies in a timely manner. The anomaly detection module uses machine learning algorithms, such as time series-based anomaly detection models (such as ARIMA) and outlier detection (such as IsolationForest), to improve the accuracy and precision of detection.

[0034] The operation process of the platform will be described below. As Figure 3 shown, the process includes the following steps:

[0035] Step S302, submit the stress test task.

[0036] When a user submits a stress test task through the platform's Web interface, multi-dimensional configuration is completed in the visual form. The form design adopts a responsive layout to adapt to different terminal devices. The core configuration items include concurrency configuration, resource requirements, and scheduling strategies. In the concurrency configuration section, the user needs to input the number of virtual users (such as 1000 concurrency) and set the ramp-up period (for example, gradually increase to the target concurrency within 60 seconds) to simulate the user traffic growth pattern in a real scenario. The resource requirement configuration allows the user to specify the computing resources required for the test task. For example, dedicated nodes can be selected through labels (such as nodes marked as "high-memory" for memory-intensive tests), or hardware parameters such as the number of CPU cores and memory size can be limited to ensure an accurate match between the task and the node capabilities. The scheduling strategy configuration provides multiple load balancing algorithm options (such as weighted round-robin, least connections, dynamic allocation based on the real-time load of nodes). The user can select the optimal strategy according to the test target. For example, in high-availability tests, selecting the "dynamic load balancing" strategy allows the platform to automatically allocate tasks to the node with the lowest current utilization, avoiding resource hotspots.

[0037] Step S304, send a task request.

[0038] After the user completes filling in the form and clicks the submit button, the front-end encapsulates the form data into a structured JSON request body. Among them, the JMeter test script (.jmx file) is embedded in the request through Base64 encoding to ensure the reliable transmission of binary files. The submit operation triggers a REST API call. The target interface is / api / task / submit of the task allocation module. The interface uses the OAuth 2.0 protocol for identity authentication and encrypts the data transmission through HTTPS to prevent man-in-the-middle attacks. After the backend receives the request, it first performs parameter legality verification (such as whether the concurrency number is a positive integer and whether the script format is compliant). If the verification fails, a 4xx error code and a detailed error description are returned; after the verification passes, the task enters the pending scheduling queue, and a unique task ID is generated and returned to the front-end for the user to track the task status later.

[0039] Step S306, allocate the test task.

[0040] Implement intelligent resource scheduling based on the Kubernetes container orchestration framework. The core logic includes three stages: resource pre-check, dynamic scaling, and task sharding. In the resource pre-check stage, the module uses Prometheus to collect the performance metrics of each JMeter node in the cluster in real time (including CPU utilization, memory occupancy, and network throughput), and filters out a list of candidate nodes that meet the user-specified resource requirements based on node labels. If the current number of available nodes is insufficient to meet the concurrent demand, the dynamic scaling mechanism is triggered: the platform automatically creates new JMeter worker node Pods according to the preset elastic scaling policy (Horizontal Pod Autoscaler) and registers them in the Kubernetes cluster. For example, when the length of the task queue to be processed exceeds the threshold, the HPA controller gradually increases the number of nodes in steps (such as adding 2 Pods each time) until the maximum instance number limit is reached.

[0041] In the task sharding stage, an adaptive sharding algorithm is adopted to split the total concurrency into multiple subtasks according to the node load capacity. The algorithm first calculates the available resource weights of each candidate node (weighted scores based on CPU, memory, and network bandwidth), and then distributes the concurrent threads according to the weight ratio. For example, if the weight of node A is 0.6 and that of node B is 0.4, and the total concurrency is 1000, then node A is assigned 600 threads and node B is assigned 400 threads. After the sharding configuration file is generated, it contains thread group parameters (such as loop count, timeout), target server IP and port information, and is synchronized to the shared storage volume of each node (such as NFS or CephFS) through the GitOps workflow. To ensure the consistency of the script version, the platform forcibly pulls the latest version of the test script from the Git repository before sharding and performs dependency checks (such as the integrity of JMeter plugins and third-party libraries).

[0042] In another embodiment, the method for task allocation can also be as Figure 4 shown, including the following steps:

[0043] Step S3062, maintain load scoring.

[0044] The real-time load status of each node is adjusted by dynamic weight coefficients. For example, when a network-intensive task (such as a large number of HTTP requests) is detected, the weight of the network load weight coefficient is automatically increased; for memory-sensitive tasks (such as big data processing), the weight of the memory utilization weight coefficient is increased. The weight adjustment strategy is dynamically optimized based on the feedback of historical task execution effects (such as task completion time, resource utilization).

[0045] Step S3064, load prediction and elastic pre-scaling.

[0046] Use the LSTM model to analyze the historical metrics of nodes (sampling interval: 1 second) and predict the load changes in the next 3 minutes. The model inputs include the current load of the node, the task queue length, and task type characteristics (such as concurrency, script complexity), and the output is the load level (low / medium / high). If it is predicted that the load of a certain node will reach the threshold within 3 minutes (such as CPU > 80%), the scheduler triggers the scaling operation in advance. At the same time, to avoid over-scaling, a cold node pool mechanism is introduced to pre-start some low-power nodes (CPU frequency limited, memory in sleep state), which can be quickly activated when the predicted load rises, and the cold start time is shortened from 60 seconds to 5 seconds.

[0047] Step S3066, dynamic priority scheduling engine.

[0048] In this embodiment, the task priorities are not statically assigned, but dynamically calculated according to business value and resource requirements. For example, dynamic calculation is performed based on business criticality, pre-release test tasks, and daily inspection tasks. Among them, business criticality: production environment tasks > pre-release test tasks > daily inspection tasks; deadline urgency: the weight of tasks with a deadline less than 30 minutes increases exponentially; resource demand: the higher the required CPU / memory, the lower the priority is appropriately reduced to avoid resource monopoly.

[0049] The scheduler sorts the tasks by Priority and preferentially assigns high-priority tasks to low-load nodes. If resources are insufficient, a task preemption mechanism is triggered: the thread group of low-priority tasks is suspended (save the state to shared storage), and the resources are released for high-priority tasks to use, and it will automatically resume after the resources are idle.

[0050] Step S3068, allocate worker nodes.

[0051] In the filtering stage: exclude nodes that do not meet the hard constraints (such as label mismatch, insufficient resources); in the scoring stage, call the multi-dimensional load scoring model to generate an adaptation score of 0 - 100 for each node; in the binding stage, select the node with the highest score. If the scores are similar (difference < 5), preferentially select the pre-started nodes according to the activation order of the cold node pool. Instead of using the native Kubernetes HPA based on CPU / memory, custom metrics (predicted load, task queue depth) are used to trigger scaling. For example, when the predicted load exceeds 70% of the total cluster capacity, scale out in gradients (the first scale-out is 20%, and each subsequent increase is 10% until the load is balanced); after the node becomes idle, enter a 30-minute observation period. If the load rises above 50% during this period, cancel the scale-in to avoid frequent oscillations.

[0052] In some other embodiments, during the filtering phase, in addition to excluding nodes that do not meet the hard constraints (such as label mismatch, insufficient resources), task fitness calculation is introduced, and a dynamic constraint matching mechanism based on task characteristics is adopted. Filtering is performed based on the fitness between the task type (CPU-intensive, memory-intensive, IO-intensive) and the node hardware architecture (such as NUMA architecture, GPU support, RDMA network). During the scoring phase, an improved multi-dimensional load scoring model is called, task migration overhead prediction (such as data locality, cross-node communication latency) is introduced, and the load stability (such as the load volatility in the past 5 minutes) is combined to generate a fitness score from 0 to 100. If the load volatility of the candidate node is too high (such as the fluctuation exceeding 30% in the past 5 minutes), even if the current load is low, the fitness score will be reduced, and nodes with more stable loads will be preferentially selected. During the binding phase, when the scores of multiple nodes are close (the difference < 5), not only are pre-started nodes preferentially selected in the order of cold node pool activation, but also a task clustering scheduling strategy is introduced. Based on task dependencies and data sharing situations, highly correlated tasks are scheduled into the same data center or the same node group with high-bandwidth interconnection to reduce the cross-node data transmission overhead.

[0053] When multiple low-priority tasks are distributed across multiple low-load nodes, a task aggregation strategy is adopted. Based on the computational dependencies and resource similarities of the tasks, they are migrated to the same node to release idle nodes, and an intelligent node sleep mechanism is combined (when the predicted load in the next 10 minutes is lower than 30%, the CPU frequency is automatically reduced and the low-power mode is entered). Moreover, when multiple low-priority tasks are distributed across multiple low-load nodes, the scheduler migrates them to the same node and releases idle nodes; and non-production tasks are allowed to oversubscribe node resources (such as the CPU oversubscription ratio ≤ 30%), but the resource contention situation is monitored in real time. Once the threshold is triggered (such as CPU Steal Time > 15%), the oversubscribed tasks are immediately isolated.

[0054] In addition, the scheduler combines an adaptive scaling strategy. When the predicted load of the cluster exceeds 70%, the first expansion amplitude is dynamically adjusted according to the task type (such as a 30% priority expansion for compute-intensive tasks and a 20% expansion for storage-intensive tasks). For non-production tasks, intelligent resource oversubscription is allowed (such as the CPU oversubscription ratio ≤ 30%), but a resource contention feedback mechanism is introduced to dynamically adjust the oversubscription ratio based on historical resource competition situations.

[0055] Compared with the prior art, the present method has the following beneficial effects: 1) Predictive scaling: Different from passive reactive scaling, this method anticipates load changes in advance and reduces task execution latency; 2) Existing solutions only support task queuing, and the present invention allows resource preemption and saves task states, shortening the completion time of urgent tasks; 3) Compared with the traditional "full standby" scheme, this method reduces the consumption of idle resources through the cold node pool.

[0056] Through multi-dimensional load prediction, dynamic priority decision-making, and deep Kubernetes integration, this method has achieved a technological improvement from "passive response" to "active optimization". Its core innovation lies in the integration of machine learning, reinforcement learning, and traditional scheduling logic, constructing an adaptive and forward-looking resource management system. Compared with existing technologies, this solution has achieved breakthrough improvements in resource utilization, task response speed, and system stability.

[0057] Step S308: Generate test data.

[0058] After receiving a test task, the JMeter master node (Master) starts the distributed test execution process. Each worker node initializes the thread group according to the configuration and binds the network endpoints of the target server. During the test, the node uses parameterized injection technology to load the CSV data file from the shared storage, and distributes the test data to each thread row by row to achieve data-driven testing. For example, in the scenario of simulating user login, different user account and password combinations are stored in the CSV file, and the threads read and execute the login requests in sequence to avoid biases caused by duplicate test data.

[0059] The real-time collection of test data is achieved through the JMeter Backend Listener extension. This extension serializes the execution results of the sampler (including response time, status code, request size) into JSON format and asynchronously pushes them to the message queue through the Kafka producer. To cope with data peaks in high-concurrency scenarios, the Kafka cluster adopts a partition replication mechanism. Each topic is divided into multiple partitions (such as hashed and assigned by node ID), and the replication factor is set to 3 to ensure data persistence and high availability. At the same time, the producer side enables compression algorithms (such as Snappy) and batch submission strategies, significantly reducing network bandwidth consumption and IO pressure.

[0060] Step S310: Transmit and visualize the test data.

[0061] The data collection module uses a layered architecture to process massive test data. The real-time stream processing layer is built on Apache Flink. After consuming the raw data in Kafka, it performs data cleaning (such as filtering heartbeat packets, repairing out-of-order events), field standardization (unifying timestamp format, filling missing values) and real-time aggregation (calculating TPS, average response time, error rate and other indicators based on a 1-second window). The cleaned data is written to the Elasticsearch cluster, and the index is sharded by task ID and time range to support fast retrieval and multi-dimensional aggregation queries. The offline batch processing layer uses Spark to regularly scan the original log files in HDFS to perform long-term trend analysis (such as weekly peak performance comparison) and root cause location (such as associating error logs with system monitoring indicators).

[0062] The visualization module uses Grafana to display interactive data. The pre-set dashboard contains multiple view components: 1) Real-time monitoring view: The line chart dynamically displays the TPS and response time curves, and the heat map shows the error distribution density of each API endpoint; 2) Resource utilization view: The stacked area chart shows the CPU, memory and network usage of the JMeter node, assisting operation and maintenance personnel to identify resource bottlenecks; 3) Root cause analysis panel: When the user clicks on an abnormal data point, the associated slow query log, thread stack trace and system monitoring snapshot are displayed in a linked manner. 4) The early warning subsystem integrates a lightweight machine learning model to detect anomalies in time series data in Elasticsearch. The model uses the Isolation Forest algorithm to calculate the anomaly score of the data point in real time and trigger an alarm when the score exceeds the threshold. The alarm information is pushed through multiple channels (email, DingTalk robot, SMS), and comes with repair suggestions (such as "The database connection pool is exhausted and it is recommended to expand to 50 connections").

[0063] The distributed stress testing platform based on JMeter provided in this embodiment covers the entire link of task submission, resource scheduling, test execution, data processing and visualization. Through innovative designs such as Kubernetes elastic architecture, real-time stream processing engine and AI enhanced detection, it effectively solves the shortcomings of traditional stress testing tools in cluster management, real-time monitoring and automation, has a high degree of technological advancement and commercial feasibility, and provides a standardized, enterprise-level solution for distributed system performance assurance.

[0064] Figure 5 FIG. 1 shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present disclosure. It should be noted that: Figure 5 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0065] like Figure 5As shown, the electronic device includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1002 or the program loaded from the storage section 1008 into the random access memory (RAM) 1003. In the RAM 1003, various programs and data required for system operation are also stored. The CPU 1001, ROM 1002, and RAM 1003 are connected to each other via a bus 1004. The input / output (I / O) interface 1005 is also connected to the bus 1004.

[0066] The following components are connected to the I / O interface 1005: an input section 1006 including a keyboard, a mouse, etc.; an output section 1007 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, a modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as required. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1010 as required so that a computer program read from it can be installed into the storage section 1008 as required.

[0067] The above description is only the preferred embodiment of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A distributed load testing system, characterized in that, including: a user operation interface, configured to receive a stress testing task and generate a task request based on the stress testing task; a cluster scheduling module, configured to allocate test tasks corresponding to the task request to multiple load-balanced worker nodes of the distributed load testing platform based on task concurrency requirements; a test execution management module, configured to execute the allocated test tasks by using the worker nodes and generate test data.

2. The system according to claim 1, wherein The system further includes a test script management module, configured to centrally manage test scripts corresponding to the task request, control the versions of the test scripts, and edit the test scripts.

3. The system according to claim 2, wherein The test execution management module is further configured to start, pause, and stop the test script through a visualization interface and dynamically adjust load parameters of the test script.

4. The system according to claim 1, characterized in that, The cluster scheduling module is further configured to: elastically expand the worker nodes based on a container orchestration platform, calculate task loads based on a load scheduling algorithm, and automatically allocate and recycle the elastically expanded worker nodes according to the task loads.

5. The system according to claim 2, wherein The test script management module is further configured to: obtain a version-controlled test script, dynamically adjust the number of concurrent users and test duration of the test script according to parameters issued by the cluster scheduling module, and generate the test data; mark the generated test data with a timestamp and a node identifier and send it to a data collection and visualization module.

6. The system according to claim 1, wherein further including an anomaly detection and warning module, configured to: perform anomaly detection by using a machine learning model based on time series or a machine learning model based on anomaly point detection; in the case of detecting an anomaly, send a warning message corresponding to the anomaly through an instant messaging tool.

7. A distributed load testing method, characterized in that, including: receiving a stress testing task and generating a task request based on the stress testing task; allocating test tasks corresponding to the task request to multiple load-balanced worker nodes of the distributed load testing platform based on task concurrency requirements; executing the allocated test tasks by using the worker nodes and generating test data.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein when the program runs, it controls the device where the computer-readable storage medium is located to execute the method according to any one of claims 1 to 6.

9. A computer device, characterized in that, including: a memory and a processor, wherein the memory stores a computer program; the processor is configured to execute the computer program stored in the memory, and when the computer program runs, it causes the processor to execute the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 6.

Images