Performance test system of NFS (Network File System)

Abstract

The invention provides a performance test system of an NFS (Network File System), which comprises a plurality of slave node software and a master node software, and the master node software is used for establishing communication connection with each slave node software after being started, issuing a performance test task to the slave node software through the communication connection with each slave node software according to the test scheme; the slave node software is used for executing a performance test on an NFS file system on the NFS client equipment after receiving the performance test task, and recording performance data obtained by the test; after the test is completed, the performance data is transmitted back to the main node software through the communication connection with the main node software; and the master node software is also used for summarizing the performance data returned by the slave node software to obtain a test result file of the NFS file system. The invention provides a system for testing an NFS (Network File System).

Description

Technical Field

[0001] The present invention relates to the technical field of file systems, and in particular to a performance testing system for an NFS file system. Background Art

[0002] As a network sharing file system, NFS file system aims to realize transparent sharing of files and directories between multiple client devices through network interfaces. In actual application scenarios, multiple clients often mount the same NFS file system at the same time to achieve efficient and real-time data interaction and collaborative work. Therefore, it is necessary to test the performance of NFS file system, and it is necessary to provide a system for performance testing of NFS file system. NFS is the abbreviation of Network File System, that is, network file system. Summary of the invention

[0003] In view of at least one of the above technical problems, an embodiment of the present invention provides a performance testing system for an NFS file system.

[0004] The NFS file system performance test system provided by the embodiment of the invention includes multiple slave node software and one master node software, each slave node software is deployed on an NFS client device, and the master node software is deployed on an independent management node, wherein:

[0005] The master node software is used to: after startup, establish a communication connection with each slave node software, and issue a performance test task to the slave node software through the communication connection with each slave node software according to the test plan;

[0006] The slave node software is used to: after receiving the performance test task, perform a performance test on the NFS file system on the NFS client device, and record the performance data obtained by the test; after the test is completed, transmit the performance data back to the master node software through the communication connection with the master node software;

[0007] The master node software is also used to: summarize the performance data returned by each slave node software to obtain a test result file of the NFS file system.

[0008] In one embodiment, the communication connection between the master node software and each slave node software is a long connection based on the TCP protocol.

[0009] In one embodiment, the master node adopts IO multiplexing technology, and the IO multiplexing technology is to use one thread to be responsible for multiple long connections based on the TCP protocol; the master node software is configured with a parent thread pool, and the parent thread pool has a thread, and the threads in the parent thread pool are used to manage the establishment and closing of the long connections based on the TCP protocol; each slave node software is configured with a child thread pool, and the child thread pool has a thread, and the threads in the child thread pool are used to logically manage the performance test process of the NFS file system on the corresponding NFS client device.

[0010] In one embodiment, the master node software is also used to: enable a dead connection detection mechanism after establishing a long connection based on the TCP protocol with each slave node software; after the dead connection detection mechanism is started, the master node software periodically sends a detection data packet to each slave node software through a long connection based on the TCP protocol, and determines whether the slave node software is in an active state based on whether a feedback message from the slave node software is received; if it is determined that the slave node software is not in an active state, close the long connection based on the TCP protocol between the master node software and the slave node software.

[0011] In one embodiment, the master node software is further used to: serialize the performance test task into JSON format; correspondingly, the master node software sends the performance test task serialized into JSON format to each slave node software;

[0012] The slave node software is also used to: serialize the performance data obtained from the test into JSON format; correspondingly, the slave node software returns the performance data serialized into JSON format to the master node software.

[0013] In one embodiment, the slave node software is further used to: decode the performance test task issued by the master node software using a JSON decoder, and after decoding to obtain a complete performance test task, perform a performance test on the NFS file system on the NFS client device;

[0014] The master node software is also used to: use a JSON decoder to decode the performance data sent back by each slave node software, and after decoding to obtain complete performance data, use the performance data in the aggregation work.

[0015] In one embodiment, the NFS file system is deployed in a container of an NFS client device; the master node software is deployed in a container of the independent management node, and the slave node software is deployed in a container of the NFS client device.

