Double-engine distributed performance testing method and system

Abstract

The invention discloses a double-engine distributed performance testing method and system. The method comprises a test node service, a Kafka message queue, a data processing service, a data storage service, a registration center and a platform management module, supports JMeter and Locust double test engines, adopts a distributed architecture and containerized deployment, and realizes scheduling of test tasks, real-time data processing, log acquisition and unified management. The method is suitable for enterprise-level performance test scenes, and has high expansibility, usability and real-time performance.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a dual-engine distributed performance testing method and system. Background Technology

[0002] As software systems become increasingly complex, performance testing has become a crucial element in ensuring system stability and scalability. While existing performance testing tools such as JMeter and Locust are powerful, they have shortcomings in distributed deployment, resource management, real-time test data processing, and log collection, especially in large-scale concurrent testing scenarios, where the real-time performance of test results and system manageability are poor. Summary of the Invention

[0003] Based on this, embodiments of this application provide a dual-engine distributed performance testing method and system to solve problems such as inconvenient resource management, poor real-time performance of test data, and insufficient system scalability in the prior art.

[0004] Firstly, a dual-engine distributed performance testing method is provided, which includes:

[0005] S1. When creating a test task, generate a globally unique task ID for the task, write the user-uploaded JMeter or Locust script along with the concurrency, loop count, and target address parameters into the data storage service, and register the task ID and the required number of nodes with the registry center to form the sole basis for subsequent scheduling.

[0006] S2, the platform obtains a list of available test node services from the registration center based on the task ID, and sends the script and parameters to the selected node. The node simultaneously starts the JMeter and Locust dual engines, performs tests on the target system according to the concurrency and loop count, and generates test results and logs in real time.

[0007] S3, the test node service encapsulates the test results and logs of the same task ID into messages and continuously pushes them to the Kafka cluster to achieve asynchronous data decoupling;

[0008] S4 consumes messages from Kafka using the task ID as the key, performs data merging, formatting, and storage, writes aggregated metrics to the relational database of the data storage service, stores raw logs in object storage, and updates the registry center status.

[0009] S5 captures the updated registry status, extracts metrics and logs by task ID, generates a visual report for viewing and downloading via a web interface, and supports log retrieval.

[0010] Optionally, the method further includes:

[0011] S6 issues a stop command to the test node service, the node stops dual engines and cleans up temporary files, the registry center releases the node quota, and the data storage service archives reports and logs according to project permissions, thus completing the test lifecycle management.

[0012] Optionally, registering the task ID and the required number of nodes with the registration center in step S1 specifically includes:

[0013] Call the Register interface of the registry center to write the task ID, the required number of nodes, and the node label selector into the registry center's storage module, forming the basis for subsequent scheduling.

[0014] Optionally, the test node service in S2 simultaneously starts both JMeter and Locust engines, specifically including:

[0015] The test node service creates a directory named after the task ID on the local machine, writes the received scripts and parameters into the directory, and then starts the JMeter and Locust processes. The two processes share the task ID environment variable to ensure that the output test result files and log files are prefixed with the task ID. The system supports Docker containerized deployment and is compatible with Kubernetes and physical machine environments, enabling rapid elastic scaling of nodes.

[0016] Optionally, the test node service in S3 encapsulates the test results and logs into messages and pushes them to the Kafka cluster, specifically including:

[0017] The built-in data acquisition thread uses the Kafka Producer client to parse each test result and log line into JSON, appends a task ID field, and sends them in batches to the Kafka cluster. The platform management uses a B / S architecture, providing a web interface that allows users to upload scripts, configure parameters, download reports, and retrieve logs through a browser.

[0018] Optionally, the data processing service in S4 consumes Kafka messages using the task ID as the key, specifically including:

[0019] The Kafka Consumer subscription is named by task ID, and consumption is partitioned by the task ID field. After sorting by timestamp, the data is merged and formatted. The aggregated metrics are written to the relational database of the data storage service, while the raw logs are written to object storage, with the task ID as the path prefix.

[0020] Optionally, in step S6, the platform management module issues a stop command to the test node service, specifically including:

