Performance test system for nfs file system

Abstract

The application provides a performance test system of an NFS file system, which comprises a plurality of slave node software and a master node software, the master node software is used for: after starting, establishing a communication connection with each slave node software, and issuing a performance test task to each slave node software through the communication connection according to a test scheme; the slave node software is used for: after receiving the performance test task, performing performance test on the NFS file system on the NFS client device, recording performance data obtained by the test, and returning the performance data to the master node software through the communication connection after the test is completed; and the master node software is further used for: collecting the performance data returned by each slave node software, and obtaining a test result file of the NFS file system. The application provides a system for testing the NFS file system.

Description

Technical Field

[0001] This invention relates to the field of file system technology, and in particular to a performance testing system for the NFS file system. Background Technology

[0002] The NFS file system, as a network shared file system, aims to enable transparent sharing of files and directories among multiple client devices via a network interface. In practical applications, multiple clients often mount the same NFS file system simultaneously to achieve efficient, real-time data interaction and collaborative work. Therefore, it is necessary to test the performance of the NFS file system, and a system for performance testing of the NFS file system is required. NFS stands for Network File System. Summary of the Invention

[0003] To address at least one of the above technical problems, embodiments of the present invention provide a performance testing system for the NFS file system.

[0004] The performance testing system for the NFS file system provided in this 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.

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

[0006] The slave node software is used to: upon 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 from the test; after the test is completed, transmit the performance data back to the master node software through a 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 the 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-lived connection based on the TCP protocol.

[0009] In one embodiment, the master node employs I / O multiplexing technology, which uses a single thread to manage multiple long-lived connections based on the TCP protocol. The master node software is configured with a parent thread pool containing one thread, which manages the establishment and closure of the long-lived TCP connections. Each slave node software is configured with a child thread pool containing one thread, which performs logical management of the performance testing process of the NFS file system on the corresponding NFS client device.

[0010] In one embodiment, the master node software is further configured to: enable a dead connection detection mechanism after establishing a long-lived connection based on the TCP protocol with each slave node software; after the dead connection detection mechanism is activated, the master node software periodically sends probe data packets to each slave node software through the long-lived connection based on the TCP protocol, and determines whether the slave node software is in an active state based on whether it receives a feedback message from the slave node software; if it is determined that the slave node software is not in an active state, the long-lived connection based on the TCP protocol between the master node software and the slave node software is closed.

[0011] In one embodiment, the master node software is further configured to: serialize the performance test task into JSON format; correspondingly, the master node software distributes 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 sends the performance data serialized into JSON format back to the master node software.

[0013] In one embodiment, the slave node software is further configured to: decode the performance test task issued by the master node software using a JSON decoder, and after obtaining the 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: decode the performance data returned by each slave node software using a JSON decoder, and after obtaining complete performance data through decoding, use the performance data for aggregation.

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

[0016] In one embodiment, the master node software is specifically used to: after startup, load a configuration file, the configuration file defining the relevant configuration information of the NFS file system and the 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 issue the performance test task to each 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 mount point of the slave node software.

[0021] The workload-related fields are used to define the configuration information of the workload generator and the workload type;

[0022] The script field is used to define the test scripts that need to be run when performing performance tests.