[0016] In one embodiment, the master node software is specifically used to: load a configuration file after startup, wherein the configuration file defines relevant configuration information of the NFS file system and configuration parameters of the performance test task in YAML format; establish a communication connection with each slave node software according to the configuration file, and send performance test tasks to the slave node software through the communication connection with each slave node software according to the test plan.

[0017] In one embodiment, the configuration file includes at least one of the following:

[0018] The target field is used to define the target NFS file system for this test;

[0019] The parameter field is used to define the mount-related parameters of the target NFS file system;

[0020] The node field is used to define the relevant information of each slave node software, including the IP address and NFS file mount point of the slave node software;

[0021] Workload related fields, used to define the configuration information of the workload generator and the workload type;

[0022] The Script field is used to define the test script that needs to be run when performing performance testing.

[0023] In one embodiment, the slave node software is used to run a performance testing program; wherein the performance testing program includes a running method and an output result method, the running method is used to execute the test script and serialize the performance data obtained from the test; the output result method is used to transmit the serialized performance data back to the master node software.

[0024] The performance test system of the NFS file system provided by the embodiment of the present invention includes a plurality of slave node software and a master node software. The master node software establishes a communication connection with each slave node software after startup, and sends a performance test task to the slave node software through the communication connection with each slave node software according to the test plan, so that after receiving the performance test task, the slave node software performs a performance test on the NFS file system on the NFS client device where it is located, and records the performance data obtained by the test; after the test is completed, the performance data is returned to the master node software through the communication connection with the master node software. The master node software summarizes the performance data returned by each slave node software to obtain the test result file of the NFS file system. It can be seen that the master-slave architecture is adopted in the embodiment of the present invention, the master node software is responsible for overall management, task allocation and result aggregation, and the slave node software executes the test task and feeds back the result. The test process covers the complete sequence of master-slave node software deployment, master node software startup, task issuance, task execution and result feedback. It can be seen that the embodiment of the present invention provides a system for testing the NFS file system. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A structural block diagram of a performance test system for an NFS file system according to an embodiment of the present invention;

[0026] Figure 2 Based on Figure 1 Schematic diagram of the performance test process for the NFS file system. DETAILED DESCRIPTION

[0027] In a first aspect, an embodiment of the present invention provides a performance testing system for an NFS file system. Figure 1 and Figure 2 The performance testing system includes a plurality of slave node software and a master node software, each slave node software is deployed on an NFS client device, and the master node software is deployed on an independent management node, wherein:

[0028] The master node software is used to: after startup, establish a communication connection with each slave node software, and issue a performance test task to the slave node software through the communication connection with each slave node software according to the test plan;

[0029] The slave node software is used to: after receiving the performance test task, perform a performance test on the NFS file system on the NFS client device, and record the performance data obtained by the test; after the test is completed, transmit the performance data back to the master node software through the communication connection with the master node software;

[0030] The master node software is also used to: summarize the performance data returned by each slave node software to obtain a test result file of the NFS file system.

[0031] It can be seen that the performance test system adopts a master-slave architecture mode, with a centrally coordinated master node software and multiple slave node software for response execution. The master node software plays the role of a command center in this architecture, and assumes the core responsibilities of coordinating and managing the slave node software, allocating performance test tasks, and aggregating and analyzing test data. The slave node software, as an execution unit, focuses on receiving and following the instructions of the master node software to execute performance test tasks and feedback the test progress and results.

[0032] See also Figure 2 , a complete performance testing process generally includes the following steps:

[0033] 1. Deploy the master node software and slave node software: First, deploy and start the slave node software on all NFS client devices participating in the test. Deploy the master node software on the independent management node. These slave node software are on standby at any time to receive and execute the performance test tasks issued by the master node software.

[0034] 2. Start the master node: Start the master node software on the independent management node. After the master node software is started, it immediately establishes a communication connection with each slave node software to prepare for subsequent task scheduling.

[0035] 3. Issue test tasks: The master node software distributes performance test tasks to each slave node software according to the preset test plan. These performance test tasks can include file read and write operations, directory traversal, permission verification, etc., aiming to comprehensively examine the performance indicators of the NFS file system.

