Distributed pressure measurement method and system based on container technology

Abstract

The invention discloses a distributed pressure measurement method and system based on a container technology, and the method comprises the steps: transmitting an upstream pressure measurement task, generating and assembling a pressure measurement script, distributing the pressure measurement script to a designated independent host cluster docker container, starting a jmeter mirror image analysis script, transmitting pressure measurement metadata back to middleware, and combining the message of the middleware with a downstream calculation module. Real-time performance test report checking is provided, and the problems that an existing pressure measurement tool is high in cost and complex in deployment, pressure measurement equipment is large in demand quantity and cannot be reused, and pressure measurement monitoring is manual are effectively solved.

Description

Technical Field

[0001] This invention relates to the field of computer testing technology, and in particular to a distributed load testing method and system based on container technology. Background Technology

[0002] Current performance testing tools mainly suffer from the following problems:

[0003] I. Traditional load testing tools have low concurrency:

[0004] Traditional tools have extremely high requirements for machine configuration during stress testing, and often encounter memory overflow, port conflicts and remote interface problems, making it impossible to achieve high-standard concurrency and thus unable to simulate high-concurrency scenarios in production environments.

[0005] II. The load testing tool cannot fix the QPS load test:

[0006] Currently, traditional tools can only select a fixed number of threads for distributed load testing. However, the load generated by the load testing service model that controls the number of threads is unstable and cannot truly simulate the actual online situation. In contrast, by controlling QPS, the load can be increased in stages to evaluate the system's performance under different loads.

[0007] 3. Load testing deployment requires manual deployment:

[0008] Existing tools typically require manual writing and configuration of performance test scripts, as well as manual deployment of physical load testing machines. This process is time-consuming and error-prone, making it difficult to meet complex testing needs.

[0009] IV. Low level of automation:

[0010] Existing tools lack sufficient automation support for test scenario management, real-time result viewing, and report generation. Testers typically need to manually intervene in generating test reports and analyzing results, increasing their workload and potentially affecting the timeliness and accuracy of the reports.

[0011] 5. Inflexible load testing configuration:

[0012] The existing system is not flexible enough in supporting complex testing scenarios and multi-stage load testing, and cannot meet the needs of dynamic configuration and different load modes.

[0013] VI. Existing tools have limited functionality in load testing notifications and report sharing, making it difficult for users to efficiently manage test notifications and quickly share reports. Summary of the Invention

[0014] In view of this, the present invention provides a distributed load testing method and system based on container technology. The method generates and assembles load testing scripts by issuing load testing tasks from upstream, distributes them to Docker containers in a designated independent host cluster, starts the JMeter image parsing script, and sends load testing metadata back to the middleware. Combined with messages from the middleware and downstream computing modules, the method provides real-time performance test reports.

[0015] This invention supports distributed load testing of thousands, tens of thousands, or even hundreds of thousands of requests per second with limited load testing machine resources, and supports fixed QPS gradient load application capabilities, compatible with multiple thread types. The platform provides automated testing and load testing functions, supports real-time monitoring of load testing reports, helps enterprises comprehensively improve the load testing efficiency of testers, realize the accumulation and sharing of digital assets, lower the threshold for performance testing, save hardware resource costs of load testing machines, and quickly achieve intelligent upgrades.

[0016] A distributed load testing method based on container technology includes the following steps:

[0017] S1 receives load testing tasks from upstream:

[0018] S2, users import load test data and set load test performance parameters, which are stored in the database as a JSON array;

[0019] S3, based on the set load test performance parameters, dynamically concatenates the element attributes of the original base XML load test file of the load test data to obtain a new XML file;

[0020] S4. Based on the pressure estimate of each press, the CSV file of the pressure test data is proportionally divided, and the divided CSV files are assembled with the new XML file to obtain the pressure test script that can be executed by each press.

[0021] S5 builds image containers within the Docker container of each stress machine;