[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 send the serialized performance data back to the master node software.

[0024] This invention provides a performance testing system for the NFS file system. The system includes multiple slave node software programs and a master node software program. After startup, the master node software establishes communication connections with each slave node software program. According to the test plan, it issues performance test tasks to each slave node software program through these communication connections. Upon receiving the performance test tasks, each slave node software program executes performance tests on the NFS file system on its NFS client device and records the obtained performance data. After the test is completed, the slave node software program sends the performance data back to the master node software program through the communication connections. The master node software program aggregates the performance data returned by each slave node software program to obtain the test result file for the NFS file system. Therefore, this invention adopts a master-slave architecture. The master node software is responsible for overall management, task allocation, and result aggregation, while the slave node software programs execute test tasks and provide feedback. The testing process covers the complete sequence from master-slave node software deployment, master node software startup, task issuance, task execution, to result feedback. Thus, this invention provides a system for testing the NFS file system. Attached Figure Description

[0025] Figure 1 This is a structural block diagram of an NFS file system performance testing system according to an embodiment of the present invention;

[0026] Figure 2 For based on Figure 1 A flowchart illustrating the performance testing process for the NFS file system. Detailed Implementation

[0027] In a first aspect, embodiments of the present invention provide a performance testing system for the NFS file system, see [link to relevant documentation]. Figure 1 and Figure 2 The performance testing system comprises 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.

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

[0029] The slave node software is used to: upon 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 from the test; after the test is completed, transmit the performance data back to the master node software through a 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 the test result file of the NFS file system.

[0031] As can be seen, the performance testing system adopts a master-slave architecture, featuring a central coordinating master node software and multiple responding slave node software. The master node software acts as the command center in this architecture, undertaking the core responsibilities of coordinating and managing the slave node software, allocating performance testing tasks, and summarizing and analyzing test data. The slave node software, as execution units, focuses on receiving and following the instructions of the master node software to execute performance testing tasks and provide feedback on test progress and results.

[0032] See Figure 2 A complete performance test process generally includes the following steps:

[0033] 1. Deploy Master 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 programs are ready to receive and execute 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 starts, it immediately establishes communication connections with the software of each slave node, preparing for subsequent task scheduling.

[0035] 3. Distribute 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 may include file read and write operations, directory traversal, permission verification, etc., aiming to comprehensively examine various performance indicators of the NFS file system.

[0036] 4. Execute test tasks: Upon receiving a performance test task, the slave node software immediately begins executing the specified performance test task. During this phase, the slave node software strictly adheres to the test specifications, simulating real user operations or system behaviors, while simultaneously monitoring and recording relevant performance data of the NFS file system.

[0037] 5. Feedback and Results Summary: After execution, the slave node software sends the test results, i.e., the performance data report, back to the master node software. Upon receiving the test results from all slave node software, the master node software summarizes and outputs them to a test results file for technical personnel to view.

[0038] In this performance testing system, the master and slave node software run on different hosts, and their communication relies on a stable network environment. Three feasible options can be considered when choosing a communication model. These three options are as follows:

[0039] Option 1: During the task distribution phase, the slave node software acts as a server, listening on a specific port and waiting for the master node software to establish a connection. It receives and executes performance test tasks via HTTP. In the result collection phase, the master node software adopts an active polling strategy, periodically sending HTTP requests to the slave node software to obtain test progress and results. Although Java provides relatively convenient implementation of HTTP clients and servers under the Spring framework, prolonged polling may lead to a large number of invalid requests, resulting in significant resource consumption.

[0040] Option 2: The task distribution phase follows the same procedure as Option 1. However, during the result reporting phase, the master node software switches to a server role, listening on a specific port and waiting for the slave node software to upload test results via HTTP. While this option eliminates the need for polling by the master node software, both the master and slave node software must function as both server and client, increasing the system's complexity.

[0041] Option 3: During the task distribution phase, the master node software establishes a long-lived connection with the slave node software via TCP, abandoning the HTTP protocol to reduce network overhead and improve communication efficiency. The implementation details of this phase are similar to the previous two options, with adjustments only at the protocol level. In the result reporting phase, the slave node software utilizes the established long-lived connection to transmit test data to the master node software in a timely and efficient manner. The advantages of this option are: firstly, the master node software only needs to act as a TCP client, simplifying its role; secondly, the slave node software only needs to act as a server to receive performance test tasks and return results, resulting in clear division of labor and high resource utilization. Furthermore, the reuse of long-lived connections effectively avoids the resource waste caused by polling, making the entire communication process simpler and more efficient.

[0042] It is evident that Option 3 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 early network communication, Java widely adopted the traditional BIO (Blocking I / O) model. This model operates in a blocking manner, meaning that when a thread handles a TCP connection, it focuses entirely on the operation of that 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 simultaneously. For a performance testing 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, leading to a surge in thread requirements. Creating a large number of threads not only puts significant pressure on system resources such as memory and CPU scheduling, but may also lead to low resource utilization and waste. Especially in high-concurrency scenarios, excessive thread management overhead and context switching costs will severely restrict the overall performance and scalability of the performance testing system. To solve this problem, the performance testing system adopts I / O multiplexing technology, which allows a single thread to efficiently monitor and handle multiple TCP connections simultaneously. By aggregating I / O events from multiple connections into a single thread for unified scheduling, the resource consumption of allocating a separate thread for each connection is avoided, thereby greatly improving the system's concurrent processing capabilities and resource utilization.

[0044] Netty, a popular Java RPC (Remote Procedure Call) framework, provides excellent support for I / O multiplexing models. During initialization, the Netty server configures two dedicated thread pools: one for managing connection establishment and closure (the parent thread pool), and the other focused on handling business logic (the child thread pool). To meet the specific needs of the performance testing system and minimize resource waste while ensuring the accuracy of test results, the Netty thread pool configuration was adjusted. First, the parent thread pool size of the master node software was set to 1. This is because the master node software only needs a single thread to efficiently accept and manage connection requests from all slave node software, eliminating the need for additional thread overhead. Second, considering the serial execution requirements of test tasks and to avoid interference between parallel tasks affecting test results, the child thread pool of each slave node software was also limited to containing only one thread. This configuration ensures that only one test task is executed for each slave node software at any given time, preventing excessive resource allocation and maintaining the consistency and reliability of test data.

[0045] In other words, in one embodiment, the master node can employ I / O multiplexing technology, which uses one thread to manage multiple long connections based on the TCP protocol; the master node software is configured with a parent thread pool, which contains one thread used to manage the establishment and closure of the long connections based on the TCP protocol; each slave node software is configured with a child thread pool, which contains one thread used to logically manage the performance testing 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-lived connection based on the TCP protocol with each slave node software; after the dead connection detection mechanism is activated, the master node software periodically sends probe data packets to each slave node software through the long-lived connection based on the TCP protocol, and determines whether the slave node software is in an active state based on whether it receives a feedback message from the slave node software; if it is determined that the slave node software is not in an active state, the long-lived connection based on the TCP protocol between the master node software and the slave node software is closed.

[0047] Understandably, as a distributed system, the inherent complexity of performance testing systems makes network anomalies the norm rather than the exception. These anomalies often lead to sudden TCP connection interruptions, severely impacting the stability and consistency of the performance testing system. To enhance the robustness of the entire system, both the master and slave node software enable keepalive at the initial TCP connection establishment. Keepalive is a mechanism in TCP that can detect dead connections. Its core value lies in the fact that when a TCP connection is in a state of no data transmission for a certain period, the master node software sends probing packets to the slave node software to check the connection's validity. In a performance testing system, if a slave node software suddenly goes offline due to its own failure, or if network fluctuations prevent the normal termination signal from successfully reaching the master node software, without keepalive enabled, the existing TCP connection will enter a "dead" state, continuously occupying system resources without releasing them. In this situation, the master node software will mistakenly believe that the slave node software is still executing test tasks, resulting in endless waiting and an inability to exit the current task state in a timely manner. Conversely, if keepalive is enabled, even if the termination signal is unfortunately lost during transmission, the master node software can still verify the activity of the slave node software through periodically sent probe packets. If the slave node software becomes unresponsive due to a fault, after a preset period of time, the master node software will recognize the continuous unsuccessful probes and proactively close the TCP connection. In this way, the master node software can promptly detect the abnormal status of the slave node software and mark it as a test failure, instead of waiting endlessly. This ensures that the master node software can complete the current task according to the expected process and smoothly enter the next working stage, maintaining the efficient operation of the overall system and the smooth flow of tasks.

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

[0049] Understandably, when the master node software sends performance test tasks to the slave node software, and when the slave node software sends test execution results back to the master node software, the data transmission involved must first undergo the crucial step of serialization—converting complex structured objects into byte streams suitable 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 it consumes relatively high computing resources and network bandwidth. In contrast, JSON, as a lightweight text serialization format, reduces CPU and network load. Therefore, the performance testing system chose JSON as the serialization method to ensure the convenience and consistency of performance test tasks and results exchanged between the master and slave node software.

[0050] In one embodiment, the slave node software can also be used to: decode the performance test task issued by the master node software using a JSON decoder, and after obtaining 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: decode the performance data returned by each slave node software using a JSON decoder, and after obtaining the complete performance data, participate in the aggregation work.

[0051] Understandably, while 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 data volume is too large, it may exceed the carrying capacity of a single data packet, causing the information to be split into multiple data packets for transmission, the so-called "packet splitting" phenomenon. Conversely, when the data volume is too small, the operating system may merge multiple small data packets into a single data packet for transmission to optimize network efficiency, the so-called "packet merging" problem. Both of these situations can lead to incomplete information received by the receiving end, resulting in data parsing errors or task execution anomalies. To ensure that the slave node software accurately receives the complete performance test task and that the master node software accurately summarizes the performance test results, this embodiment of the invention selects the JSON decoder provided by the Netty framework. This component is specifically designed for processing JSON data in network communication and has anti-packet merging and anti-packet splitting capabilities. Netty's JSON decoder can identify the beginning and end of a JSON object, ensuring that only one complete JSON object is decoded at a time. Therefore, the slave node software will only start executing the test after receiving the complete performance test task structure, while the master node software will only perform subsequent aggregation and analysis after receiving complete and correctly structured performance test result data.

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

[0053] Understandably, in industry practice, the mainstream usage of the NFS file system has been deeply integrated with containerized environments. Many enterprises and developers choose to use the NFS file system in containers to enable multiple container instances to share the same NFS file system data resources. To ensure the rigor and practicality of performance testing, the performance testing system also follows this trend and is built and run in a container environment; therefore, the master node software and slave node software are also deployed in containers.

[0054] In one embodiment, the master node software may be specifically used to: after startup, load a configuration file, the configuration file defining the relevant configuration information of the NFS file system and the 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 issue the performance test task to each slave node software through the communication connection with each slave node software according to the test plan.

[0055] As can be seen, in the initial stage of the performance testing system startup, the master node software needs to parse and load the configuration file. The configuration file, written in YAML format, defines the relevant settings data for the NFC file system and the specific parameters of the performance testing tasks. Based on the configuration file, a reference can be provided for establishing communication connections and issuing performance testing 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 mount point of the slave node software.

[0060] The workload-related fields are used to define the configuration information of the workload generator and the workload type;

[0061] The script field is used to define the test scripts that need to be run when performing performance tests.

[0062] For example, the `task` configuration field defines the target file system for this performance test; the `parameters` configuration field lists detailed parameters related to mounting the NFS file system; and the `workers` configuration field lists the information of the slave node software participating in the test, with each slave node's entry including its IP address and corresponding NFS mount point. These configuration fields guide the master node software on how to assist the slave node software in mounting the target NFS file system, building the basic architecture of the distributed testing environment. The `workload` configuration field defines the selection and configuration of the workload generator; `provider` indicates the type of workload, which can be `fio` or `filebench`. The `script` field represents the test script to be run during the performance test, defining specific test modes, parameter sets, execution cycles, and other details to ensure that the testing tools can simulate real-world application scenarios, applying the expected load to 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 send the serialized performance data back to the master node software.

[0064] The performance testing program is written in Java. As an object-oriented language, Java's native polymorphism allows for more elegant support of multiple load generators. Specifically, a simple factory pattern is used to implement the selection of multiple load generators. First, an interface class is defined, containing two methods: a run() method and an exportResult() method. The run() method executes the performance test script and formats the test results; the exportResult() method exports the test results to a file for technical personnel to view. Next, specific load generators are implemented. For each supported load generator, a corresponding Java class is written that implements the interface. These implementation classes need to override the run() and exportResult() methods defined in the interface to adapt to the characteristics and interfaces of their respective tools, ensuring that when executing specific performance test tasks, the underlying tool's functionality is correctly invoked while adhering to a unified data output standard. Finally, a factory class is implemented, containing 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-in name.

[0065] This invention aims to provide a distributed performance testing system capable of accurately simulating concurrent access to the NFS file system by multiple clients. It efficiently and realistically evaluates the performance of NFS under complex network environments and high load conditions, providing scientific and detailed performance data support for NFS file system optimization, selection, and deployment decisions. Its main objectives include, but are not limited to: simulating NFS usage patterns in modern cloud-native environments to ensure a high degree of fit between the testing environment and the actual application environment; employing easily understandable and modifiable configuration files, allowing users to conveniently adjust test parameters and select load generators according to actual needs, achieving flexible configuration and expansion of the testing system, enhancing its applicability and ease of use; and strengthening system robustness and stability, ensuring that the testing system can quickly respond and recover when facing network anomalies or node failures, maintaining the continuity of the testing process, and improving the overall system stability and reliability.

[0066] To achieve the above objectives, this invention is based on a master-slave architecture, simulating a real-world application scenario where multiple client devices simultaneously mount an NFS file system for data interaction and collaborative work. Furthermore, it is built and run in a container environment, simulating the usage pattern of the NFS file system in a modern cloud-native environment, making the testing process closer to real-world applications and ensuring the rigor and authenticity of performance testing. The master node software is responsible for centrally managing the slave node software, task allocation, and result aggregation, enabling unattended performance testing and simplifying the testing process. Using I / O multiplexing technology reduces thread requirements, lowers thread creation and management overhead, avoids excessive resource allocation and context switching costs, significantly improving the system's concurrent processing capabilities and resource utilization, achieving efficient resource utilization. Using JSON as the serialization method reduces CPU and network load, improving data transmission efficiency between master and slave nodes. Moreover, it implements flexible and scalable load generator support. By utilizing the simple factory pattern and Java polymorphism, the system implements pluggable support for various load generators, allowing test tasks to flexibly select and configure different load generators according to actual needs, enhancing the system's scalability and adaptability.

[0067] In other words, this embodiment of the invention adopts a master-slave architecture. The master node software is responsible for overall management, task allocation, and result aggregation, while the slave node software executes test tasks and provides feedback. The testing process covers the complete sequence from master-slave node software deployment, master node software startup, task distribution, task execution, to result feedback. The system communication model uses TCP long connections to reduce network overhead and improve communication efficiency. The Netty framework is used to implement I / O multiplexing, and thread pool optimization improves resource utilization and system stability. To cope with network anomalies, the system enables TCP keepalive functionality to ensure connection validity. Data transmission uses JSON serialization, utilizing the Netty JSON decoder to prevent packet fragmentation and ensure data integrity. The test system is built and run in a containerized environment to closely resemble the actual application of NFS in modern cloud-native environments. The configuration file uses YAML format, clearly defining test objectives, parameters, slave node software information, and workload generator settings. It supports flexible selection and integration of multiple workload generators and utilizes the simple factory pattern to achieve polymorphism support. As can be seen, the embodiments of the present invention can efficiently and realistically evaluate the performance of the NFS file system under complex network environments and high load conditions, providing a scientific basis for the optimization, selection and deployment of the NFS file system.

[0068] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

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

[0070] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment 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 within 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 a separate management node, wherein: The master node software is used to: establish a communication connection with each slave node software after startup, and issue performance test tasks to each slave node software through the communication connection according to the test plan; The slave node software is used to: upon 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 from the test; after the test is completed, transmit the performance data back to the master node software through a 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 for the NFS file system; The communication connection between the master node software and each slave node software is a long-lived connection based on the TCP protocol; The master node employs I / O multiplexing technology, which uses a single thread to manage multiple long-lived TCP connections. The master node software is configured with a parent thread pool containing one thread, which manages the establishment and closure of the long-lived TCP connections. Each slave node software is configured with a child thread pool containing one thread, which logically manages the performance testing process of the NFS file system on the corresponding NFS client device. The master node software is further configured to: enable a dead connection detection mechanism after establishing a long-lived connection with each slave node software based on the TCP protocol; after the dead connection detection mechanism is activated, the master node software periodically sends probe data packets to each slave node software through the long-lived connection based on the TCP protocol, and determines whether the slave node software is active based on whether it receives a feedback message from the slave node software; if it is determined that the slave node software is not active, the long-lived connection based on the TCP protocol between the master node software and the slave node software is closed.

2. 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 distributes 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 sends the performance data serialized into JSON format back to the master node software.

3. The performance testing system according to claim 2, 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: decode the performance data returned by each slave node software using a JSON decoder, and after obtaining complete performance data through decoding, use the performance data for aggregation.

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

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

6. The performance testing system according to claim 5, 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 mount point of the slave node software. The workload-related fields are used to define the configuration information of the workload generator and the workload type; The script field is used to define the test scripts that need to be run when performing performance tests.

7. The performance testing system according to claim 6, 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 send the serialized performance data back to the master node software.

Images