[0036] 4. Execute the test task: The slave node software that receives the performance test task immediately starts to execute the specified performance test task. In this stage, the slave node software strictly follows the test specifications, simulates real user operations or system behaviors, and monitors and records relevant performance data of the NFS file system.

[0037] 5. Feedback and summary results: After the slave node software is executed, the slave node software will send the test results, i.e., performance data report, back to the master node software. After receiving the test results of all slave node software, the master node software will summarize and output them into the test result file for the technician to view.

[0038] The master node software and slave node software of the performance test system run on different hosts, and the communication between them depends on a stable network environment. There are three feasible solutions to consider when choosing a communication model. These three solutions are as follows:

[0039] Solution 1: In the task delivery phase, the slave node software plays the role of a server, listens to a specific port and waits for the master node software to establish a connection, receives and executes performance test tasks through the HTTP protocol. In the result collection phase, the master node software adopts an active polling strategy and periodically initiates HTTP requests to the slave node software to obtain test progress and results. Although the Java language is relatively convenient for implementing HTTP clients and servers under the Spring framework, long-term polling may result in a large number of invalid requests, and resource consumption cannot be ignored.

[0040] Solution 2: The processing method of the task distribution phase is consistent with Solution 1. In the result reporting phase, the master node software is converted to a server role, also listening to a specific port, waiting for the slave node software to upload the test results through the HTTP protocol. Although this solution does not require the master node software to poll, the master and slave node software must have both server and client identities, and the complexity of the system implementation increases accordingly.

[0041] Solution 3: In the task distribution stage, the master node software establishes a long connection with the slave node software through the TCP protocol, and no longer uses the HTTP protocol, in order to reduce network overhead and improve communication efficiency. The implementation details of this stage are similar to the previous two solutions, with only some adjustments at the protocol level. Entering the result reporting stage, the slave node software uses the established long connection to transmit test data to the master node software instantly and efficiently. The advantages of this solution are: on the one hand, the master node software only needs to act as a TCP client, which simplifies its role positioning; on the other hand, the slave node software only needs to act as a server to receive performance test tasks and return results, with clear division of labor and high resource utilization. In addition, the reuse of long connections effectively avoids the waste of resources caused by polling, making the entire communication process more concise and efficient.

[0042] It can be seen that solution three is the best choice. Therefore, in a preferred embodiment, the communication connection between the master node software and each slave node software is a long connection based on the TCP protocol.

[0043] In the early days of network communication, Java widely adopted the traditional BIO (Blocking I / O) model. This model works in a blocking manner, which means that when a thread processes a TCP connection, it will focus entirely on the operation of the connection until the read and write operations on the connection are completed. Under this mechanism, a thread can only correspond to one TCP connection and cannot handle multiple connection requests at the same time. For a performance test system consisting of several slave node software and a core master node software, the master node software needs to maintain an independent TCP connection with each slave node software to ensure data exchange. Since each connection requires a separate thread to handle, as the number of slave node software increases, the number of TCP connections faced by the master node software also increases, which in turn leads to a surge in thread demand. Creating a large number of threads not only puts significant pressure on system resources such as memory and CPU scheduling, but also may lead to low resource utilization and waste. Especially in high-concurrency scenarios, excessive thread management overhead and context switching costs will seriously restrict the overall performance and scalability of the performance test system. To solve this problem, the performance test system adopts IO multiplexing technology, which allows a single thread to efficiently monitor and process multiple TCP connections at the same time. By aggregating the I / O events of multiple connections into one thread for unified scheduling, the resource consumption of allocating independent threads to each connection is avoided, thereby greatly improving the system's concurrent processing capabilities and resource utilization.

[0044] Netty, as a popular Java language RPC (Remote Procedure Call) framework, happens to provide excellent support for the IO multiplexing model. During initialization, the Netty server configures two dedicated thread pools: one is used to manage the establishment and closing of connections, which can be called the parent thread pool, and the other is focused on processing business logic, which can be called the child thread pool. In view of the specific needs of the performance test system, in order to minimize resource waste and ensure the accuracy of the test results, the configuration of the Netty thread pool was adjusted. First, the parent thread pool size of the master node software is set to 1, because the master node software only needs a single thread to efficiently accept and manage the connection requests of all slave node software without additional thread overhead. Secondly, considering the serial execution requirements of the test task, in order to avoid mutual interference between parallel tasks affecting the test results, the child thread pool of each slave node software is also limited to contain only one thread. This configuration ensures that only one test task is executed for each slave node software at any time, which not only prevents excessive resource allocation, but also maintains the consistency and reliability of the test data.