[0021] The stop interface of each test node service is called. The call parameter includes the task ID. After receiving the task ID, the test node service stops the JMeter and Locust processes corresponding to the task ID, deletes the local temporary directory named after the task ID, and returns a confirmation message. After receiving the confirmation, the platform management module deletes the key corresponding to the task ID from the registry center and releases the node quota.

[0022] Secondly, a dual-engine distributed performance testing system is provided, which includes:

[0023] The creation module is used to generate a globally unique task ID for the task when creating a test task. It writes the user-uploaded JMeter or Locust script, along with the concurrency, loop count, and target address parameters, into the data storage service and registers the task ID and the required number of nodes with the registry center, forming the sole basis for subsequent scheduling.

[0024] The testing module retrieves a list of available test node services from the registry center based on the task ID through the platform, and sends the script and parameters to the selected node. The node simultaneously starts the JMeter and Locust dual engines, executes the test on the target system according to the concurrency and loop count, and generates test results and logs in real time.

[0025] The push module is used to encapsulate the test results and logs of the same task ID into a message and continuously push it to the Kafka cluster, thereby achieving asynchronous data decoupling.

[0026] The storage module is used to consume messages from Kafka using the task ID as the key, perform data merging, formatting and storage, write aggregated metrics to the relational database of the data storage service, store raw logs in object storage, and update the registry center status.

[0027] The output module is used to capture the updated registry status, extract metrics and logs by task ID, generate a visual report for viewing and downloading via the web interface, and support log retrieval.

[0028] Thirdly, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the dual-engine distributed performance testing method described in any of the first aspects above.

[0029] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the dual-engine distributed performance testing method described in any of the first aspects above.

[0030] The beneficial effects of the technical solutions provided in this application include at least the following:

[0031] (1) Supports both JMeter and Locust testing engines, taking into account both Java and Python ecosystems, and improving script compatibility;

[0032] (2) A distributed architecture and message queue are adopted to achieve real-time processing and high availability of test data;

[0033] (3) Provide a unified Web management interface to simplify the process of test resource configuration, execution and report analysis;

[0034] (4) It has good scalability and maintainability, and is suitable for enterprise-level performance testing scenarios. Attached Figure Description

[0035] To more clearly illustrate the embodiments of this application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0036] Figure 1 A flowchart illustrating the steps of a dual-engine distributed performance testing method provided in this application embodiment;

[0037] Figure 2 This application provides a schematic diagram of a dual-engine distributed performance testing architecture.

[0038] Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0040] In the description of this application, the terms "comprising," "having," and any variations thereof are intended to cover non-exclusive inclusion, such as a process, method, system, product, or apparatus that includes a series of steps or units, not necessarily limited to those steps or units that are expressly listed, but may also include other steps or units that are not expressly listed but are inherent to these processes, methods, products, or apparatuses, or steps or units added based on further optimizations conceived in this application.

[0041] As software systems become increasingly complex, performance testing has become a crucial element in ensuring system stability and scalability. While existing performance testing tools such as JMeter and Locust are powerful, they have shortcomings in distributed deployment, resource management, real-time test data processing, and log collection, especially in large-scale concurrent testing scenarios, where the real-time performance of test results and system manageability are poor.

[0042] This invention aims to provide a performance testing platform system and method that supports dual testing engines, distributed deployment, real-time data processing, and log collection, in order to solve problems such as inconvenient resource management, poor real-time performance of test data, and insufficient system scalability in the prior art.

[0043] Please refer to Figure 1 The diagram illustrates a flowchart of a dual-engine distributed performance testing method provided in an embodiment of this application. The method may include the following steps:

[0044] S1 generates a globally unique task ID for the task when creating a test task, writes the user-uploaded JMeter or Locust script along with the concurrency, loop count, and target address parameters into the data storage service, and registers the task ID and the required number of nodes with the registry center, forming the sole basis for subsequent scheduling.