[0022] S6, the test scripts that each pressure machine can execute are transmitted to their respective pressure machines. After each pressure machine executes the test scripts synchronously, it sends the test metadata back to the distributed test system in real time.

[0023] S7, the distributed load testing system generates load testing reports based on the received load testing metadata.

[0024] Preferably, the specific steps for the user to import the stress test data in step S2 are as follows:

[0025] Users can select a method for importing load test data, which includes local import and platform automatic import.

[0026] If the user selects the local import method for load testing data, the load testing data stored locally will be uploaded to the distributed load testing system.

[0027] If the user selects the platform's automatic import method for load testing data, the user can directly edit the load testing data online in the automated testing scenario of the distributed load testing system;

[0028] The distributed load testing system parses the load testing data and automatically configures the performance load testing scenario.

[0029] Preferably, the specific steps in step S3 to dynamically concatenate the element attributes of the original base XML load test file based on the set load test performance parameters to obtain a new XML file are as follows:

[0030] Based on the step number in the set stress test performance parameters, generate n collectionProp child node elements with different names, and obtain the target TPS corresponding to each collectionProp child node element;

[0031] Calculate the time value of each single step by using the total step time and number of steps in the set pressure test performance parameters;

[0032] Replace the corresponding parameters in the original base XML load test file with the target TPS, single-step time value, and set load test performance parameters corresponding to each collectionProp child node element to obtain a new XML file.

[0033] Preferably, the stress test performance parameters include the number of tiered threads, QPS, number of tiers, total tier time, tag attributes, and number of stress testers;

[0034] The tag attributes include guiclass, testclass, TargetLevel, and VariableThroughputTimer.

[0035] Preferably, the specific steps for building the image container within the Docker container of each pressure machine in step S5 are as follows:

[0036] Add Docker build scripts and shell scripts to the press;

[0037] Download the JMeter container, port the JMeter container to the Docker container of the load tester, and integrate the JMeter Backend Listener Kafka plugin.

[0038] Preferably, a Docker container can contain multiple JMeter containers. The number of JMeter containers depends on the type of load testing task, but a JMeter container can only execute the load testing script for one load testing task at a time.

[0039] Preferably, when a new pressure machine needs to be deployed, the image container in the currently deployed pressure machine can be directly ported.

[0040] Preferably, the specific steps for each press to synchronously execute the pressure test script in step S6 are as follows:

[0041] The distributed load testing system transmits the load testing scripts executable by each load tester to each load tester according to the IP address and sequence number of the load tester.

[0042] After each load tester receives an executable load test script, it executes the script and, after the load test is completed, sends the load test metadata back to the JMeter Backend Listener Kafka plugin in real time.

[0043] The JMeter Backend Listener Kafka plugin transmits load testing metadata, excluding JTL files, to the distributed load testing system.

[0044] Preferably, the specific steps in step S7 where the distributed load testing system generates a load testing report based on the received load testing metadata are as follows:

[0045] The distributed load testing system stores the Timestamp and SampleLabel data from the load testing metadata it receives in a local array in the database, grouped by second, and calculates performance metrics.

[0046] The system automatically generates load testing reports based on data stored in the database. The load testing reports include test results, performance metrics, and analysis data. The table structure of the load testing reports is indexed by the load testing timestamp and the report ID.

[0047] A distributed load testing system based on container technology includes a task distribution module, a load testing script import module, an automated test case management module, a performance load testing configuration module, a load testing script generation module, a performance testing module, a data collection module, and a load testing report generation module.

[0048] The task distribution module is used to receive load testing tasks from upstream and transmit the load testing tasks to the performance testing module;

[0049] The load testing script import module is used to import load testing data according to the load testing data import method selected by the user and transmit the load testing data to the automated test case management module.

[0050] The automated test case management module is used to manage and execute automated test scenarios, parse load test data, and automatically configure performance load test scenarios;

[0051] The performance test configuration module is used to configure the test performance parameters and store the test performance parameters in the database in the form of a JSON array.

