WO2020253079A1 - Jmeter-based distributed performance test method and apparatus, device, and storage medium - Google Patents

Abstract

The present application relates to the field of cloud testing, and discloses a Jmeter-based distributed performance test method and apparatus, a device, and a storage medium. The Jmeter-based distributed performance test method comprises: deploying a Jmeter mirror image of a prediction version to distributed nodes, wherein the distributed nodes comprise one master node and at least one slave node; when the master node receives a test start instruction, the master node transmitting a respective corresponding test script to each slave node; when each slave node receives the respective corresponding test script, each slave node performing respective performance tests, and acquiring respective corresponding test results; each slave node transmitting the respective corresponding test results to the master node; and the master node counting the respective corresponding test results, and acquiring a performance test result. The present application performs version control on a Jmeter mirror image, and uses container-based distributed nodes to deploy the Jmeter mirror image to perform performance test. Deployment is simple and quick, thereby improving the efficiency of test.

Description

Jmeter-based distributed performance testing method, device, equipment and storage medium

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on June 17, 2019, the application number is 201910523487.4, and the invention title is "Jmeter-based distributed performance testing methods, devices, equipment and computer-readable storage media". , Its entire content is incorporated in the application by reference.

Technical field

This application relates to the field of cloud testing, and in particular to Jmeter-based distributed performance testing methods, devices, equipment, and storage media.

Background technique

The mainstream tools for server-side performance testing are Jmeter and LoadRunner. The principle is to monitor and collect instructions sent by concurrent clients through intermediate agents, generate scripts and send them to the application server, and then monitor the results of the server.

When testing the interface performance of the application, due to the limitations of the single-machine CPU and memory, the single-machine deployment of Jmeter cannot meet the test requirements, and Jmeter distributed deployment is required. The traditional application deployment method is to install the application through plug-ins or scripts. The disadvantage of this is that the operation, configuration, management, and all life cycles of the application will be bound to the current operating system. The inventor realizes that this is not conducive to the application. Operations such as upgrade updates and version rollbacks.

When deploying Jmeter by creating a virtual machine, the deployment process is complicated, inefficient, and not conducive to portability. At the same time, the inventor found that a Jmeter cluster based on a large number of virtual machines has a disadvantage that is inconvenient to manage, such as the need to restart Jmeter The service also needs to be connected to each virtual machine for operation, and it is not convenient to install and deploy, and it is not convenient to package the cluster into a whole application to provide services to the outside.

Summary of the invention

The main purpose of this application is to solve the problem that Jmeter deployed on a stand-alone machine cannot meet the test requirements, but the process of deploying Jmeter using a virtual machine is complicated, low in efficiency and poor portability, and at the same time solves the problem of unfriendly version control support for test scripts.

In order to achieve the above objectives, the first aspect of the present application provides a Jmeter-based distributed performance test method, including: deploying a predicted version of the Jmeter image to a distributed node. The distributed node includes a master node and at least one slave node. Node; when the master node receives the start-up test instruction, the master node sends the corresponding test script to each slave node; when each slave node receives the respective corresponding test script, the test script is performed by each slave node The performance test obtains the respective corresponding test results; each slave node sends the respective corresponding test results to the master node; and the master node counts the respective corresponding test results to obtain the performance test results.

Optionally, in the first implementation manner of the first aspect of the present application, the deployment of the predicted version of the Jmeter image to a distributed node, where the distributed node includes a master node and at least one slave node includes: slave mirror Select the predicted version of the Jmeter image in the warehouse; set up the distributed node through an ECS instance of the elastic computing service, the distributed node including the one master node and the at least one slave node; determine the master node and each slave node Whether the Jmeter image of the predicted version exists at the same time; if the Jmeter image of the predicted version does not exist at the same time on the master node and each slave node, deploy the Jmeter image of the predicted version in a preset manner to obtain the deployment result; if If the Jmeter image of the predicted version exists at the same time on the master node and each slave node, it is determined that the deployment is successful.

Optionally, in the second implementation manner of the first aspect of the present application, if the master node and each slave node do not simultaneously have a Jmeter image of the predicted version, the predicted version is deployed in a preset manner The Jmeter image obtained by the deployment result includes: if the predicted version of the Jmeter image does not exist in the master node and each slave node at the same time, deploy the predicted version of the Jmeter image to the ECS instance to obtain the Jmeter application; Run the Jmeter application through the container docker; add the configuration information corresponding to each slave node to the control list of the master node, and the configuration information corresponding to each slave node includes its corresponding IP address and its corresponding port; restart The Jmeter application of the master node obtains the deployment result.

Optionally, in the third implementation manner of the first aspect of the present application, if the master node and each slave node do not simultaneously have a Jmeter image of the predicted version, the predicted version is deployed in a preset manner After the deployment result is obtained, the Jmeter-based distributed performance testing method further includes: determining whether the deployment result is a target value, the target value being used to indicate successful deployment of the predicted version of the Jmeter image; if If the deployment result is not the target value, then redeploy; if the deployment result is the target value, it is determined that the deployment is successful.