[0045] In this step, after the system receives the JMeter or Locust script uploaded by the user, it first generates a globally unique task number and stores this number, along with the set concurrency, number of loops, and target address, in the background database. At the same time, it writes this number and the required number of nodes into a unified configuration center as the sole basis for subsequent resource scheduling, ensuring that all data, logs, and status in the entire process are associated with this number.

[0046] S2: The platform retrieves a list of available test node services from the registry center based on the task ID, and sends the script and parameters to the selected node. The node simultaneously starts the JMeter and Locust dual engines, performs tests on the target system according to the number of concurrent requests and loops, and generates test results and logs in real time.

[0047] In this step, the system retrieves the list of currently available execution nodes from the configuration center based on the task number, selects a node according to the load, and then distributes the script and parameters. The node creates an isolated space with the same name as the task number on its local machine, and then starts two processes, JMeter and Locust, in parallel. They initiate load tests on the target address according to the given concurrency and number of loops, and write the generated test results and logs to the isolated space in real time for subsequent steps to read.

[0048] In S3, the test node service encapsulates the test results and logs for the same task ID into messages and continuously pushes them to the Kafka cluster, achieving asynchronous data decoupling.

[0049] In this step, during the load test, each execution node continuously scans the local result file through the built-in acquisition thread, appends a task number to each line of data, encapsulates it into a message in a unified format, and sends it in batches to the message queue. The sending end uses highly reliable parameters to ensure that data is not lost when a node or queue is abnormal, thus achieving complete decoupling between test execution and subsequent processing.

[0050] S4 consumes messages from Kafka using the task ID as the key, performs data merging, formatting, and storage, writes aggregated metrics to the relational database of the data storage service, stores raw logs in object storage, and updates the registry center status.

[0051] In this step, the backend consumer reads data sequentially from the message queue using the task number as the key. It first sorts the data by timestamp, then performs sliding window aggregation to calculate throughput, response time distribution, and error rate. The aggregation results are written to the metrics table of the relational database, while the raw logs are stored in object storage in columnar format. After completion, the status of the corresponding key in the configuration center is updated to "stored" to notify the downstream that the data is ready.

[0052] S5 captures the updated registry status, extracts metrics and logs by task ID, generates a visual report for viewing and downloading via a web interface, and supports log retrieval.

[0053] The system monitors status changes in the configuration center. Once a "stored" flag is detected, it immediately extracts aggregated data and raw logs from the metrics table and object storage, respectively, using the task number as an index. The data is then rendered into a web report containing graphs and statistical tables using a template engine. Users can directly browse and download the report through the web interface, or enter keywords or time periods to search for logs under the same number, achieving a one-stop display of load test results and problem localization.

[0054] This embodiment also includes:

[0055] S6 issues a stop command to the test node service, the node stops dual engines and cleans up temporary files, the registry center releases the node quota, and the data storage service archives reports and logs according to project permissions, thus completing the test lifecycle management.

[0056] like Figure 2 A schematic diagram of a dual-engine distributed performance testing architecture is provided, which specifically includes the following components:

[0057] TestNode Service: Deployed with JMeter and Locust test engines, responsible for executing performance test scripts, and integrating data processing and log collection modules to push test results and logs to the Kafka cluster in real time;

[0058] Kafka message queue: used to cache test result data and log information, achieving asynchronous data decoupling and high-throughput transmission;

[0059] Data Processing Service (DPS): Consumes data from Kafka and performs data merging, formatting, and database insertion operations;

[0060] Data storage service: used to store test results, configuration files, and log data;

[0061] Registration Center: Enables service discovery, registration, and configuration management;

[0062] Platform Management Module: Provides a web interface for unified management of test resources, scripts, reports, logs, and system permissions.

[0063] The platform supports Docker containerized deployment and is compatible with Kubernetes clusters and physical machine environments.

[0064] Based on the above components, the following process was implemented:

[0065] 1. System Deployment: Deploy components such as TestNode, Kafka, DPS, and registry center in a Kubernetes or physical machine environment using Docker;

[0066] 2. Test Execution: Users upload JMeter or Locust scripts through the web interface, configure parameters such as concurrency and loop count, and the platform schedules TestNode to execute the test;