[0052] The load testing script generation module is used to dynamically concatenate the element attributes of the original base XML load testing file of the load testing data according to the set load testing performance parameters to obtain a new XML file; then, according to the pressure estimate of each pressure machine, the CSV file of the load testing data is proportionally cut, and the cut CSV files are assembled with the new XML file to obtain the load testing script that can be executed by each pressure machine.

[0053] The performance testing module is used to start the Docker container of the relevant stress machine according to the stress test task ID it receives. At the same time, the relevant stress machine will send a stress test script download request to the stress test script generation module. After receiving the download request instruction, the stress test script generation module will transmit the corresponding executable stress test script to each stress machine according to the IP and sequence number of each stress machine.

[0054] The data collection module is used to acquire pressure test metadata from each press in real time, and to group and store the Timestamp and SampleLabel in the received pressure test metadata in a local array of the database with a granularity of seconds, and to calculate the performance index of the database.

[0055] The stress test report generation module is used to automatically generate stress test reports based on the data stored in the database.

[0056] The beneficial effects of this invention are:

[0057] 1. This invention distributes load testing tasks from upstream, generates and assembles load testing scripts, and distributes them to designated independent host cluster Docker containers. It then starts the JMeter image parsing script, sends load testing metadata back to middleware, and combines middleware messages with downstream computing modules to provide real-time performance test reports. This effectively solves the problems of high cost, complex deployment, large and non-reusable load testing equipment requirements, and manual load testing monitoring in current load testing tools. This invention can support continuous distributed load testing of thousands, tens of thousands, or even hundreds of thousands of requests with limited load testing machine resources, maximizing machine resource utilization and achieving high-standard concurrency to simulate high-concurrency scenarios in production environments. It also supports fixed QPS gradient load application, is compatible with multiple thread types, significantly improves the efficiency and accuracy of performance testing, reduces manual operation and human error, supports complex testing requirements, and enhances the timeliness of information transmission through convenient notification and report sharing functions, improving user experience and making the performance testing process more efficient, reliable, and easy to operate.

[0058] 2. The distributed load testing platform of this invention provides automated testing and load testing functions, supports real-time monitoring of load testing reports, helps enterprises comprehensively improve the load testing efficiency of testers, realizes the accumulation and sharing of digital assets, lowers the threshold for performance testing, saves hardware resource costs of load testing machines, and quickly realizes intelligent upgrades.

[0059] 3. This invention can dynamically expand or shrink the press resources according to the load requirements of the load test. When the load test task requires more load test resources, the platform can automatically adjust to meet the demand, without causing task failure or delay due to insufficient resources.

[0060] 4. The stress tester of this invention, based on existing JMeter functionality, specifically adds Docker build scripts and shell scripts to manage the download, execution, and result processing of stress test scripts. This enables horizontal scaling of multi-node containers for stress testing, avoiding resource limitations of the master machine and maximizing concurrency. Finally, the entire process is built into an image. When a new stress tester needs to be deployed, simply migrate this image to the new stress tester. It supports selecting multiple stress testers for distributed stress testing while ensuring the recycling and reuse of stress tester resources. It can more realistically simulate system performance under different load conditions and allows pressure to be applied simultaneously on different nodes, improving test coverage and realism to meet complex testing needs. Furthermore, the lightweight deployment of the stress tester allows all stress testers to be centrally managed on the distributed stress testing platform, eliminating the need for tedious and complex manual deployment steps. Manually deploying a distributed stress tester requires at least one to two hours of configuration and debugging, significantly improving the deployment efficiency of the stress tester.

[0061] 5. This invention supports fixed and tiered QPS control, providing a tiered load testing function. Users can gradually increase the load to evaluate the system's performance under different loads. It is compatible with multiple thread types and supports concurrent load testing in mixed scenarios, benchmarking industry leaders.