Optionally, in the fourth implementation manner of the first aspect of the present application, when the master node receives the start test instruction, sending the corresponding test script to each slave node through the master node includes: The master node is set as the client of remote method invoking RMI; each slave node is set as the server side of the RMI; when the master node receives the start test instruction, the test plan is executed through the master node, the The test plan includes total test data and test scripts; parsing the control list of the master node to obtain configuration information corresponding to each slave node; splitting the total test data according to the configuration information corresponding to each slave node, Obtain the test data corresponding to each slave node; replace the keywords in the test script according to the test data corresponding to each slave node to obtain the respective corresponding test script; send the corresponding test script to each slave node in the RMI manner through the master node Push the respective corresponding test scripts from the node.

Optionally, in the fifth implementation manner of the first aspect of the present application, when each slave node receives the respective corresponding test script, each slave node performs a performance test to obtain the corresponding test result. Including: when each slave node receives the respective corresponding test script, analyze the respective corresponding test script through each slave node to obtain the respective corresponding test request; execute the respective corresponding test request through each slave node, Obtain the respective corresponding test results; record the respective corresponding test results through each slave node.

Optionally, in the sixth implementation manner of the first aspect of the present application, before the Jmeter image of the predicted version is deployed to a distributed node, the distributed node includes a master node and at least one slave node, the The Jmeter-based distributed performance testing method further includes: uploading the predicted version of the Jmeter image to the mirror warehouse; and performing version management on the predicted version of the Jmeter image by tagging.

A third aspect of the present application provides a Jmeter-based distributed performance test equipment, including: a memory and at least one processor, the memory stores instructions, and the memory and the at least one processor are interconnected by wires; The at least one processor invokes the instructions in the memory, so that the Jmeter-based distributed performance testing device executes the method described in the first aspect.

The fourth aspect of the present application provides a computer-readable storage medium having instructions stored in the computer-readable storage medium, which when run on a computer, cause the computer to execute the method described in the first aspect.

It can be seen from the above technical solutions that this application has the following advantages:

In the technical solution provided by this application, the predicted version of the Jmeter image is deployed to a distributed node. The distributed node includes a master node and at least one slave node; when the master node receives a start test instruction, the The master node sends each corresponding test script to each slave node; when each slave node receives the respective corresponding test script, the performance test is performed through each slave node to obtain the corresponding test result; each slave node corresponds to each The test result of is sent to the master node; the master node counts the respective corresponding test results to obtain the performance test result. In the embodiment of the application, the Jmeter image is version controlled through the mirror warehouse, and the Jmeter image is deployed and performance tested using container-based distributed nodes. The processes between the containers will not affect each other, and the computing resources can be distinguished, and compared to the virtual machine , The container deployment process is simplified and testing efficiency is improved.

Description of the drawings

FIG. 1 is a schematic diagram of an embodiment of a Jmeter-based distributed performance testing method in an embodiment of the application;

2 is a schematic diagram of another embodiment of a Jmeter-based distributed performance testing method in an embodiment of the application;

Fig. 3 is a schematic diagram of an embodiment of a Jmeter-based distributed performance testing device in an embodiment of the application;

4 is a schematic diagram of another embodiment of a Jmeter-based distributed performance testing device in an embodiment of the application;

Fig. 5 is a schematic diagram of another embodiment of a Jmeter-based distributed performance test device in an embodiment of the application.

Detailed ways

This application provides a distributed performance test equipment based on Jmeter.

Referring to FIG. 1, FIG. 1 is an embodiment of a Jmeter-based distributed performance testing method in an embodiment of the application, including:

101. Deploy the Jmeter image of the predicted version to a distributed node, where the distributed node includes a master node and at least one slave node;

The server deploys the predicted version of the Jmeter image to the distributed node. The distributed node includes a master node and at least one slave node. Both the master node and the slave node use container docker. Docker is an open source application container engine. Docker completely uses a sandbox mechanism without any interfaces between them. Docker uses a client-server C/S architecture model.

It should be noted that the server selects the predicted version of the Jmeter mirror from the mirror warehouse. The server is mirrored by Jmeter, there is no need to set up environments such as Java virtual machine and property files, but only need to focus on creating test scripts and test resources, such as data files. A Jmeter mirror contains all the scripts in the test task. According to the corresponding relationship between the test task and the test script name, a certain version of the Jmeter mirror is selected as the predicted version of the Jmeter mirror. The Jmeter image does not filter any Jmeter command parameters and allows multiple operating modes. In the container-based distributed mode, the image can be used to build a container cluster.

102. When the master node receives the start test instruction, it sends the corresponding test script to each slave node through the master node;