[0067] 3. Data Processing: Data and logs generated during the test are consumed by the DPS service via Kafka and stored in the database;

[0068] 4. Report and Log Management: Users can view and download test reports and logs through the platform, supporting result analysis and problem localization;

[0069] 5. Permissions and Project Management: Supports multi-project and multi-user permission management to ensure the security of test resources.

[0070] In summary, the system includes test node services, Kafka message queues, data processing services, data storage services, a registry center, and platform management modules. The platform supports both JMeter and Locust testing engines, employs a distributed architecture and containerized deployment, and enables test task scheduling, real-time data processing, log collection, and unified management. This invention is suitable for enterprise-level performance testing scenarios, featuring high scalability, ease of use, and real-time performance. Specifically:

[0071] 1) Test node service, used to perform performance tests and collect test data and logs;

[0072] 2) Message middleware, used to cache test data and logs;

[0073] 3) Data processing service, used to process and store test data and logs;

[0074] 4) Data storage service, used to persist test results, configurations, and logs;

[0075] 5) Registry Center, used for service registration and discovery;

[0076] 6) Platform management module, used for unified management of resources, scripts, reports, logs and permissions.

[0077] In addition, the test node service supports both JMeter and Locust testing engines. The system supports Docker containerized deployment and is compatible with Kubernetes and physical machine environments. The platform management module adopts a B / S architecture and provides a web-based user interface.

[0078] This application also provides a dual-engine distributed performance testing system, which may include:

[0079] The creation module is used to generate a globally unique task ID for the task when creating a test task. It writes the user-uploaded JMeter or Locust script, along with the concurrency, loop count, and target address parameters, into the data storage service and registers the task ID and the required number of nodes with the registry center, forming the sole basis for subsequent scheduling.

[0080] The testing module retrieves a list of available test node services from the registry center based on the task ID through the platform, and sends the script and parameters to the selected node. The node simultaneously starts the JMeter and Locust dual engines, executes the test on the target system according to the concurrency and loop count, and generates test results and logs in real time.

[0081] The push module is used to encapsulate the test results and logs of the same task ID into a message and continuously push it to the Kafka cluster, thereby achieving asynchronous data decoupling.

[0082] The storage module is used to consume messages from Kafka using the task ID as the key, perform data merging, formatting and storage, write aggregated metrics to the relational database of the data storage service, store raw logs in object storage, and update the registry center status.

[0083] The output module is used to capture the updated registry status, extract metrics and logs by task ID, generate a visual report for viewing and downloading via the web interface, and support log retrieval.

[0084] Specific limitations regarding the dual-engine distributed performance testing system can be found in the limitations of the dual-engine distributed performance testing method described above, and will not be repeated here. Each module in the aforementioned dual-engine distributed performance testing system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0085] In one embodiment, an electronic device is provided, which may be a computer, and its internal structure diagram may be as follows: Figure 3 As shown, the electronic device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The database of the computer device is used for dual-engine distributed performance test data. The network interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a dual-engine distributed performance testing method.

[0086] Those skilled in the art will understand that, Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0087] In one embodiment of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described dual-engine distributed performance testing method.

[0088] In one embodiment of this application, a computer program product is provided, including a computer program / instructions, which, when executed by a processor, implements the steps of the above-described dual-engine distributed performance testing method.

[0089] The computer-readable storage medium and computer program product provided in this embodiment are similar in implementation principle and technical effect to the above method embodiments, and will not be repeated here.

[0090] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods.

[0091] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0092] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A dual-engine distributed performance testing method, characterized in that, The method includes: S1. When creating a test task, generate a globally unique task ID for the task, write the user-uploaded JMeter or Locust script along with the concurrency, loop count, and target address parameters into the data storage service, and register the task ID and the required number of nodes with the registry center to form the sole basis for subsequent scheduling. S2, the platform obtains a list of available test node services from the registration center based on the task ID, and sends the script and parameters to the selected node. The node simultaneously starts the JMeter and Locust dual engines, performs tests on the target system according to the concurrency and loop count, and generates test results and logs in real time. S3, the test node service encapsulates the test results and logs of the same task ID into messages and continuously pushes them to the Kafka cluster to achieve asynchronous data decoupling; S4 consumes messages from Kafka using the task ID as the key, performs data merging, formatting, and storage, writes aggregated metrics to the relational database of the data storage service, stores raw logs in object storage, and updates the registry center status. S5 captures the updated registry status, extracts metrics and logs by task ID, generates a visual report for viewing and downloading via a web interface, and supports log retrieval.

