Server performance test method and device based on docker containerization

Abstract

The invention discloses a server performance test method and device based on docker containerization, a server is communicated with a workstation through network data, the workstation is provided with a docker platform, the test method comprises the following steps: starting a docker platform engine of the workstation, respectively running preset test scripts on the basis of a plurality of containers of the docker platform, and starting the docker platform engine of the workstation; the preset test script is used for simulating data communication between the client and the server; obtaining a running state detection parameter result of the server; and evaluating the performance of the server based on the running state detection parameter result. By creating a plurality of containers on the docker platform, concurrent access conditions of clients of different scales can be easily simulated, a high-performance physical machine does not need to be relied on to deal with large-scale concurrent test requirements, only a corresponding number of containers need to be started as required, the running states of servers in various scale scenes can be simulated more truly, and the test efficiency is improved. And a test result is more suitable for an actual application scene.

Description

Technical Field

[0001] The present invention relates to the technical field of server testing, and in particular to a server performance testing method and device based on Docker containerization. Background Art

[0002] With the rapid development of information technology, servers play a critical role in various enterprises and Internet services. The performance of servers directly affects many important aspects such as service quality, response speed, and user experience. Therefore, accurate and efficient testing of server performance has become an important research and practice topic in the field of information technology.

[0003] In traditional server performance testing methods, it is usually necessary to deploy a large number of test tools and environments on physical machines, which faces many problems. First, the construction and configuration of the physical machine environment is often complex and time-consuming, requiring the installation of numerous dependent software, library files, and complex network settings, which not only increases the pre-test preparation time, but also easily leads to inaccurate test results due to differences in environment configuration. For example, different physical machines may cause inconsistent behavior of the test tools running on them due to factors such as operating system versions and conflicts in installed software, thereby affecting the reliability of server performance evaluation. Secondly, the scalability of traditional testing methods is poor. When it is necessary to simulate large-scale concurrent client access to the server, a large number of test processes or threads need to be started on the physical machine, which places extremely high demands on the hardware resources of the physical machine (such as CPU, memory, network bandwidth, etc.). Often, in order to meet the test requirements, expensive high-performance physical machine equipment has to be purchased, which undoubtedly increases the test cost. Moreover, even if you have a high-performance physical machine, you may not be able to truly simulate the operation of the server in a super-large-scale concurrent scenario due to hardware resource limitations, resulting in a large deviation between the test results and the server performance in the actual application scenario. Furthermore, traditional testing methods have difficulties in the migration and reuse of test environments. Once the test environment is built on a physical machine, if you want to migrate it to another environment for retesting or share the test environment with other teams, you almost have to rebuild the entire environment, which not only wastes a lot of time and energy, but also easily introduces new configuration errors, further affecting the accuracy and efficiency of the test.

[0004] In summary, traditional server performance testing methods are difficult to meet the needs of efficient, accurate, low-cost and flexible scalability for server performance testing in today's rapidly developing information technology field due to the complexity of the physical machine environment, poor scalability and difficulty in migrating and reusing the test environment. Summary of the invention

[0005] The purpose of the embodiments of the present invention is to provide a server performance testing method and device based on docker containerization. By creating several containers on the docker platform, it is easy to simulate concurrent access situations of clients of different scales. There is no need to rely on expensive high-performance physical machines to cope with large-scale concurrent testing requirements. It is only necessary to start the corresponding number of containers on demand. It can more realistically simulate the operating status of servers in various scale scenarios, making the test results more in line with actual application scenarios.

[0006] To solve the above technical problems, a first aspect of an embodiment of the present invention provides a server performance testing method based on Docker containerization, wherein the server is connected to a workstation via network data, and the workstation is provided with a Docker platform, and the testing method comprises the following steps:

[0007] Starting the docker platform engine of the workstation, and running preset test scripts based on a plurality of containers of the docker platform respectively, wherein the preset test scripts are used to simulate data connection between the client and the server;

[0008] Obtaining the running status detection parameter results of the server;

[0009] Based on the running status detection parameter results, the performance of the server is evaluated.

[0010] Furthermore, before starting the docker platform engine of the workstation, the process includes:

[0011] Creating the plurality of containers based on the Docker platform, each of the containers simulating one of the clients;