When the master node receives the start test instruction, the server sends the corresponding test script to each slave node through the master node. Specifically, the server sets the master node as the client of remote method invocation RMI; the server sets each slave node as the server side of RMI; when the master node receives the start test instruction, the server executes the test plan through the master node, and the test plan includes Total test data and test scripts; the server parses the control list of the master node to obtain the configuration information corresponding to each slave node; the server splits the total test data according to the configuration information corresponding to each slave node to obtain the test data corresponding to each slave node; The server replaces the keywords in the test script according to the test data corresponding to each slave node to obtain the corresponding test script; the server pushes the corresponding test script to each slave node in the RMI manner through the master node.

It should be noted that remote method invocation (RMI) is an application programming interface used to implement remote procedure invocation, which supports programs running on the client to call objects on the remote server, that is, stored in different addresses The program-level objects in the space communicate with each other, and the RMI feature supports distributed operations in a network environment. RMI includes a server that runs a remote method call service and a client that runs a remote method call service.

103. When each slave node receives its corresponding test script, perform a performance test through each slave node to obtain respective corresponding test results;

When each slave node receives its corresponding test script, the server performs a performance test through each slave node to obtain the corresponding test result. Specifically, when each slave node receives its corresponding test script, the server parses its corresponding test script through each slave node to obtain its corresponding test request; through each slave node executes its corresponding test request, obtains its corresponding test script. Test result: The server records the corresponding test result through each slave node.

It should be noted that the performance test indicators include the number of concurrency, average response time, request success rate, and the number of concurrent requests or transactions per second, namely QPS/TPS. Among them, the relationship between QPS/TPS and the number of concurrencies and the average response time is that QPS/TPS is equal to the number of concurrencies divided by the average response time.

104. Send the corresponding test results to the master node through each slave node;

The server sends the corresponding test results to the master node through each slave node. Specifically, the server receives the corresponding test result through each slave node, the server sends the corresponding test result to the master node through each slave node in the RMI service mode, and each slave node records its corresponding test result. The test results are test requests under the same test plan, but the respective test results are not the same, and the respective test results include normal test data results and abnormal test data results.

105. Obtain performance test results through the statistics of the respective corresponding test results by the master node.

The server counts the corresponding test results through the master node, and obtains the performance test results. Specifically, the server receives the respective test results of each slave node through the master node, and the server calculates and classifies the respective test results of each slave node according to a preset statistical script to obtain the performance test result.

In the embodiment of the application, the Jmeter image is version controlled through the mirror warehouse, and version rollback is supported. At the same time, the container-based distributed node is used to deploy the Jmeter image and perform performance testing. The processes between the containers will not affect each other and can distinguish computing resources. , And compared to virtual machines, containers can be deployed quickly. Because the container is decoupled from the underlying facilities and the machine file system, it can be migrated between different clouds and different versions of operating systems, simplifying the deployment process and improving test efficiency.

Refer to FIG. 2, which is another embodiment of the Jmeter-based distributed performance testing method in the embodiment of the application, including:

201. Select the predicted version of the Jmeter mirror from the mirror warehouse;

The server selects the predicted version of the Jmeter image from the image warehouse. The image is an elastic cloud server template that contains software and necessary configurations. It contains at least the operating system, and can also contain application software and proprietary software. For example, application software includes database software. Mirrors are divided into public mirrors and private mirrors. The public mirror is the mirror provided by the system by default, and the private mirror is the mirror created by the user.

It should be noted that the server selects the predicted version of the Jmeter mirror from the mirror warehouse. The server is mirrored by Jmeter, there is no need to set up environments such as Java virtual machine and property files, but only need to focus on creating test scripts and test resources, such as data files. A Jmeter mirror contains all the scripts in the test task. According to the corresponding relationship between the test task and the test script name, a certain version of the Jmeter mirror is selected as the predicted version of the Jmeter mirror. The Jmeter image does not filter any Jmeter command parameters and allows multiple operating modes. In the container-based distributed mode, the image can be used to build a container cluster.

Optionally, the server uploads the predicted version of the Jmeter image to the mirror warehouse. The mirror warehouse is a warehouse that stores docker images. It is not limited to the Jmeter image and is divided into public and private warehouses; the server uses tags to label the predicted version of Jmeter. Image version management, version management is to label Jmeter images of different test tasks according to preset rules. The same test task can have different branches and tags according to different test scripts. At the same time, Jmeter image deployment also supports version rollback. , Making test deployment more convenient and faster.

202. Set up a distributed node through an ECS instance of the elastic computing service, where the distributed node includes a master node and at least one slave node;

The server sets up a distributed node through an ECS instance of the elastic computing service, and the distributed node includes a master node and at least one slave node. The distributed node is a system composed of a group of computer nodes that communicate through a network and coordinate work to complete common tasks. The emergence of distributed nodes is to use cheap and ordinary machines to complete calculation and storage tasks that a single computer cannot complete.