2. The dual-engine distributed performance testing method according to claim 1, characterized in that, The method further includes: S6 issues a stop command to the test node service, the node stops dual engines and cleans up temporary files, the registry center releases the node quota, and the data storage service archives reports and logs according to project permissions, thus completing the test lifecycle management.

3. The dual-engine distributed performance testing method according to claim 1, characterized in that, The specific steps in S1 of registering the task ID and the required number of nodes with the registration center include: Call the Register interface of the registry center to write the task ID, the required number of nodes, and the node label selector into the registry center's storage module, forming the basis for subsequent scheduling.

4. The dual-engine distributed performance testing method according to claim 1, characterized in that, The test node service in S2 simultaneously starts both JMeter and Locust engines, specifically including: The test node service creates a directory named after the task ID on the local machine, writes the received scripts and parameters into the directory, and then starts the JMeter and Locust processes. The two processes share the task ID environment variable to ensure that the output test result files and log files are prefixed with the task ID. The system supports Docker containerized deployment and is compatible with Kubernetes and physical machine environments, enabling rapid elastic scaling of nodes.

5. The dual-engine distributed performance testing method according to claim 1, characterized in that, The test node service in S3 encapsulates the test results and logs into messages and pushes them to the Kafka cluster, specifically including: The built-in data acquisition thread uses the Kafka Producer client to parse each test result and log line into JSON, appends a task ID field, and sends them in batches to the Kafka cluster. The platform management uses a B / S architecture, providing a web interface that allows users to upload scripts, configure parameters, download reports, and retrieve logs through a browser.

6. The dual-engine distributed performance testing method according to claim 1, characterized in that, The data processing service in S4 consumes Kafka messages using the task ID as the key, specifically including: The Kafka Consumer subscription is named by task ID, and consumption is partitioned by the task ID field. After sorting by timestamp, the data is merged and formatted. The aggregated metrics are written to the relational database of the data storage service, while the raw logs are written to object storage, with the task ID as the path prefix.

7. The dual-engine distributed performance testing method according to claim 2, characterized in that, In S6, the platform management module issues a stop command to the test node service, specifically including: The stop interface of each test node service is called. The call parameter includes the task ID. After receiving the task ID, the test node service stops the JMeter and Locust processes corresponding to the task ID, deletes the local temporary directory named after the task ID, and returns a confirmation message. After receiving the confirmation, the platform management module deletes the key corresponding to the task ID from the registry center and releases the node quota.

8. A dual-engine distributed performance testing system, characterized in that, The system includes: The creation module is used to generate a globally unique task ID for the task when creating a test task. It writes the user-uploaded JMeter or Locust script, along with the concurrency, loop count, and target address parameters, into the data storage service and registers the task ID and the required number of nodes with the registry center, forming the sole basis for subsequent scheduling. The testing module retrieves a list of available test node services from the registry center based on the task ID through the platform, and sends the script and parameters to the selected node. The node simultaneously starts the JMeter and Locust dual engines, executes the test on the target system according to the concurrency and loop count, and generates test results and logs in real time. The push module is used to encapsulate the test results and logs of the same task ID into a message and continuously push it to the Kafka cluster, thereby achieving asynchronous data decoupling. The storage module is used to consume messages from Kafka using the task ID as the key, perform data merging, formatting and storage, write aggregated metrics to the relational database of the data storage service, store raw logs in object storage, and update the registry center status. The output module is used to capture the updated registry status, extract metrics and logs by task ID, generate a visual report for viewing and downloading via the web interface, and support log retrieval.

9. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the dual-engine distributed performance testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the dual-engine distributed performance testing method as described in any one of claims 1 to 7.

Images