[0062] 6. The report data of this invention is returned in seconds with a difference of <=3%; the granularity of report data acquisition is adjustable in 6 levels, and it can support data access at the highest level of 1 second; the pressure flow and concurrency are displayed in real time; the entire pressure process RT: real-time calculation and display of p95, p99, and p999, while ensuring the professionalism and readability of the report. The generated report can also be automatically sent to relevant personnel through the notification function, and the report can be viewed, downloaded and shared. Attached Figure Description

[0063] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0064] Figure 1 This is a system architecture diagram of the distributed load testing system of this invention.

[0065] Figure 2 This is a flowchart of the distributed load testing method of the present invention. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this invention clearer, the invention is described below with reference to specific embodiments shown in the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0067] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0068] In the following description, the use of suffixes such as "module" or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module" and "unit" may be used interchangeably.

[0069] To better understand the technical solution of the present invention, the present invention will be described in detail below with reference to the accompanying drawings.

[0070] This invention provides a distributed load testing method based on container technology, which specifically includes the following steps:

[0071] S1 receives load testing tasks from upstream.

[0072] Each load testing task has a unique task ID.

[0073] S2 allows users to import load testing data and set load testing performance parameters, which are stored in the database as a JSON array.

[0074] Specifically, the user selects the load test data import method, which includes local import method and platform automatic import method;

[0075] If the user selects the local import method for load testing data, the user will upload the load testing data stored locally to the distributed load testing system. The distributed load testing system will parse the load testing data and automatically configure the performance load testing scenario.

[0076] If the user selects the platform's automatic import method for load testing data, the user needs to create, select, or reference a predefined automated test scenario and edit the load testing data online within that scenario. The distributed load testing system parses the load testing data and automatically converts it into a performance load testing scenario, without requiring manual configuration.

[0077] The load testing data includes JMeter scripts and related resource files, such as original basic XML load testing files and CSV files. After the load testing files are imported into the distributed load testing system, these files are stored in a database (such as a file server) and can be referenced or downloaded at any time; different scripts can share the same files.

[0078] Meanwhile, users configure load testing performance parameters according to the load testing task, and these parameters are stored in the database as a JSON array. These performance parameters include the number of tiered threads, QPS, number of tiers, total tier time, tag attributes, and number of load testing machines; tag attributes include guiclass, testclass, TargetLevel, and VariableThroughputTimer.

[0079] guiclass refers to the graphical user interface class name;

[0080] testclass refers to the backend logic processing responsible for executing the actual tests;

[0081] TargetLevel refers to the target concurrency level for each load testing phase;

[0082] VariableThroughputTimer refers to a timer that controls the change in requests per second (TPS).

[0083] S3 dynamically concatenates the element attributes of the original base XML load test file based on the set load test performance parameters to obtain a new XML file.

[0084] Specifically, based on the number of steps in the set load testing performance parameters, n uniquely named collectionProp child node elements are generated, and the target TPS corresponding to each collectionProp child node element is obtained. That is, assuming the number of steps in the load testing performance parameters set by the user is n, the load testing is divided into n stages, each stage has a unique number and name, i.e., n collectionProp child node elements. At the same time, the target throughput (TPS) corresponding to each stage is calculated. Assuming the user sets a 3-step load testing model, the load testing is divided into 3 stages. For example, the first stage runs 100 users, the second stage runs 200 users, and the third stage runs 300 users. Then, 3 collectionProp child node elements step_1, step_2, and step_3 can be obtained, and the value (target TPS) corresponding to each collectionProp child node element is 100, 200, and 300, respectively.

[0085] The time value of each single step is calculated by using the total step time and number of steps in the set stress test performance parameters. Assuming that the entire stress test lasts for a total of 6 minutes and the user sets a 3-step stress test model, the stress test is divided into 3 stages, and the time value of each single step is 2 minutes.

[0086] Replace the corresponding parameters in the original base XML load test file with the target TPS and single-step time values, and the tag attributes guiclass, testclass, TargetLevel, and VariableThroughputTimer in the set load test performance parameters of each collectionProp child node element to obtain a new XML file.