It should be noted that in actual deployment, the server dynamically adjusts the number of slave nodes according to the number of concurrent performance test indicators. For example, if the number of concurrent performance test indicators is 1000, and the maximum number of concurrent slave nodes is 200, then at least 5 slave nodes.

203. Determine whether the Jmeter mirror of the predicted version exists at the same time on the master node and each slave node;

The server judges whether the Jmeter mirror of the predicted version exists at the same time on the master node and each slave node. Specifically, the server judges whether the target mirror installation file is contained in the designated directory of the master node and each slave node. If the designated directory of the master node and each slave node does not contain If the target mirror installation file does not exist at the same time, the predicted version of the Jmeter mirror is determined; if the target mirror installation file is contained in the designated directory of the master node and each slave node, the target mirror installation file is read to obtain the version number; to determine whether the version number matches the forecast The version number of the Jmeter image of the version matches. If the version number of the Jmeter image installation file matches the version number of the predicted version of the Jmeter image, it is determined that there is a predicted version of the Jmeter image; if the version number does not match the version number of the predicted version of the Jmeter image Match, it is determined that there is no Jmeter mirror of the predicted version at the same time.

204. If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image through a preset method to obtain the deployment result;

If the master node and each slave node do not have the predicted version of the Jmeter mirror at the same time, the predicted version of the Jmeter mirror is deployed through the preset method, and the deployment result is obtained. Specifically, if the master node and each slave node do not have the predicted version of the Jmeter mirror at the same time , The server deploys the predicted version of the Jmeter image to the ECS instance to obtain the Jmeter application; the server runs the Jmeter application through the container docker; the server adds each slave node to the control list of the master node; the server restarts the Jmeter application of the master node to get Deployment results. Among them, an ECS instance is equivalent to a virtual machine, including basic computing components such as CPU, memory, operating system, network, and disk. According to business scenarios and usage scenarios, ECS instances can be divided into multiple specification families. In the same business scenario, you can also choose a variety of new and old specification families. According to the configuration of CPU and memory, the same specification family can be divided into many different specifications. The ECS instance specification defines the configuration of the CPU and memory of the instance, including the CPU model and main frequency.

Optionally, the server determines whether the deployment result is the target value, and the target value indicates the successful deployment of the predicted version of the Jmeter image; if the deployment result is not the target value, the server redeploys the predicted version of the Jmeter image; if the deployment result is the target value, then Confirm that the deployment was successful. Specifically, the server queries the status of deploying the Jmeter image through the kubernetes platform, and judges whether the Jmeter image deployment is successful based on this. Among them, kubernetes is an open source container orchestration engine that supports automated deployment, large-scale scalability, and application container management. When deploying an application in a production environment, multiple instances of the application are usually deployed to load balance application requests.

205. If the Jmeter image of the predicted version exists at the same time on the master node and each slave node, it is determined that the deployment is successful;

If the Jmeter image of the predicted version exists at the same time on the master node and each slave node, the server determines that the deployment is successful. Specifically, the server loops through the deployment of the predicted version of the Jmeter image to the master node and each slave node, and checks the deployment results one by one, until all deployments are successful, and then execute step 206.

206. When the master node receives the start test instruction, it sends the corresponding test script to each slave node through the master node;

When the master node receives the start test instruction, the server sends the corresponding test script to each slave node through the master node. Specifically, the server sets the master node as the client of remote method invocation RMI; the server sets each slave node as the server side of RMI; when the master node receives the start test instruction, the server executes the test plan through the master node, and the test plan includes Total test data and test scripts; the server parses the control list of the master node to obtain the configuration information corresponding to each slave node; the server splits the total test data according to the configuration information corresponding to each slave node to obtain the test data corresponding to each slave node; The server replaces the keywords in the test script according to the test data corresponding to each slave node to obtain the corresponding test script. Among them, the master node communicates with each slave node, but each slave node does not communicate with each other.

It should be noted that remote method invocation (RMI) is an application programming interface used to implement remote procedure invocation, which supports programs running on the client to call objects on the remote server, that is, stored in different addresses The program-level objects in the space communicate with each other, and the RMI feature supports distributed operations in a network environment. RMI includes a server that runs a remote method call service and a client that runs a remote method call service.

207. When each slave node receives its corresponding test script, perform a performance test through each slave node to obtain respective corresponding test results;

When each slave node receives its corresponding test script, the server performs a performance test through each slave node to obtain the corresponding test result. Specifically, when each slave node receives its corresponding test script, the server parses its corresponding test script through each slave node to obtain its corresponding test request; through each slave node executes its corresponding test request, obtains its corresponding test script. Test result: The server records the corresponding test result through each slave node.

It should be noted that the performance test indicators include the number of concurrency, average response time, request success rate, and the number of concurrent requests or transactions per second, namely QPS/TPS. Among them, the relationship between QPS/TPS and the number of concurrencies and the average response time is that QPS/TPS is equal to the number of concurrencies divided by the average response time.