[0045] That is to say, in one embodiment, the master node can adopt IO multiplexing technology, and the IO multiplexing technology is to use one thread to be responsible for multiple long connections based on the TCP protocol; the master node software is configured with a parent thread pool, and the parent thread pool has a thread, and the threads in the parent thread pool are used to manage the establishment and closing of the long connection based on the TCP protocol; each slave node software is configured with a child thread pool, and the child thread pool has a thread, and the threads in the child thread pool are used to logically manage the performance test process of the NFS file system on the corresponding NFS client device.

[0046] In one embodiment, the master node software can also be used to: enable a dead connection detection mechanism after establishing a long connection based on the TCP protocol with each slave node software; after the dead connection detection mechanism is started, the master node software periodically sends a detection data packet to each slave node software through a long connection based on the TCP protocol, and determines whether the slave node software is in an active state based on whether a feedback message from the slave node software is received; if it is determined that the slave node software is not in an active state, close the long connection based on the TCP protocol between the master node software and the slave node software.

[0047] It is understandable that as a distributed system, the inherent complexity of the performance test system makes network anomalies the norm rather than the exception. These anomalies often lead to sudden interruptions of TCP connections, seriously affecting the stability and continuity of the performance test system. In order to enhance the robustness of the entire system, the master node software and the slave node software enable the keepalive function at the beginning of establishing the TCP connection. Keepalive is a mechanism in TCP that can detect dead connections. The core value of this function is that when the TCP connection is in a state of no data transmission for a certain period of time, the master node software will send a exploratory data packet to the slave node software to detect the validity of the connection. In the performance test system, if the slave node software suddenly goes offline due to its own failure, or encounters network fluctuations that cause the normal termination signal to fail to be successfully transmitted to the master node software, if the keepalive mechanism is not enabled at this time, the original TCP connection will fall into a "pseudo-death" state, and continue to occupy system resources without releasing them. In this case, the master node software will mistakenly believe that the slave node software is still executing the test task, fall into endless waiting, and cannot exit the current task state in time. On the contrary, if the keepalive function is turned on, even if the termination signal is unfortunately lost during the transmission process, the master node software can verify the activity of the slave node software through regularly sent detection messages. If the slave node software is unable to respond due to a fault, after a preset period of time, the master node software will recognize that continuous detection has been fruitless and actively close the TCP connection. In this way, the master node software can detect the abnormal condition of the slave node software in time and mark it as a test failure instead of waiting endlessly, thereby ensuring that the master node software can end the current task according to the expected process and smoothly enter the next work stage, maintaining the efficient operation of the overall system and the smoothness of task flow.

[0048] In one embodiment, the master node software is also used to: serialize the performance test task into JSON format; correspondingly, the master node software sends the performance test task serialized into JSON format to each slave node software; the slave node software is also used to: serialize the performance data obtained from the test into JSON format; correspondingly, the slave node software returns the performance data serialized into JSON format to the master node software.

[0049] It is understandable that when the master node software issues performance test tasks to the slave node software, and when the slave node software feeds back the test execution results to the master node software, the data transmission involved must first undergo the key step of serialization, that is, converting complex structured objects into byte streams that are convenient for network transmission. However, the native serialization mechanism provided by the Java platform is not ideal in terms of performance. Its processing speed is slow, and its consumption of computing resources and network bandwidth is relatively high. In contrast, JSON, as a lightweight text serialization format, reduces CPU and network loads, so the performance testing system chooses JSON as the serialization method to ensure the convenience and consistency of the interaction between performance test tasks and performance test results between the master and slave node software.