[0087] S4 assembles the new XML file with the original CSV file imported by the user to obtain the pressure testing script that the pressure machine can execute.

[0088] Specifically, if a single press machine is used for pressure testing, the new XML file is assembled with the original CSV file in the pressure testing data imported by the user to obtain the pressure testing script that the press machine can execute.

[0089] If multiple presses are used for simultaneous pressure testing, the CSV file of the pressure test data is first divided proportionally according to the pressure forecast of each press. For example, if three presses are used and the pressure forecasts of the three presses are equal, the CSV file is divided into three equal segments. If the pressure forecasts of the three presses are different, the CSV file is divided proportionally according to the ratio of the pressure forecasts of the three presses. The divided CSV files are then assembled with the new XML file to obtain the pressure test scripts that can be executed by each press.

[0090] Each executable pressure test script for a given press carries its corresponding press's IP address and serial number.

[0091] S5 builds image containers within a Docker container on each stress tester.

[0092] Specifically, firstly, Docker build scripts and shell scripts are added to the pressure machine;

[0093] Next, download the JMeter container, port the JMeter container into the Docker container of the stress tester, and integrate the JMeter backend listener Kafka plugin.

[0094] A single Docker container can contain multiple JMeter containers. The number of JMeter containers depends on the type of load testing task. Each JMeter container can only execute the load testing script for one load testing task at a time.

[0095] Preferably, when a new pressure machine needs to be deployed, the image container in the currently deployed pressure machine can be directly transplanted, which supports the selection of multiple pressure machines for distributed load testing, while ensuring the recycling and reuse of pressure machine resources.

[0096] S6: The executable test scripts of each pressure machine are transmitted to their respective pressure machines. After each pressure machine executes the test script synchronously, it sends the test metadata back to the distributed test system in real time.

[0097] Specifically, after the image container of the stress tester is built, the stress test task is started, and the distributed stress test system starts the Docker container of the corresponding stress tester according to the stress test task ID;

[0098] After receiving the start command, the Docker container of the stress tester sends a download request to the distributed stress testing system;

[0099] The distributed load testing system retrieves the executable load testing scripts for each load tester from the database (the load testing scripts obtained in step S4) based on the received download request, and transmits the executable load testing scripts for each load tester to its respective load tester according to the IP address and sequence number of each load tester.

[0100] After receiving the executable load test script, each load tester executes the script using the Linux command to perform the load test. After the load test is completed, the load test metadata is transmitted to its JMeter backend listener Kafka plugin in real time.

[0101] The distributed load testing system monitors the JMeter backend listener Kafka plugin in real time and retrieves load testing metadata from it. Once the metadata is obtained, the system discards the original JMeter JTL file and groups the Timestamp and SampleLabel data into a local array CopyOnWriteArrayList in the database. The Timestamp and SampleLabel data can be stored in the database every 10 or 30 seconds. The system can then use the load testing metadata in the database to calculate performance metrics such as requests per second, response time, and bandwidth.

[0102] S7, the distributed load testing system generates load testing reports based on the received load testing metadata.

[0103] The distributed load testing system provides real-time monitoring, allowing users to view test results, performance metrics (requests per second, response time, bandwidth, etc.) and analysis data during the load testing process. The table structure is indexed by the load testing timestamp and report ID. Even with tens of millions of data points, queries are completed within seconds without table or database sharding. The report data granularity is adjustable to six levels, supporting data access up to 1 second. Based on the granularity and time interval, p95, p99, and p999 are calculated in real-time and displayed intuitively in charts.

[0104] Because the load testing metadata is very large when the concurrency is too high, it will consume a lot of resources. Therefore, in order to ensure the accuracy of the data, this application stores the load testing metadata in seconds. The table data resources are not affected by the QPS size. Even if the QPS is hundreds of thousands or even millions, the data is stored in the time unit. The database table data is always stored only once per second of QPS, which greatly saves the consumption of resources.