208. Send the corresponding test results to the master node through each slave node;

The server sends the corresponding test results to the master node through each slave node. Specifically, the server receives the corresponding test results through each slave node, and the server sends the corresponding test results to the master node through each slave node in the RMI service mode. The respective test results are test requests under the same test plan. But the corresponding test results are not the same. The test results include normal test data and abnormal test data.

209. Obtain performance test results through the master node statistics of respective test results.

The server counts the corresponding test results through the master node, and obtains the performance test results. Specifically, the server receives the respective test results of each slave node through the master node, and the server calculates and classifies the respective test results of each slave node according to a preset statistical script to obtain the performance test result. Further, the server displays the performance test results through the Jmeter application of the master node.

It should be noted that the throughput of each slave node is closely related to the CPU consumption of user requests. The higher the CPU consumption of a single user request, the lower the throughput of each slave node, that is, the smaller the number of concurrent processing.

In the embodiment of the application, the Jmeter image is version controlled through the mirror warehouse, and version rollback is supported. At the same time, the container-based distributed node is used to deploy the Jmeter image and perform performance testing. The processes between the containers will not affect each other and can distinguish computing resources , And compared to virtual machines, containers can be deployed quickly. Because the container is decoupled from the underlying facilities and the machine file system, it can be migrated between different clouds and different versions of operating systems, simplifying the deployment process and improving test efficiency.

Referring to FIG. 3, FIG. 3 is an embodiment of a Jmeter-based distributed performance testing device in an embodiment of the application, including:

The deployment unit 301 is configured to deploy the predicted version of the Jmeter image to a distributed node, and the distributed node includes a master node and at least one slave node;

The control unit 302, when the master node receives the start test instruction, is used to send the corresponding test script to each slave node through the master node;

The test unit 303, when each slave node receives its corresponding test script, is used to perform a performance test through each slave node to obtain respective test results;

The sending unit 304 is configured to send the corresponding test results to the master node through each slave node;

The statistics unit 305 is configured to count the respective test results corresponding to the master nodes to obtain the performance test results.

In the embodiment of the application, the Jmeter image is version controlled through the mirror warehouse, and version rollback is supported. At the same time, the container-based distributed node is used to deploy the Jmeter image and perform performance testing. The processes between the containers will not affect each other and can distinguish computing resources , And compared to virtual machines, containers can be deployed quickly. Because the container is decoupled from the underlying facilities and the machine file system, it can be migrated between different clouds and different versions of operating systems, simplifying the deployment process and improving test efficiency.

Referring to FIG. 4, FIG. 4 is another embodiment of the Jmeter-based distributed performance testing device in the embodiment of the application, including:

The deployment unit 301 is configured to deploy the predicted version of the Jmeter image to a distributed node, and the distributed node includes a master node and at least one slave node;

The control unit 302, when the master node receives the start test instruction, is used to send the corresponding test script to each slave node through the master node;

The test unit 303, when each slave node receives its corresponding test script, is used to perform a performance test through each slave node to obtain respective test results;

The sending unit 304 is configured to send the corresponding test results to the master node through each slave node;

The statistics unit 305 is configured to count the respective test results corresponding to the master nodes to obtain the performance test results.

Optionally, the deployment unit 301 may further include:

The selection subunit 3011 is used to select the predicted version of the Jmeter image from the image warehouse;

The setting subunit 3012 is used to set up distributed nodes through the ECS instance of the elastic computing service, and the distributed nodes include a master node and at least one slave node;

The first judging subunit 3013 is used to judge whether the Jmeter mirror of the predicted version exists at the same time on the master node and each slave node;

The deployment subunit 3014, if the master node and each slave node do not have the predicted version of the Jmeter image at the same time, it is used to deploy the predicted version of the Jmeter image in a preset manner to obtain the deployment result;

The confirmation sub-unit 3015 is used to determine that the deployment is successful if the Jmeter image of the predicted version exists at the same time on the master node and each slave node.

Optionally, the deployment subunit 3014 may also be specifically used for:

If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image to the ECS instance to obtain the Jmeter application;

Run Jmeter application through container docker;

Add the configuration information corresponding to each slave node to the control list of the master node, and the configuration information corresponding to each slave node includes its corresponding IP address and its corresponding port;

Restart the Jmeter application of the master node to get the deployment result.

Optionally, the deployment unit 301 may further include:

The second judging subunit 3016 is used to judge whether the deployment result is a target value, and the target value is used to indicate the successful deployment of the predicted version of the Jmeter image;

The first processing subunit 3017, if the deployment result is not the target value, is used for redeployment;

The second processing subunit 3018, if the deployment result is the target value, is used to determine that the deployment is successful.

Optionally, the control unit 302 may also be specifically configured to:

Set the master node as the client of remote method invocation RMI;

Set each slave node as the server side of RMI;

When the master node receives the start test instruction, the master node executes the test plan, which includes the total test data and the test script;