[0012] The network configuration parameters of the plurality of containers are configured respectively, and a network connection between each of the containers and the server is established.

[0013] Furthermore, the network configuration parameters of the container include: IP address, subnet mask and gateway.

[0014] Furthermore, the plurality of containers based on the Docker platform respectively run preset test scripts, including:

[0015] Each container is controlled to run the preset test script to simulate the client sending an HTTP request to the server, making a Socket connection, and performing a database query.

[0016] Furthermore, after controlling each of the containers to run the preset test script, the method further includes:

[0017] By adjusting the concurrency number and request frequency of the preset test script, the server is simulated to test the corresponding different loads.

[0018] Furthermore, the operating status detection parameters include: CPU usage, memory occupancy, network throughput and response time.

[0019] Furthermore, the server and the workstation are connected via an Overlay network or a MacVLAN network data connection.

[0020] Accordingly, a second aspect of an embodiment of the present invention provides a server performance testing device based on docker containerization, wherein the server is connected to a workstation via network data, the workstation is provided with a docker platform, and the testing device comprises:

[0021] A script running module, which is used to start the docker platform engine of the workstation and respectively run preset test scripts based on several containers of the docker platform, wherein the preset test scripts are used to simulate data connection between the client and the server;

[0022] A data acquisition module, which is used to obtain the operating status detection parameter results of the server;

[0023] The performance evaluation module is used to evaluate the performance of the server based on the running status detection parameter results.

[0024] Accordingly, a third aspect of an embodiment of the present invention provides an electronic device, comprising: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor executes the above-mentioned server performance testing method based on Docker containerization.

[0025] Accordingly, a fourth aspect of an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-mentioned server performance testing method based on Docker containerization.

[0026] The above technical solution of the embodiment of the present invention has the following beneficial technical effects:

[0027] 1. The Docker platform avoids the complex and time-consuming software installation and network settings required to build a traditional physical machine environment. It can quickly start containers and run preset test scripts, significantly shortening the pre-test preparation time and improving overall test efficiency.

[0028] 2. By creating several containers on the Docker platform, you can easily simulate concurrent access by clients of different scales. You don’t need to rely on expensive high-performance physical machines to cope with large-scale concurrent testing requirements. You only need to start the corresponding number of containers on demand. This can more realistically simulate the running status of servers in various scale scenarios, making the test results more in line with actual application scenarios.

[0029] 3. Based on the characteristics of Docker containerization, the test environment exists in the form of containers, which is convenient for migration between different workstations and other environments, and it is also easy to share the test environment with other teams. There is no need to rebuild the entire environment as in traditional methods, which reduces errors caused by reconfiguration and ensures the accuracy and consistency of the test;

[0030] 4. The preset test script simulates the data connection between the client and the server in the container, obtains the server operation status detection parameter results and then performs performance evaluation. The entire process is carried out in a relatively standardized, isolated and easy-to-control Docker container environment, which reduces external environmental interference factors and makes the final evaluation results of server performance more accurate and reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is a flow chart of a server performance testing method based on Docker containerization provided by an embodiment of the present invention;

[0032] Figure 2 It is a schematic diagram of the system architecture principle provided by an embodiment of the present invention;

[0033] Figure 3 It is a module block diagram of a server performance testing device based on Docker containerization provided by an embodiment of the present invention.

[0034] Reference numerals:

[0035] 1. Script running module, 2. Data acquisition module, 3. Performance evaluation module. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention is further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings. It should be understood that these descriptions are only exemplary and are not intended to limit the scope of the present invention. In addition, in the following description, the description of well-known structures and technologies is omitted to avoid unnecessary confusion of the concept of the present invention.

[0037] Please refer to Figure 1 and Figure 2The first aspect of the embodiment of the present invention provides a server performance testing method based on Docker containerization, wherein the server is connected to a workstation via network data, and the workstation is provided with a Docker platform, and the testing method comprises the following steps:

[0038] Step S200, start the docker platform engine of the workstation, and run preset test scripts based on several containers of the docker platform respectively. The preset test scripts are used to simulate data connectivity between the client and the server.

[0039] When starting the Docker platform engine, you must first ensure that Docker has been correctly installed on your workstation and that the relevant configurations are correct. During the startup process, the system will load the core components of the Docker engine, including the daemon, which is responsible for managing the entire life cycle of the container and its interaction with the outside world, such as allocating system resources to the container to be created, such as CPU cores, memory space, etc.