[0050] In one embodiment, the slave node software can also be used to: use a JSON decoder to decode the performance test task issued by the master node software, and after decoding to obtain the complete performance test task, perform a performance test on the NFS file system on the NFS client device; the master node software can also be used to: use a JSON decoder to decode the performance data returned by each slave node software, and after decoding to obtain the complete performance data, use the performance data in the aggregation work.

[0051] It is understandable that although the TCP protocol provides reliable data transmission services, the size of its data packets is not arbitrarily adjustable. The capacity of a single TCP data packet has an upper limit, but the size of the performance test task or result data to be transmitted cannot be accurately predicted in advance. When the amount of data is too large, it may exceed the carrying capacity of a single data packet, resulting in the information being divided into multiple data packets for transmission, which is the so-called "packetization" phenomenon. On the contrary, when the amount of data is too small, in order to optimize network efficiency, the operating system may merge multiple small data into one data packet for transmission, which is the so-called "sticky packet" problem. Both of these situations may cause the information received by the receiving end to be incomplete, thereby causing data parsing errors or task execution exceptions. In order to ensure that the complete performance test task is received accurately from the node software and the performance test results are accurately summarized in the master node software, the embodiment of the present invention selects the JSON decoder provided by the Netty framework. This component is designed specifically for processing JSON data in network communications and has anti-sticking and anti-packetization capabilities. Netty's JSON decoder can identify the start and end of JSON objects, ensuring that only one complete JSON object is decoded each time. Therefore, the slave node software will start to execute the test only after receiving the complete performance test task structure, and the master node software will perform subsequent summary and analysis processing only after receiving the complete and correctly structured performance test result data.

[0052] In one embodiment, the NFS file system can be deployed in a container of an NFS client device; the master node software is deployed in a container of the independent management node, and the slave node software is deployed in a container of the NFS client device.

[0053] It is understandable that in the application practice of NFS file system in the industry, its mainstream usage mode has been deeply integrated with the containerized environment. Many enterprises and developers choose to use NFS file system in containers to share the data resources of the same NFS file system between multiple container instances. In order to ensure the rigor and practicality of performance testing, the performance testing system also follows this trend and chooses to build and run in the container environment, so the master node software and slave node software are also deployed in the container.

[0054] In one embodiment, the master node software can be specifically used to: load a configuration file after startup, wherein the configuration file defines relevant configuration information of the NFS file system and configuration parameters of the performance testing task in YAML format; establish a communication connection with each slave node software according to the configuration file, and send performance testing tasks to the slave node software through the communication connection with each slave node software according to the test plan.

[0055] It can be seen that in the initial stage of starting the performance test system, the master node software needs to parse and load the configuration file, which is written in YAML format and defines the relevant setting data of the NFC file system and the specific parameters of the performance test task. Based on the configuration file, it can provide a reference for establishing communication connections and issuing performance test tasks.

[0056] Furthermore, the configuration file may include at least one of the following:

[0057] The target field is used to define the target NFS file system for this test;

[0058] The parameter field is used to define the mount-related parameters of the target NFS file system;

[0059] The node field is used to define the relevant information of each slave node software, including the IP address and NFS file mount point of the slave node software;

[0060] Workload related fields, used to define the configuration information of the workload generator and the workload type;

[0061] The Script field is used to define the test script that needs to be run when performing performance testing.

[0062] For example, the task configuration, as a target field segment, defines the target file system for this performance test. The parameters configuration segment, as a parameter field, lists the detailed parameters related to the NFS file system mount. The workers configuration segment, as a node field, lists the information of the slave node software participating in the test one by one. Each slave node software entry contains its IP address and the corresponding NFS mount point. These configuration segments can guide the master node software on how to assist each slave node software to complete the mount of the target NFS file system and build the infrastructure of the distributed test environment. The workload configuration segment, as a workload-related field, defines the selection and configuration of the workload generator. The provider indicates the type of workload, which can be fio or filebench. The script, as a script field, indicates the test script that needs to be run for the performance test. It can define specific test modes, parameter sets, execution cycles and other details to ensure that the test tool can simulate actual application scenarios and impose expected loads on the target file system, thereby accurately evaluating its performance.