[0105] This invention also provides a distributed load testing system based on container technology, including a task distribution module, a load testing script import module, an automated test case management module, a performance load testing configuration module, a load testing script generation module, a performance testing module, a data collection module, and a load testing report generation module.

[0106] The task distribution module is used to receive load testing tasks from upstream and transmit the load testing tasks to the performance testing module.

[0107] The load testing script import module is used to import load testing data according to the load testing data import method selected by the user and transmit the load testing data to the automated test case management module. There are two load testing data import methods: importing JMeter scripts and related resource files from the local machine, or referencing automated test scenarios in the platform and editing load testing data online in the automated test scenario.

[0108] The automated test case management module manages and executes automated test scenarios, allowing users to create, select, or reference predefined automated test scenarios. After parsing the load testing data, it automatically converts these automated test scenarios into performance load testing scenarios. The referencing and conversion functions of automated test scenarios provide users with flexible configuration options, reducing the workload of manual configuration. It also supports modifying advanced performance metric parameters, further simplifying the complexity of load testing scripts.

[0109] The performance test configuration module is used to configure the test performance parameters and store them in the database as a JSON array. The test performance parameters include the number of tiered threads, QPS, number of tiers, total tier time, tag attributes, and number of test machines. The tag attributes include guiclass, testclass, TargetLevel, and VariableThroughputTimer.

[0110] The load testing script generation module is used to dynamically concatenate the element attributes of the original base XML load testing file of the load testing data according to the set load testing performance parameters to obtain a new XML file; then, according to the pressure estimate of each press, the CSV file of the load testing data is proportionally cut, and the cut CSV files are assembled with the new XML file to obtain the load testing script that can be executed by each press.

[0111] The performance testing module is used to start the Docker container of the relevant stress machine according to the stress test task ID it receives. At the same time, the relevant stress machine will send a stress test script download request to the stress test script generation module. After receiving the download request instruction, the stress test script generation module will transmit the corresponding executable stress test script to each stress machine according to the IP and sequence number of each stress machine.

[0112] The data collection module is used to acquire pressure test metadata from each press in real time, and to group and store the Timestamp and SampleLabel in the received pressure test metadata in a local array in the database with a granularity of seconds, and to calculate the performance index of the database.

[0113] The stress test report generation module is used to automatically generate stress test reports based on the data stored in the database.

[0114] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A distributed load testing method based on container technology, characterized in that, Specifically, the following steps are included: S1 receives load testing tasks from upstream: S2, users import load test data and set load test performance parameters, which are stored in the database as a JSON array; S3, based on the set load test performance parameters, dynamically concatenates the element attributes of the original base XML load test file of the load test data to obtain a new XML file; S4. Based on the pressure estimate of each press, the CSV file of the pressure test data is proportionally divided, and the divided CSV files are assembled with the new XML file to obtain the pressure test script that can be executed by each press. S5 builds image containers within the Docker container of each stress tester; S6, the test scripts that each pressure machine can execute are transmitted to their respective pressure machines. After each pressure machine executes the test scripts synchronously, it sends the test metadata back to the distributed test system in real time. S7, the distributed load testing system generates load testing reports based on the received load testing metadata.

2. The distributed load testing method based on container technology according to claim 1, characterized in that, The specific steps for users to import load test data in step S2 are as follows: Users can select a method for importing load test data, which includes local import and platform automatic import. If the user selects the local import method for load testing data, the load testing data stored locally will be uploaded to the distributed load testing system. If the user selects the platform's automatic import method for load testing data, the user can directly edit the load testing data online in the automated testing scenario of the distributed load testing system; The distributed load testing system parses the load testing data and automatically configures the performance load testing scenario.

3. The distributed load testing method based on container technology according to claim 1, characterized in that, In step S3, based on the set load test performance parameters, the element attributes of the original base XML load test file are dynamically concatenated to obtain a new XML file. The specific steps are as follows: Based on the step number in the set stress test performance parameters, generate n collectionProp child node elements with different names, and obtain the target TPS corresponding to each collectionProp child node element; Calculate the time value of each single step by using the total step time and number of steps in the set pressure test performance parameters; Replace the corresponding parameters in the original base XML load test file with the target TPS, single-step time value, and set load test performance parameters corresponding to each collectionProp child node element to obtain a new XML file.