[0040] The prediction test script can implement complex interactive logic and data communication protocols according to business needs. Specifically, golang code can be used to implement TCP connection with the server, and the protobuf protocol can be used to respond to the server's instructions and report data.

[0041] Step S300, obtaining the server's operating status detection parameter results.

[0042] After receiving the request from the container simulation client, the server's operating system, application, etc. will undergo a series of operating status changes. By deploying performance monitoring tools on the server side or using the server's own monitoring function, you can obtain parameter results such as CPU usage, memory usage, disk I / O rate, network bandwidth usage, application response time distribution, and number of requests processed per second (TPS).

[0043] For example, for CPU usage monitoring, the usage of each core can be accurately determined, and the CPU load balancing of the server when processing different types of requests can be understood. The detection of memory usage can reflect the consumption of memory resources during the operation of the server, and whether there are problems such as memory leaks. The disk I / O rate is particularly important for application servers that involve large amounts of data storage and reading, and can reflect the performance of the server when processing data persistence operations. The network bandwidth usage rate can indicate whether there is a bottleneck in the data transmission between the server and the outside world (including the container simulating the client). The response time distribution of the application can intuitively show how fast the server processes different requests, and whether there are abnormally slow responses. TPS can reflect the number of requests that the server can handle per unit time as a whole, and is a key indicator for measuring server performance. The client can simulate various business logic scenarios, receive control instructions from the server based on specific business logic, and execute data reporting logic.

[0044] Step S400, evaluating the performance of the server based on the running status detection parameter results.

[0045] Compare and analyze the obtained server operation status detection parameter results with the pre-set performance standards or benchmark values. For example, if the set CPU usage benchmark value should not exceed 80% under long-term high-load testing, but the CPU usage in the actual test results is continuously higher than 90%, it means that the server may have a CPU performance bottleneck when processing the current simulated client load.

[0046] Consider multiple parameter results to comprehensively evaluate server performance. For example, even if the CPU and memory usage are within a reasonable range, if the network bandwidth usage is close to saturation and the application response time is long, it may indicate that there is a problem with the network configuration or network equipment that affects the overall performance of the server.

[0047] By weighted analysis of the results of these parameters or establishing a performance evaluation model, we can obtain the performance scores of the server in different aspects (such as computing power, storage capacity, network communication capacity, etc.), and ultimately give an evaluation conclusion of the overall performance of the server to determine whether the server can meet the expected business needs and which aspects need to be optimized or upgraded.

[0048] In addition, after the test is completed, the results can be analyzed. The server can issue control instructions, collect the execution results of the preset test scripts, and count the data volume and total data reporting of each client.

[0049] Furthermore, before starting the docker platform engine of the workstation in step S200, the following steps are included:

[0050] Step S110, creating several containers based on the Docker platform, each container simulating a client.

[0051] Create several containers based on the Docker platform. These containers are isolated from each other but share the operating system kernel of the workstation. When creating a container, you can specify the resource limits of the container, such as the maximum memory usage, the upper limit of CPU usage, etc., so as to have more precise control when simulating different client load scenarios. For example, you can create a group of containers with a memory limit of 512MB to simulate low-configuration clients, and another group of containers with a memory limit of 2GB to simulate medium-configuration clients.

[0052] For each container, run the preset test script. These test scripts are written according to the needs of server performance testing and can simulate various requests initiated by the client to the server, such as HTTP requests, database query requests, file upload and download requests, etc. For example, a test script that simulates an e-commerce website client may send product browsing requests, shopping cart add requests, order requests, etc. at a certain time interval, and the number of concurrent requests can be set. During the operation, the script in the container will establish a network connection with the server, send data according to the set rules and wait for the server to respond, and record information such as response time and accuracy of returned data. This information will serve as an important basis for subsequent evaluation of server performance.

[0053] Step S120: configure network configuration parameters of several containers respectively, and establish a network connection between each container and the server.