[0063] In one embodiment, the slave node software can be used to run a performance testing program; wherein the performance testing program includes a running method and an output result method, the running method is used to execute the test script and serialize the performance data obtained from the test; the output result method is used to transmit the serialized performance data back to the master node software.

[0064] The performance test program is written in Java. As an object-oriented language, the natively supported polymorphism can more elegantly support multiple load generators. Specifically, a simple factory pattern is used to implement the selection of multiple load generators. First, an interface class is defined, which contains two methods: the run() method and the exportResult() method. The run() method is responsible for executing the performance test script and formatting the test results; the exportResult() method is responsible for exporting the test results to a file for technicians to view. Then, a specific load generator is implemented. For each supported load generator, a corresponding Java class is written to implement the above interface. These implementation classes need to rewrite the run() and exportResult() methods defined in the interface to adapt to the characteristics and interfaces of each tool, ensuring that when executing a specific performance test task, the functions of the underlying tool can be correctly called and the unified data output standard can be followed. Finally, a factory class is implemented, which contains a static factory method that accepts a string parameter - the name of the load generator. This method dynamically instantiates and returns the corresponding interface implementation object based on the passed name.

[0065] The embodiment of the present invention aims to provide a distributed performance testing system that can accurately simulate multiple clients concurrently accessing the NFS file system, efficiently and realistically evaluate the performance of NFS in complex network environments and high-load conditions, and provide scientific and detailed performance data support for the optimization, selection and deployment decisions of the NFS file system. Its main goals include but are not limited to: simulating the usage mode of NFS in a modern cloud-native environment to ensure that the test environment is highly consistent with the actual application environment; using easy-to-understand and modify configuration files so that users can easily adjust test parameters and select load generators according to actual needs, thereby achieving flexible configuration and expansion of the test system and enhancing its applicability and ease of use; strengthening the robustness and stability of the system to ensure that the test system can quickly respond, recover and maintain the continuity of the test process when facing network anomalies or node failures, thereby improving the stability and reliability of the overall system.

[0066] To achieve the above objectives, the embodiment of the present invention is based on the master-slave architecture design, simulating multiple client devices in actual application scenarios, and mounting NFS file systems for data interaction and collaborative work. Moreover, it is built and run in a container environment, simulating the usage mode of the NFS file system in a modern cloud native environment, making the test process closer to the real application scenario and ensuring the rigor and authenticity of the performance test; the master node software is responsible for centralized management of the slave node software, task allocation and result aggregation, realizing unattended performance testing and simplifying the test process. Using IO multiplexing technology, thread requirements are reduced, thread creation and management overhead are reduced, resource over-allocation and context switching costs are avoided, and the system's concurrent processing capabilities and resource utilization are significantly improved, achieving efficient resource utilization. Using JSON as a serialization method reduces CPU and network loads and improves the efficiency of data transmission between master and slave nodes. Moreover, flexible and scalable load generator support is achieved. By using a simple factory pattern and Java polymorphism, the system realizes plug-in support for a variety of load generators, so that test tasks can flexibly select and configure different load generators according to actual needs, enhancing the scalability and adaptability of the system.

[0067] That is to say, in the embodiment of the present invention, a master-slave architecture is adopted, and the master node software is responsible for overall management, task allocation and result aggregation, and the slave node software executes the test task and feedbacks the result. The test process covers the complete sequence of master-slave node software deployment, master node software startup, task distribution, task execution and result feedback. The system communication model selects TCP long connection to reduce network overhead and improve communication efficiency. The Netty framework is used to implement IO multiplexing, and resource utilization and system stability are improved through thread pool optimization. In order to deal with network anomalies, the system enables the TCP keepalive function to ensure the validity of the connection. Data transmission adopts JSON serialization, and the Netty JSON decoder is used to prevent sticky packages and anti-subpacketization to ensure data integrity. The test system is built and run in a containerized environment to be close to the actual application of NFS in a modern cloud native environment. The configuration file adopts the YAML format, clearly defines the test objectives, parameters, slave node software information and workload generator settings, supports flexible selection and integration of multiple load generators, and uses a simple factory mode to achieve polymorphic support. It can be seen that the embodiments of the present invention can efficiently and truly evaluate the performance of the NFS file system in a complex network environment and under high load conditions, and provide a scientific basis for the optimization, selection and deployment of the NFS file system.