Parse the control list of the master node to obtain the configuration information corresponding to each slave node;

Split the total test data according to the configuration information corresponding to each slave node to obtain the test data corresponding to each slave node;

Replace the keywords in the test script according to the test data corresponding to each slave node to obtain the corresponding test script;

Push the corresponding test script to each slave node through the master node in RMI mode.

Optionally, the test unit 303 may also be specifically used for:

When each slave node receives its corresponding test script, each slave node analyzes its corresponding test script to obtain its corresponding test request;

Each slave node executes its corresponding test request to obtain its corresponding test result.

Optionally, the Jmeter-based distributed performance testing device may further include:

The uploading unit 306 is used to upload the Jmeter image of the predicted version to the image warehouse;

The management unit 307 is configured to perform version management on the Jmeter image of the predicted version by tagging.

In the embodiment of the application, the Jmeter image is version controlled through the mirror warehouse, and version rollback is supported. At the same time, the container-based distributed node is used to deploy the Jmeter image and perform performance testing. The processes between the containers will not affect each other and can distinguish computing resources. , And compared to virtual machines, containers can be deployed quickly. Because the container is decoupled from the underlying facilities and the machine file system, it can be migrated between different clouds and different versions of operating systems, simplifying the deployment process and improving test efficiency.

The above figures 3 and 4 describe in detail the Jmeter-based distributed performance test device in the embodiment of the present application from the perspective of modular functional entities. The following describes the Jmeter-based distributed performance test device in the embodiment of the present application from the perspective of hardware processing Give a detailed description.

FIG. 5 is a schematic structural diagram of a Jmeter-based distributed performance testing device provided by an embodiment of the present application. The Jmeter-based distributed performance testing device 500 may have relatively large differences due to different configurations or performances, and may include one or One or more processors (central processing units, CPU) 501 (for example, one or more processors) and memory 509, one or more storage media 508 for storing application programs 509 or data 509 (for example, one or one storage device with a large amount of ). Among them, the memory 509 and the storage medium 508 may be short-term storage or persistent storage. The program stored in the storage medium 508 may include one or more modules (not shown in the figure), and each module may include a series of command operations in the Jmeter-based distributed performance test. Further, the processor 501 may be configured to communicate with the storage medium 508, and execute a series of instruction operations in the storage medium 508 on the Jmeter-based distributed performance testing device 500.

The distributed performance test equipment 500 based on Jmeter may also include one or more power supplies 502, one or more wired or wireless network interfaces 503, one or more input and output interfaces 504, and/or, one or more operating systems 505 . Those skilled in the art can understand that the structure of the Jmeter-based distributed performance test equipment shown in FIG. 5 does not constitute a limitation on the Jmeter-based distributed performance test equipment, and may include more or less components than shown, or Combining certain components, or different component arrangements.

In addition, the functional units in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or software functional unit.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solution of this application essentially or the part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (read-only memory, ROM), random access memory (random access memory, RAM), magnetic disk or optical disk and other media that can store program code Wherein, the computer-readable storage medium may be a non-volatile storage medium or a volatile storage medium.

Claims (20)

1. A distributed performance test method based on Jmeter. The distributed performance test method based on Jmeter includes the following steps:

   Deploying the predicted version of the Jmeter image to a distributed node, the distributed node including a master node and at least one slave node;

   When the master node receives the test start instruction, sending the corresponding test script to each slave node through the master node;

   When each slave node receives the corresponding test script, perform a performance test through each slave node to obtain respective corresponding test results;

   Sending the respective corresponding test results to the master node through each slave node;

   The respective corresponding test results are counted by the master node to obtain performance test results.
2. The Jmeter-based distributed performance testing method according to claim 1, wherein the deployment of the predicted version of the Jmeter image to a distributed node, the distributed node including a master node and at least one slave node includes:

   Select the predicted version of Jmeter mirror from the mirror warehouse;

   Setting the distributed node through an ECS instance of the elastic computing service, the distributed node including the one master node and the at least one slave node;

   Determine whether the Jmeter mirror of the predicted version exists at the same time on the master node and each slave node;

   If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image in a preset manner to obtain the deployment result;

   If the Jmeter image of the predicted version exists at the same time on the master node and each slave node, it is determined that the deployment is successful.
3. The Jmeter-based distributed performance testing method according to claim 2, wherein if the master node and each slave node do not have the predicted version of Jmeter mirror at the same time, deploy the predicted version of Jmeter in a preset manner Mirror, get deployment results including:

   If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image on the ECS instance to obtain a Jmeter application;

   Run the Jmeter application through the container docker;

   Adding configuration information corresponding to each slave node to the control list of the master node, where the configuration information corresponding to each slave node includes each corresponding IP address and each corresponding port;

   Restart the Jmeter application of the master node to obtain the deployment result.