[0054] When configuring the network configuration parameters of the container, you must first determine the network mode of the container. Common network modes include bridge mode (Bridge), host mode (Host) and container network mode (Container). If you choose the bridge mode, the container will be connected to a virtual bridge in the local area network where the workstation is located, and will be assigned an independent IP address in the same network segment as the workstation. In this way, the container can communicate with the server like other real devices in the local area network. For example, the network segment of the workstation's network is 192.168.1.0 / 24, and the created container may be assigned an IP address such as 192.168.1.100, and then establish a network connection based on the TCP / IP protocol with the server through this IP address.

[0055] In addition to the allocation of IP addresses, network parameters such as subnet mask and gateway also need to be configured. The subnet mask is used to determine the subnet range where the container is located, and the gateway is the exit address for the container to access other subnets or external networks. For example, the subnet mask is set to 255.255.255.0 and the gateway is set to 192.168.1.1 to route data packets to the network where the server is located.

[0056] For some special network requirements, you may also need to configure port mapping. If a service on the server runs on a specific port (such as a Web service running on port 80), and the container needs to forward through a port on the workstation when accessing it, you need to set up port mapping rules. For example, map the request to access port 80 of the server from within the container to port 8080 of the workstation, so that accessing port 8080 of the workstation in the container is equivalent to accessing port 80 of the server, thereby establishing a correct network connection and ensuring that the test script can smoothly interact with the server for data.

[0057] In a specific implementation of the embodiment of the present invention, the network configuration parameters of the container include: an IP address, a subnet mask, and a gateway.

[0058] Furthermore, in step S200, several containers based on the Docker platform respectively run preset test scripts, including:

[0059] Step S210, controlling each container to run a preset test script, simulating the client sending an HTTP request to the server, making a Socket connection, and performing a database query.

[0060] When the container runs the preset test script, for simulating sending HTTP requests, the test script will construct the request message according to the HTTP protocol specification. For example, it sets the request method (such as GET, POST, PUT, DELETE, etc.), determines the target URL of the request (that is, the specific resource path on the server), and may add header information to the request message, such as user authentication information, content type, etc. Taking an HTTP POST request that simulates user login as an example, the script will place login data such as username and password in the request body in a specific format (such as JSON or form data format), and then send it to the server's login interface.

[0061] When simulating a socket connection, the script in the container will create a socket object, specify the server's IP address and port number, and try to establish a connection with the server based on the TCP or UDP protocol. Once the connection is successfully established, data can be transmitted on the connection. For example, for a simulation of a real-time chat application, the client container sends chat messages to the server through a socket connection, and the server then forwards the messages to the clients represented by other related client containers.

[0062] For database query simulation, the test script will use the corresponding database driver (such as MySQL driver, Oracle driver, etc.) to connect to the database on the server, build SQL query statements, such as SELECT, INSERT, UPDATE, DELETE and other operation statements, and then execute these queries and obtain results. For example, to simulate an e-commerce system client querying product information, the script will execute a query statement like "SELECT * FROM products WHERE category = 'electronic s'" to obtain product data in the electronic product category from the database, and record the query response time, the amount of data returned, and other information, so as to subsequently evaluate the server's performance in database operations.

[0063] Furthermore, after controlling each container to run a preset test script in step S210, the method further includes:

[0064] Step S220, adjusting the concurrency and request frequency of the preset test script to simulate the server to test the corresponding different loads.

[0065] Adjusting the concurrency number means controlling the number of containers that run test scripts at the same time or the number of threads or processes that initiate requests at the same time in a single container. For example, the number of containers that run test scripts at the same time (representing 10 clients accessing concurrently) can be increased gradually to 100 containers to observe the performance of the server under different concurrent loads. In the process of increasing the concurrency number, the usage of the server's CPU, memory, network and other resources will change. By monitoring these changes, the maximum concurrency that the server can withstand can be determined.

[0066] Changing the request frequency means adjusting the number of requests sent by each container or each thread / process per unit time. For example, adjusting the request frequency of each container from 1 time per second to 10 times per second can simulate the impact of changes in client behavior on server performance. Different request frequencies may cause the server to exhibit different characteristics in processing request queues and resource scheduling. By analyzing the results of server operation status detection parameters under different request frequencies, the performance stability and responsiveness of the server under different load modes can be evaluated. For example, whether the server will have long response delays under high-frequency requests, or resource exhaustion leading to the failure of some requests, etc.