4. The distributed load testing method based on container technology according to claim 3, characterized in that, The stress test performance parameters include the number of tiered threads, QPS, number of tiers, total tier time, tag attributes, and number of stress testers; The tag attributes include guiclass, testclass, TargetLevel, and VariableThroughputTimer.

5. The distributed load testing method based on container technology according to claim 1, characterized in that, The specific steps for building the image container within the Docker container on each stress machine in step S5 are as follows: Add Docker build scripts and shell scripts to the press; Download the JMeter container, port the JMeter container to the Docker container of the load tester, and integrate the JMeter Backend Listener Kafka plugin.

6. The distributed load testing method based on container technology according to claim 5, characterized in that, A Docker container can contain multiple JMeter containers. The number of JMeter containers depends on the type of load testing task, but a JMeter container can only execute the load testing script for one load testing task at a time.

7. The distributed load testing method based on container technology according to claim 1, characterized in that, When a new pressure machine needs to be deployed, the image container in the currently deployed pressure machine can be directly ported.

8. The distributed load testing method based on container technology according to claim 1, characterized in that, The specific steps for each press to synchronously execute the pressure test script in step S6 are as follows: The distributed load testing system transmits the load testing scripts executable by each load tester to each load tester according to the IP address and sequence number of the load tester. After each load tester receives an executable load test script, it executes the script and, after the load test is completed, sends the load test metadata back to the JMeter Backend Listener Kafka plugin in real time. The JMeter Backend Listener Kafka plugin transmits load testing metadata, excluding JTL files, to the distributed load testing system.

9. The distributed load testing method based on container technology according to claim 1, characterized in that, In step S7, the distributed load testing system generates a load testing report based on the received load testing metadata. The specific steps are as follows: The distributed load testing system stores the Timestamp and SampleLabel data from the load testing metadata it receives in a local array in the database, grouped by second, and calculates performance metrics. The system automatically generates load testing reports based on data stored in the database. The load testing reports include test results, performance metrics, and analysis data. The table structure of the load testing reports is indexed by the load testing timestamp and the report ID.

10. A distributed load testing system based on container technology, characterized in that, It includes a task distribution module, a load testing script import module, an automated test case management module, a performance load testing configuration module, a load testing script generation module, a performance testing module, a data collection module, and a load testing report generation module; The task distribution module is used to receive load testing tasks from upstream and transmit the load testing tasks to the performance testing module; The load testing script import module is used to import load testing data according to the load testing data import method selected by the user and transmit the load testing data to the automated test case management module. The automated test case management module is used to manage and execute automated test scenarios, parse load test data, and automatically configure performance load test scenarios; The performance test configuration module is used to configure the test performance parameters and store the test performance parameters in the database in the form of a JSON array. The load testing script generation module is used to dynamically concatenate the element attributes of the original base XML load testing file of the load testing data according to the set load testing performance parameters to obtain a new XML file; then, according to the pressure estimate of each pressure machine, the CSV file of the load testing data is proportionally cut, and the cut CSV files are assembled with the new XML file to obtain the load testing script that can be executed by each pressure machine. The performance testing module is used to start the Docker container of the relevant stress machine according to the stress test task ID it receives. At the same time, the relevant stress machine will send a stress test script download request to the stress test script generation module. After receiving the download request instruction, the stress test script generation module will transmit the corresponding executable stress test script to each stress machine according to the IP and sequence number of each stress machine. The data collection module is used to acquire pressure test metadata from each press in real time, and to group and store the Timestamp and SampleLabel in the received pressure test metadata in a local array of the database with a granularity of seconds, and to calculate the performance index of the database. The stress test report generation module is used to automatically generate stress test reports based on the data stored in the database.

Images