4. The Jmeter-based distributed performance testing method according to claim 2, wherein if the master node and each slave node do not have the predicted version of Jmeter mirror at the same time, deploy the predicted version of Jmeter in a preset manner After the deployment result is obtained by mirroring, the Jmeter-based distributed performance testing method further includes:

   Determining whether the deployment result is a target value, where the target value is used to indicate successful deployment of the predicted version of the Jmeter image;

   If the deployment result is not the target value, redeploy;

   If the deployment result is the target value, it is determined that the deployment is successful.
5. According to the Jmeter-based distributed performance testing method according to claim 3, when the master node receives a test start instruction, sending the corresponding test script to each slave node through the master node comprises:

   Setting the master node as a client for remote method invocation RMI;

   Setting each slave node as the RMI server;

   When the master node receives a test start instruction, execute a test plan through the master node, the test plan including total test data and test scripts;

   Parse the control list of the master node to obtain configuration information corresponding to each slave node;

   Split the total test data according to the configuration information corresponding to each slave node to obtain the test data corresponding to each slave node;

   Replacing keywords in the test script according to the test data corresponding to each slave node to obtain the respective corresponding test script;

   Push the corresponding test script to each slave node through the master node in the RMI manner.
6. According to the Jmeter-based distributed performance testing method of claim 5, when each slave node receives the respective corresponding test script, performing a performance test through each slave node to obtain respective corresponding test results includes:

   When each slave node receives the respective corresponding test script, each slave node analyzes the respective corresponding test script to obtain the respective corresponding test request;

   Obtain the respective corresponding test results by executing the respective corresponding test requests by each slave node;

   Record the respective corresponding test results through each slave node.
7. The Jmeter-based distributed performance testing method according to claim 1, wherein the predicted version of Jmeter mirror is deployed to distributed nodes, and the distributed node includes a master node and at least one slave node. Distributed performance testing methods also include:

   Uploading the Jmeter image of the predicted version to the image warehouse;

   Perform version management on the predicted version of the Jmeter image by tagging.
8. A distributed performance testing device based on Jmeter, the distributed performance testing device based on Jmeter includes:

   A deployment unit for deploying the predicted version of the Jmeter image to a distributed node, the distributed node including a master node and at least one slave node;

   The control unit, when the master node receives a test start instruction, is configured to send respective corresponding test scripts to each slave node through the master node;

   The test unit, when each slave node receives the respective corresponding test script, is used to perform performance testing through each slave node to obtain respective corresponding test results;

   A sending unit, configured to send the respective corresponding test results to the master node through each slave node;

   The statistical unit is configured to count the respective corresponding test results through the master node to obtain performance test results.
9. The Jmeter-based distributed performance testing device according to claim 8, wherein the deployment unit is used for:

   Select the predicted version of Jmeter mirror from the mirror warehouse;

   Setting the distributed node through an ECS instance of the elastic computing service, the distributed node including the one master node and the at least one slave node;

   Determine whether the Jmeter mirror of the predicted version exists at the same time on the master node and each slave node;

   If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image in a preset manner to obtain the deployment result;

   If the Jmeter image of the predicted version exists at the same time on the master node and each slave node, it is determined that the deployment is successful.
10. According to the Jmeter-based distributed performance testing device of claim 9, the deployment unit is further configured to:

    If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image on the ECS instance to obtain a Jmeter application;

    Run the Jmeter application through the container docker;

    Adding configuration information corresponding to each slave node to the control list of the master node, where the configuration information corresponding to each slave node includes each corresponding IP address and each corresponding port;

    Restart the Jmeter application of the master node to obtain the deployment result.
11. The Jmeter-based distributed performance testing device according to claim 9, wherein the device further comprises a judging unit, specifically configured to:

    Determining whether the deployment result is a target value, where the target value is used to indicate successful deployment of the predicted version of the Jmeter image;

    If the deployment result is not the target value, redeploy;

    If the deployment result is the target value, it is determined that the deployment is successful.
12. According to the Jmeter-based distributed performance testing device of claim 10, the control unit is used for:

    Setting the master node as a client for remote method invocation RMI;

    Setting each slave node as the RMI server;

    When the master node receives a test start instruction, execute a test plan through the master node, the test plan including total test data and test scripts;

    Parse the control list of the master node to obtain configuration information corresponding to each slave node;

    Split the total test data according to the configuration information corresponding to each slave node to obtain the test data corresponding to each slave node;

    Replacing keywords in the test script according to the test data corresponding to each slave node to obtain the respective corresponding test script;

    Push the corresponding test script to each slave node through the master node in the RMI manner.
13. The Jmeter-based distributed performance testing device according to claim 12, wherein the testing unit is used for:

    When each slave node receives the respective corresponding test script, each slave node analyzes the respective corresponding test script to obtain the respective corresponding test request;

    Obtain the respective corresponding test results by executing the respective corresponding test requests by each slave node;

    Record the respective corresponding test results through each slave node.