[0067] Optionally, the running status detection parameters include: CPU usage, memory usage, network throughput, and response time.

[0068] In an optional implementation of the embodiment of the present invention, a comprehensive score is obtained through a calculation formula based on the detection values ​​of the four parameters, and the comprehensive score = (CPU usage score × k1 + memory occupancy score × k2 + network throughput score * k3 + response time score × k4) / 4. Among them, k1, k3, k3, k4 are the weights of each indicator, and they can all be used as 1 by default, or they can be adjusted according to business requirements; for example, for data transmission, the influence of k3 network and the weight of k2 memory usage can be increased, and for computing intensive, k1 can be increased; k4 can be increased if timely response is required, etc.

[0069] The score of each indicator can be determined by comparing its detection value with a preset threshold. For example, the following thresholds can be set:

[0070] CPU usage: ≤50% is excellent, 50% to 70% is good, and above 70% is poor;

[0071] Memory usage: ≤50% is excellent, 50% to 70% is good, and 70% is poor;

[0072] Network throughput: ≤30% maximum throughput is excellent, 30% to 50% is good, and more than 50% is poor (maximum throughput refers to the maximum data transmission rate of a network device or link without failure);

[0073] Response time: ≤100ms is excellent, 100ms-500ms is good, 500ms-1000ms is poor, and ≥1000ms is extremely poor;

[0074] Based on the above content, each indicator can be divided into different scoring ranges according to the comparison results between the detection value and the threshold, for example, excellent is 4 points, good is 3 points, poor is 2 points, and extremely bad is 1 point (or other scoring rules can be set according to actual needs).

[0075] Specifically, the server and the workstation are connected via an Overlay network or a MacVLAN network data connection.

[0076] Overlay network is an overlay network that allows a virtual network to be created between different Docker hosts (the workstation here can be regarded as one of the hosts), so that containers can communicate across hosts and are independent of the underlying network infrastructure. Cross-host transmission is achieved by encapsulating additional information in network packets, usually using tunneling technologies such as VXLAN (Virtual eXtensible Local Area Network). For example, when a container sends data to a server on another host on a workstation, the data is encapsulated in a VXLAN packet, transmitted to the target host through the underlying physical network, and then decapsulated on the target host and forwarded to the corresponding container or server.

[0077] When configuring an Overlay network, you need to first create an Overlay network in the Docker cluster environment. For example, you can use the docker network create-d overlay myoverlay command to create an Overlay network named myoverlay. Then, when starting the container, connect the container to this Overlay network. For the server, if it is also running in a Docker environment, it can also be connected to this Overlay network, so that the server and the container on the workstation can communicate in this virtual Overlay network space. In this network, containers and servers have their own IP addresses in the Overlay network. They interact with data through these IP addresses, just like in the same LAN, without having to worry about the topology of the underlying physical network and the allocation of IP addresses.

[0078] In addition, MacVLAN networking allows containers to be directly connected to the host's physical network interface. Containers have independent MAC addresses in the network and look like independent physical devices in the network. Virtual sub-interfaces are created based on the physical network interface. Each sub-interface corresponds to a container. The container communicates with the server through these sub-interfaces. For example, the physical network card of the workstation is connected to the LAN. Through the MacVLAN network configuration, an IP address and an independent MAC address in the same network segment as the LAN are assigned to each container. The container can directly participate in the communication within the LAN, including communication with the server.

[0079] Accordingly, please refer to Figure 3 The second aspect of the embodiment of the present invention provides a server performance test device based on docker containerization, the server is connected to the workstation through network data, the workstation is provided with a docker platform, and the test device includes:

[0080] The script running module 1 is used to start the docker platform engine of the workstation, and respectively run preset test scripts based on several containers of the docker platform, wherein the preset test scripts are used to simulate data connection between the client and the server;

[0081] Data acquisition module 2, which is used to obtain the running status detection parameter results of the server;

[0082] The performance evaluation module 3 is used to evaluate the performance of the server based on the running status detection parameter results.

[0083] Accordingly, a third aspect of an embodiment of the present invention provides an electronic device, comprising: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor executes the above-mentioned server performance testing method based on Docker containerization.

[0084] Accordingly, a fourth aspect of an embodiment of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-mentioned server performance testing method based on Docker containerization.