[0068] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0069] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the present invention can be implemented by hardware, software, widgets, or any combination thereof. When implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0070] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.

Claims

1. A performance testing system for an NFS file system, characterized in that: It includes multiple slave node software and one master node software, each slave node software is deployed on an NFS client device, and the master node software is deployed on an independent management node, wherein: The master node software is used to: after startup, establish a communication connection with each slave node software, and issue a performance test task to the slave node software through the communication connection with each slave node software according to the test plan; The slave node software is used to: after receiving the performance test task, perform a performance test on the NFS file system on the NFS client device, and record the performance data obtained by the test; after the test is completed, transmit the performance data back to the master node software through the communication connection with the master node software; The master node software is also used to: summarize the performance data returned by each slave node software to obtain a test result file of the NFS file system.

2. The performance testing system according to claim 1, characterized in that: The communication connection between the master node software and each slave node software is a long connection based on the TCP protocol.

3. The performance testing system according to claim 2, characterized in that: The master node adopts IO multiplexing technology, and the IO multiplexing technology is to use one thread to be responsible for multiple long connections based on the TCP protocol; the master node software is configured with a parent thread pool, and the parent thread pool has a thread, and the threads in the parent thread pool are used to manage the establishment and closing of the long connections based on the TCP protocol; each slave node software is configured with a child thread pool, and the child thread pool has a thread, and the threads in the child thread pool are used to logically manage the performance test process of the NFS file system on the corresponding NFS client device.

4. The performance testing system according to claim 2, characterized in that: The master node software is also used to: after establishing a long connection based on the TCP protocol with each slave node software, enable a dead connection detection mechanism; after the dead connection detection mechanism is started, the master node software periodically sends a detection data packet to each slave node software through a long connection based on the TCP protocol, and determines whether the slave node software is in an active state according to whether a feedback message from the slave node software is received; If it is determined that the slave node software is not in an active state, the long connection based on the TCP protocol between the master node software and the slave node software is closed.

5. The performance testing system according to claim 1, characterized in that: The master node software is also used to: serialize the performance test task into JSON format; correspondingly, the master node software sends the performance test task serialized into JSON format to each slave node software; The slave node software is also used to: serialize the performance data obtained from the test into JSON format; correspondingly, the slave node software returns the performance data serialized into JSON format to the master node software.

6. The performance testing system according to claim 5, characterized in that: The slave node software is also used to: decode the performance test task issued by the master node software using a JSON decoder, and after decoding to obtain a complete performance test task, perform a performance test on the NFS file system on the NFS client device; The master node software is also used to: use a JSON decoder to decode the performance data sent back by each slave node software, and after decoding to obtain complete performance data, use the performance data in the aggregation work.

7. The performance testing system according to claim 1, characterized in that: The NFS file system is deployed in a container of an NFS client device; the master node software is deployed in a container of the independent management node, and the slave node software is deployed in a container of the NFS client device.

8. The performance testing system according to claim 1, characterized in that: The master node software is specifically used to: load a configuration file after startup, wherein the configuration file defines relevant configuration information of the NFS file system and configuration parameters of the performance test task in YAML format; establish a communication connection with each slave node software according to the configuration file, and send performance test tasks to the slave node software through the communication connection with each slave node software according to the test plan.

9. The performance testing system according to claim 8, characterized in that: The configuration file includes at least one of the following: The target field is used to define the target NFS file system for this test; The parameter field is used to define the mount-related parameters of the target NFS file system; The node field is used to define the relevant information of each slave node software, including the IP address and NFS file mount point of the slave node software; Workload related fields, used to define the configuration information of the workload generator and the workload type; The Script field is used to define the test script that needs to be run when performing performance testing.

10. The performance testing system according to claim 9, characterized in that: The slave node software is used to run a performance test program; wherein the performance test program includes a running method and an output result method, the running method is used to execute the test script and serialize the performance data obtained from the test; the output result method is used to transmit the serialized performance data back to the master node software.

Images