14. A distributed performance test device based on Jmeter. The distributed performance test device based on Jmeter includes a memory and at least one processor, the memory stores instructions, and the memory and the at least one processor are interconnected by wires The at least one processor invokes the instructions in the memory, so that the Jmeter-based distributed performance testing equipment executes the following steps:

    Deploying the predicted version of the Jmeter image to a distributed node, the distributed node including a master node and at least one slave node;

    When the master node receives the test start instruction, sending the corresponding test script to each slave node through the master node;

    When each slave node receives the corresponding test script, perform a performance test through each slave node to obtain respective corresponding test results;

    Sending the respective corresponding test results to the master node through each slave node;

    The respective corresponding test results are counted by the master node to obtain performance test results.
15. The Jmeter-based distributed performance testing device according to claim 14, wherein the at least one processor invokes the instructions in the memory, so that the Jmeter-based distributed performance testing device executes the Jmeter-based When the distributed performance test program is executed by the processor to implement the step of deploying the predicted version of the Jmeter image to the distributed node, and the distributed node includes a master node and at least one slave node, the following steps are also executed:

    Select the predicted version of Jmeter mirror from the mirror warehouse;

    Setting the distributed node through an ECS instance of the elastic computing service, the distributed node including the one master node and the at least one slave node;

    Determine whether the Jmeter mirror of the predicted version exists at the same time on the master node and each slave node;

    If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image in a preset manner to obtain the deployment result;

    If the Jmeter image of the predicted version exists at the same time on the master node and each slave node, it is determined that the deployment is successful.
16. The Jmeter-based distributed performance testing device according to claim 15, wherein the at least one processor invokes the instructions in the memory, so that the Jmeter-based distributed performance testing device executes the The master node and each slave node do not have the predicted version of the Jmeter image at the same time, then the predicted version of the Jmeter image is deployed in a preset manner, and when the deployment result is obtained, the following steps are also performed:

    If the master node and each slave node do not have the predicted version of the Jmeter image at the same time, deploy the predicted version of the Jmeter image on the ECS instance to obtain a Jmeter application;

    Run the Jmeter application through the container docker;

    Adding configuration information corresponding to each slave node to the control list of the master node, where the configuration information corresponding to each slave node includes each corresponding IP address and each corresponding port;

    Restart the Jmeter application of the master node to obtain the deployment result.
17. The Jmeter-based distributed performance testing device according to claim 15, wherein the at least one processor invokes the instructions in the memory, so that the Jmeter-based distributed performance testing device executes the The master node and each slave node do not have the predicted version of the Jmeter image at the same time, then the predicted version of the Jmeter image is deployed in a preset manner, and after the step of obtaining the deployment result, the following steps are performed:

    Determining whether the deployment result is a target value, where the target value is used to indicate successful deployment of the predicted version of the Jmeter image;

    If the deployment result is not the target value, redeploy;

    If the deployment result is the target value, it is determined that the deployment is successful.
18. 16. The Jmeter-based distributed performance testing device according to claim 16, wherein the at least one processor calls the instructions in the memory so that the Jmeter-based distributed performance testing device executes the current When the master node receives the start test instruction, when the master node sends the corresponding test script to each slave node through the master node, the following steps are also performed:

    Setting the master node as a client for remote method invocation RMI;

    Setting each slave node as the RMI server;

    When the master node receives a test start instruction, execute a test plan through the master node, the test plan including total test data and test scripts;

    Parse the control list of the master node to obtain configuration information corresponding to each slave node;

    Split the total test data according to the configuration information corresponding to each slave node to obtain the test data corresponding to each slave node;

    Replacing keywords in the test script according to the test data corresponding to each slave node to obtain the respective corresponding test script;

    Push the corresponding test script to each slave node through the master node in the RMI manner.
19. The Jmeter-based distributed performance testing device according to claim 18, wherein the at least one processor calls the instructions in the memory, so that the Jmeter-based distributed performance testing device executes each slave When the nodes receive the respective corresponding test scripts, perform the performance test through each slave node, and obtain the respective corresponding test results, they also perform the following steps:

    When each slave node receives the respective corresponding test script, each slave node analyzes the respective corresponding test script to obtain the respective corresponding test request;

    Obtaining the respective corresponding test results by executing the respective corresponding test requests by each slave node;

    Record the corresponding test results through each slave node.
20. A computer-readable storage medium having computer-readable instructions stored thereon, and when the computer-readable instructions are executed by a processor, the following steps are implemented:

    Deploying the predicted version of the Jmeter image to a distributed node, the distributed node including a master node and at least one slave node;

    When the master node receives the test start instruction, sending the corresponding test script to each slave node through the master node;

    When each slave node receives the corresponding test script, perform a performance test through each slave node to obtain respective corresponding test results;

    Sending the respective corresponding test results to the master node through each slave node;

    The respective corresponding test results are counted by the master node to obtain performance test results.

Images