[0085] The embodiment of the present invention aims to protect a server performance testing method and device based on docker containerization. The server and the workstation are connected through network data. The workstation is provided with a docker platform. The testing method includes the following steps: starting the docker platform engine of the workstation, running preset test scripts based on several containers of the docker platform respectively, and the preset test scripts are used to simulate data connection between the client and the server; obtaining the server's operating status detection parameter results; and evaluating the server's performance based on the operating status detection parameter results. The above technical solution has the following effects:

[0086] 1. The Docker platform avoids the complex and time-consuming software installation and network settings required to build a traditional physical machine environment. It can quickly start containers and run preset test scripts, significantly shortening the pre-test preparation time and improving overall test efficiency.

[0087] 2. By creating several containers on the Docker platform, you can easily simulate concurrent access by clients of different scales. You don’t need to rely on expensive high-performance physical machines to cope with large-scale concurrent testing requirements. You only need to start the corresponding number of containers on demand. This can more realistically simulate the running status of servers in various scale scenarios, making the test results more in line with actual application scenarios.

[0088] 3. Based on the characteristics of Docker containerization, the test environment exists in the form of containers, which is convenient for migration between different workstations and other environments, and it is also easy to share the test environment with other teams. There is no need to rebuild the entire environment as in traditional methods, which reduces errors caused by reconfiguration and ensures the accuracy and consistency of the test;

[0089] 4. The preset test script simulates the data connection between the client and the server in the container, obtains the server operation status detection parameter results and then performs performance evaluation. The entire process is carried out in a relatively standardized, isolated and easy-to-control Docker container environment, which reduces external environmental interference factors and makes the final evaluation results of server performance more accurate and reliable.

[0090] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0091] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0092] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0093] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0094] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A server performance testing method based on Docker containerization, characterized in that: The server is connected to the workstation via network data, the workstation is provided with a docker platform, and the testing method comprises the following steps: Starting the docker platform engine of the workstation, and running preset test scripts based on a plurality of containers of the docker platform respectively, wherein the preset test scripts are used to simulate data connection between the client and the server; Obtaining the running status detection parameter results of the server; Based on the running status detection parameter results, the performance of the server is evaluated.

2. The server performance testing method based on Docker containerization according to claim 1 is characterized in that: Before starting the docker platform engine of the workstation, the process includes: Creating the plurality of containers based on the Docker platform, each of the containers simulating one of the clients; The network configuration parameters of the plurality of containers are configured respectively, and a network connection between each of the containers and the server is established.

3. The server performance testing method based on Docker containerization according to claim 2 is characterized in that: The network configuration parameters of the container include: IP address, subnet mask and gateway.

4. The server performance testing method based on Docker containerization according to claim 1 is characterized in that: The plurality of containers based on the Docker platform respectively run preset test scripts, including: Each container is controlled to run the preset test script to simulate the client sending an HTTP request to the server, making a Socket connection, and performing a database query.

5. The server performance testing method based on Docker containerization according to claim 4 is characterized in that: After controlling each of the containers to run the preset test script, the method further includes: By adjusting the concurrency number and request frequency of the preset test script, the server is simulated to test the corresponding different loads.

6. The server performance testing method based on Docker containerization according to any one of claims 1 to 5, characterized in that: The operating status detection parameters include: CPU usage, memory occupancy, network throughput and response time.

7. The server performance testing method based on Docker containerization according to any one of claims 1 to 5, characterized in that: The server and the workstation are connected via an Overlay network or a MacVLAN network data connection.

8. A server performance testing device based on Docker containerization, characterized in that: The server is connected to the workstation via network data. The workstation is provided with a docker platform. The testing device includes: A script running module, which is used to start the docker platform engine of the workstation and respectively run preset test scripts based on several containers of the docker platform, wherein the preset test scripts are used to simulate data connection between the client and the server; A data acquisition module, which is used to obtain the operating status detection parameter results of the server; The performance evaluation module is used to evaluate the performance of the server based on the running status detection parameter results.

9. An electronic device, characterized in that: include: at least one processor; And a memory connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor executes the server performance testing method based on Docker containerization as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: Computer instructions are stored thereon, and when the instructions are executed by a processor, a server performance testing method based on Docker containerization as described in any one of claims 1 to 7 is implemented.

Images