Performance comparison test method and device for network policy control tool

Abstract

The invention discloses a performance comparison test method and device for a network policy control tool, relates to the technical field of automatic test, can be applied to the field of smart medical treatment and the field of finance, and mainly aims to solve the problem that the accuracy and comprehensiveness of a performance comparison test result of an existing network policy control tool are relatively low. The method mainly comprises the steps that at least one testing environment is set up, and different testing environments are configured with different flow control matching mechanisms so as to simulate an actual service scene that a core application is called by multiple applications; for any to-be-tested tool, deploying the to-be-tested tool to a test environment, generating a strategy rule according to a flow control matching mechanism in the test environment, and obtaining performance parameter information of the to-be-tested tool for executing the strategy rule; and generating a comparison test result of the global to-be-tested tool according to the performance parameter information of each to-be-tested tool in the test environment. The method is mainly used for comparing and testing the performance of the network strategy management and control tool.

Description

Technical Field

[0001] The present invention relates to the field of automated testing technology and can be applied to the fields of smart healthcare and finance, and in particular to a performance comparison testing method and device for a network policy management tool. Background Art

[0002] Network policy management tools are the "nerve center" of modern enterprise network architectures. By building a closed-loop system of policy definition, automated distribution, real-time verification, and intelligent optimization, they enable refined traffic management and dynamic security defense across cloud, network, and endpoints (hybrid cloud, edge computing, and 5G private networks). With the rise of enterprise digital transformation and the widespread adoption of hybrid cloud architectures, network policy management tools have become core infrastructure supporting multi-cloud environments, the Internet of Things (IoT), and distributed applications. In particular, in the digital transformation of smart healthcare, medical networks have become the core vehicle for cross-regional, multimodal data collaboration, high-efficiency business support, and strong compliance assurance. Their complexity and security demands place increasing demands on network policy management tools, making performance comparison and testing of network policy management tools a crucial tool for selecting them. Similarly, in the financial sector, with the increasing adoption of digital transformation and hybrid cloud architectures, network policy management tools have become core infrastructure supporting multi-cloud environments, IoT-enabled financial terminals (such as smart ATMs and mobile payment devices), and distributed transaction systems. Especially in scenarios such as high-frequency trading, cross-border payments, and real-time risk control, financial networks have become the core carrier for cross-regional multi-institutional data collaboration, millisecond-level transaction response, and strong regulatory compliance guarantees.

[0003] Currently, existing mainstream performance comparison test methods mostly rely on static policy benchmark tests in laboratory environments, facing three core pain points: fragmented test scenarios, distorted load models, and discontinuity in business value. As a result, the performance comparison test results of network policy management tools are less accurate and comprehensive, and cannot meet the needs of developers in this field for performance comparison test data. Summary of the Invention

[0004] In view of this, the present invention provides a performance comparison test method and device for network policy management tools, the main purpose of which is to solve the problem of low accuracy and comprehensiveness of performance comparison test results of existing network policy management tools.

[0005] According to one aspect of the present invention, a performance comparison test method for a network policy management tool is provided, comprising:

[0006] Establishing at least one test environment, wherein different flow control matching mechanisms are configured in different test environments to simulate an actual business scenario in which a core application is called by multiple applications;

[0007] For any tool under test, deploy the tool under test into the test environment, generate policy rules based on the flow control matching mechanism in the test environment, and obtain performance parameter information of the tool under test executing the policy rules;

[0008] A global comparison test result of the tools under test is generated according to the performance parameter information of each of the tools under test in the test environment.

[0009] Furthermore, the test environment includes a first test environment for simulating a business scenario of calling within the cluster and a second test environment for simulating a business scenario of calling outside the cluster. The process of setting up the first test environment includes:

[0010] Build a Kubernetes cluster with multiple container groups to simulate a microservice architecture.

[0011] Configuring label information for the core application of the simulated microservice architecture, wherein the label information is used as matching information for flow control;

[0012] The process of setting up the second test environment includes:

[0013] Build a simulated cross-cluster or cross-network call architecture that includes multiple external applications;

[0014] An IP address range is configured for the core application simulating the cross-cluster or cross-network call architecture, wherein the IP address range is used as matching information for flow control.

[0015] Furthermore, in the first test environment, generating policy rules according to the flow control matching mechanism in the test environment and obtaining performance parameter information of the tool under test executing the policy rules include:

[0016] Generating an initial policy rule based on the tag information according to a traffic matching and routing control mechanism of the metadata tag based on first preset test parameters and the tag information, wherein the first preset test parameters include the number of request tags, the number of first service ports, and the number of first container groups;

[0017] Sending the initial policy rule based on the tag information to the tool under test, and obtaining a first policy effective time and a first single-node performance parameter during the tool under test's execution of the initial policy rule;

[0018] The first policy effective time and the first single-node performance parameter are used as the performance parameter information under the first test environment.

[0019] Furthermore, the performance parameter information also includes a first single-node performance parameter time series. After obtaining the first policy effective time and the first single-node performance parameter during the process of the tool under test executing the initial policy rule, the method further includes:

[0020] According to a first preset step size, gradually generate multiple sets of incremental policy rules based on the tag information until the number of the incremental policy rules meets a first policy rule upper limit, where the first policy rule upper limit is calculated based on the number of request tags, the number of the first service ports, and the number of the first container groups;

[0021] The single-node performance parameters of the tool under test when executing each set of incremental strategy rules are obtained to obtain a first single-node performance parameter time series.

[0022] Furthermore, in the second test environment, generating policy rules according to the flow control matching mode in the test environment and obtaining performance parameter information of the tool under test executing the policy rules include:

[0023] generating, according to a second preset test parameter and the IP address range, an initial policy rule based on the IP address range in accordance with a classless inter-domain routing traffic matching mechanism, wherein the second preset test parameter includes the number of requested IP addresses, the number of second service ports, and the number of second container groups;

[0024] Sending the initial policy rules based on the IP address range to the tool to be tested;

[0025] A second policy effective time and a second single-node performance parameter during the process of the tool under test executing the initial policy rule are obtained.

[0026] Furthermore, the performance parameter information also includes a second single-node performance parameter time series. After obtaining the second policy effective time and the second single-node performance parameter during the process of the tool under test executing the initial policy rule, the method further includes:

[0027] According to a second preset step size and a second policy rule upper limit, gradually generating multiple sets of incremental policy rules based on the IP address range until the number of the incremental policy rules meets the second policy rule upper limit, wherein the second policy rule upper limit is calculated based on the number of request IP addresses, the number of second service ports, and the number of second container groups;

[0028] The single-node performance parameters of the tool under test when executing each set of the incremental strategy rules are obtained to obtain a second single-node performance parameter time series.

[0029] Furthermore, the test environment includes a first test environment and a second test environment, the performance parameter information includes a policy effective time, a single-node performance parameter, and a single-node performance parameter time series, and generating a global comparison test result of the tool under test based on the performance parameter information of each tool under test in the test environment includes:

[0030] For any tool under test, the policy effective time is converted into a delay factor, the single-node throughput and request processing delay in the single-node performance parameters are converted into an efficiency factor, and based on the fitting results of the single-node performance parameter time series, the performance change factor and the single-node policy rule upper limit achievement rate are extracted;

[0031] For any tool under test, retrieve an environment weighting model that matches the expected application business type of the tool under test, and calculate a test score index based on the weight coefficients assigned by the environment weighting model to the latency factor, efficiency factor, performance variation factor, and single-node policy rule upper limit achievement rate in the first test environment and the second test environment;

[0032] The test score index ranking results of the different tools to be tested are used as the comparison test results of the tools to be tested.

[0033] According to another aspect of the present invention, a performance comparison test device for a network policy management tool is provided, comprising:

[0034] A building module for building at least one test environment, wherein different flow control matching mechanisms are configured in different test environments to simulate an actual business scenario in which a core application is called by multiple applications;

[0035] A testing module is configured to deploy any tool under test into the test environment, generate policy rules based on a flow control matching mechanism in the test environment, and obtain performance parameter information of the tool under test executing the policy rules;

[0036] The generating module is used to generate a global comparison test result of the tools under test according to the performance parameter information of each tool under test in the test environment.

[0037] Furthermore, the building module includes:

[0038] The first building unit is used to build a Kubernetes cluster containing multiple container groups to obtain a simulated microservice architecture;

[0039] A first configuration unit is configured to configure label information for the core application of the simulated microservice architecture, wherein the label information is used as matching information for flow control;

[0040] The second building unit is used to build a simulated cross-cluster or cross-network call architecture containing multiple external applications;

[0041] The second configuration unit is used to configure an IP address range for the core application that simulates a cross-cluster or cross-network call architecture, wherein the IP address range is used as matching information for flow control.

[0042] Furthermore, in the first test environment, the test module includes:

[0043] a first policy generating unit, configured to generate an initial policy rule based on the tag information according to a traffic matching and routing control mechanism of the metadata tag based on first preset test parameters and the tag information, wherein the first preset test parameters include the number of request tags, the number of first service ports, and the number of first container groups;

[0044] The first acquisition unit is used to send the initial policy rules based on the label information to the tool to be tested, and obtain the first policy effective time and the first single-node performance parameters during the process of the tool to be tested executing the initial policy rules; and use the first policy effective time and the first single-node performance parameters as the performance parameter information in the first test environment.

[0045] Furthermore, the test module further includes:

[0046] a second policy generation unit, configured to gradually generate, according to a first preset step size, multiple sets of incremental policy rules based on the tag information until the number of the incremental policy rules meets a first policy rule upper limit, wherein the first policy rule upper limit is calculated based on the number of request tags, the number of the first service ports, and the number of the first container groups;

[0047] The second acquisition unit is configured to acquire the single-node performance parameters when the tool under test executes each set of incremental strategy rules, and obtain a first single-node performance parameter time series.

[0048] Furthermore, in the second test environment, the test module includes:

[0049] a third policy generating unit, configured to generate an initial policy rule based on the IP address range according to a classless inter-domain routing traffic matching mechanism based on second preset test parameters and the IP address range, wherein the second preset test parameters include the number of requested IP addresses, the number of second service ports, and the number of second container groups;

[0050] The third acquisition unit is configured to send the initial policy rule based on the IP address range to the tool under test, and acquire a second policy effective time and a second single-node performance parameter during the process of the tool under test executing the initial policy rule.

[0051] Furthermore, the test module further includes:

[0052] a fourth policy generation unit, configured to gradually generate multiple sets of incremental policy rules based on the IP address range according to a second preset step size and a second policy rule upper limit, until the number of the incremental policy rules meets the second policy rule upper limit, wherein the second policy rule upper limit is calculated based on the number of requested IP addresses, the number of second service ports, and the number of second container groups;

[0053] The fourth acquisition module is configured to acquire the single-node performance parameters when the tool under test executes each set of the incremental strategy rules, and obtain a second single-node performance parameter time series.

[0054] Furthermore, the generation module includes:

[0055] a conversion unit configured to convert, for any tool under test, the policy effective time into a delay factor, convert the single-node throughput and request processing delay in the single-node performance parameters into an efficiency factor, and extract a performance change factor and a single-node policy rule upper limit achievement rate based on a fitting result of a time series of the single-node performance parameters;

[0056] A weight allocation unit is used to call an environment weighting model that matches the expected application business type of any tool to be tested, and calculate a test score index based on the weight coefficients assigned to the delay factor, efficiency factor, performance change factor and single-node policy rule upper limit achievement rate in the first test environment and the second test environment according to the environment weighting model;

[0057] The ranking unit is used to use the ranking results of the test score indexes of the different tools to be tested as the comparison test results of the tools to be tested.

[0058] According to another aspect of the present invention, a storage medium is provided, in which at least one executable instruction is stored. The executable instruction enables a processor to execute operations corresponding to the performance comparison test method of the network policy management tool as described above.

[0059] According to another aspect of the present invention, there is provided a computer device comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus;

[0060] The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute operations corresponding to the performance comparison test method of the above-mentioned network policy management tool.

[0061] By means of the above technical solution, the technical solution provided by the embodiment of the present invention has at least the following advantages:

[0062] The present invention provides a performance comparison test method and device for a network policy management tool. An embodiment of the present invention establishes at least one test environment, wherein different test environments are configured with different flow control matching mechanisms to simulate an actual business scenario in which a core application is called by multiple applications; for any tool to be tested, the tool to be tested is deployed into the test environment, policy rules are generated according to the flow control matching mechanism in the test environment, and performance parameter information of the tool to be tested executing the policy rules is obtained; a global comparison test result of the tool to be tested is generated according to the performance parameter information of each tool to be tested under the test environment, and by establishing a test environment configured with different flow control matching mechanisms, the test environment is made more in line with the actual business scenario, thereby comprehensively evaluating the adaptability, stability and scalability of the network policy management tool in a complex network, and meeting the needs of developers in this field for performance comparison test data.

[0063] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are specifically listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the present invention. The same reference symbols are used throughout the drawings to represent the same components. In the drawings:

[0065] Figure 1 A flow chart of a performance comparison test method for a network policy management tool provided by an embodiment of the present invention is shown;

[0066] Figure 2 A flow chart of a performance comparison test method for another network policy management tool provided by an embodiment of the present invention is shown;

[0067] Figure 3 A block diagram showing the composition of a performance comparison test device for a network policy management tool provided by an embodiment of the present invention is shown;

[0068] Figure 4 A schematic structural diagram of a computer device provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0069] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0070] Aiming at the problem that the performance comparison test results of existing network policy management tools are less accurate and comprehensive. The embodiment of the present invention provides a performance comparison test method for network policy management tools, such as Figure 1 As shown, the method includes:

[0071] 101. Build at least one test environment.

[0072] In smart healthcare scenarios, to comprehensively and accurately evaluate the performance of tools under test (such as iptables or eBPF) under micro-isolation network policies, embodiments of the present invention construct multiple test environments, each configured with a different traffic control and matching mechanism to simulate real-world scenarios where core applications are called by multiple applications. For example, in one test environment, we employ a label-based matching mechanism (such as match label) to simulate the dynamic calling relationships between medical applications within a microservices architecture. By assigning specific labels to different medical devices and medical applications, we can precisely control the flow of network traffic and evaluate the performance of the tools under test in issuing and matching label-based policies. In another test environment, we employ an IP address range-based matching mechanism (such as ipblock) to simulate cross-network or cross-cluster medical data access scenarios. By setting different IP address ranges and access rules, we can evaluate the performance of the tools under test when dealing with large-scale and complex network traffic. Core applications generally refer to applications or services that play a key role in smart healthcare systems. These core applications may be responsible for processing sensitive medical data, providing critical medical functions or services, or be core components of the entire medical business process.

[0073] In financial scenarios, to comprehensively and accurately evaluate the performance of tools under test (such as iptables or eBPF) under micro-segmented network policies, we can build multiple test environments, each configured with different traffic control and matching mechanisms, to simulate real-world scenarios where core financial applications are called by multiple applications. In the financial industry, microservices architectures are widely used in scenarios such as online payments, securities trading, and core banking systems. By assigning specific tags to different financial services, we can precisely control the flow of network traffic and evaluate the performance of the tools under test in issuing and matching tag-based policies.

[0074] 102. For any tool under test, deploy the tool under test into the test environment, generate policy rules according to a flow control matching mechanism in the test environment, and obtain performance parameter information of the tool under test executing the policy rules.

[0075] In an embodiment of the present invention, for any tool to be tested, we deploy it into a pre-built diversified test environment. Then, according to the specific traffic control matching mechanism in the test environment, corresponding policy rules are generated. For example, in a label-based matching scenario, we will dynamically generate policy rules that allow or deny specific traffic to pass through based on the label information of medical applications and medical devices; in a matching scenario based on IP address ranges, we will set corresponding access control rules based on the IP address range of the request source. Then, use automated testing tools to monitor and record the performance parameter information of the tool to be tested in executing these policy rules. These performance parameters include but are not limited to policy effective time, single-node throughput, request processing delay, resource occupancy, etc., which can fully reflect the efficiency and stability of the tool to be tested in processing network traffic and executing policy rules. The tools to be tested include but are not limited to eBPF, iptables, Calico and nftables, that is, this method can realize comparative testing of any combination of the above tools.

[0076] 103. Generate a global comparison test result of the tools under test based on the performance parameter information of each tool under test in the test environment.

[0077] In an embodiment of the present invention, after completing the deployment of each tool to be tested to a diversified test environment, and generating policy rules and obtaining performance parameter information based on the traffic control matching mechanism in the test environment, we further generate a global comparison test result of the tool to be tested based on this performance parameter information. Through statistical, comparative and other methods, the performance characteristics of each tool to be tested in different test environments are extracted. On this basis, we further integrate these performance characteristics, use scientific evaluation methods (such as environmental weighted models, etc.), and comprehensively consider factors such as the importance of actual application scenarios, the urgency of business needs, and resource constraints to generate a comprehensive and objective global comparison test result for each tool to be tested. This global comparison test result can not only help medical institutions more intuitively understand the comprehensive performance of different tools to be tested in smart medical scenarios, but also provide them with powerful decision-making support when choosing the network policy management tool that best suits their needs. By comparing the global comparison test results of different tools to be tested, medical institutions can more accurately grasp the advantages and disadvantages of each tool, thereby making more scientific and reasonable choices.

[0078] In a microservices architecture testing environment simulating a payment system or securities trading system, the assessment of the tool's ability to handle highly concurrent financial transactions and its ability to ensure data security and access control in cross-network or cross-cluster financial data access scenarios can also provide strong decision-making support for selecting the network policy management tool that best suits their needs. By comparing the overall results of different tools under test, financial institutions can more accurately grasp the strengths and weaknesses of each tool, thereby making more scientific and reasonable choices.

[0079] In one embodiment of the present invention, for further explanation and limitation, as Figure 2 As shown, the test environment includes a first test environment for simulating a business scenario of calling within a cluster and a second test environment for simulating a business scenario of calling outside a cluster. The process of setting up the first test environment includes:

[0080] 201. Build a Kubernetes cluster with multiple container groups to simulate a microservice architecture.

[0081] 202. Configure label information for the core application of the simulated microservice architecture.

[0082] 203. Build a simulated cross-cluster or cross-network call architecture that includes multiple external applications.

[0083] 204. Configure an IP address range for the core application simulating the cross-cluster or cross-network call architecture.

[0084] In order to comprehensively evaluate the performance of the tools under test (such as iptables or eBPF) under the micro-isolation network strategy, the present invention carefully designed two typical test environments: the first test environment is used to simulate the business scenario of calling services within the cluster, and the second test environment is used to simulate the business scenario of calling services outside the cluster. The following is a detailed explanation of the process of setting up these two test environments:

[0085] The first test environment (simulating in-cluster business scenarios) was set up using a Kubernetes-based containerized platform to simulate the microservices architecture of a smart healthcare system. Kubernetes, with its powerful container orchestration and management capabilities, allows for the flexible deployment, scaling, and management of multiple container groups (Pods), providing an ideal environment for simulating a microservices architecture. In the Kubernetes cluster, each container group (representing a different healthcare application or service) was assigned unique labels. These labels served as a basis for traffic control, allowing for dynamic control of network traffic based on attributes such as the application or service type and role. Simulating the microservices architecture of a financial system: In the Kubernetes cluster, each container group (representing a different financial service or application, such as user services, order services, and payment services) was assigned unique labels. These labels served as a basis for traffic control, allowing for dynamic control of network traffic based on attributes such as the financial service or application type and role, thereby more accurately simulating network traffic behavior in financial business scenarios.

[0086] The second test environment (simulating out-of-cluster call business scenarios) involves building a test environment containing multiple external applications. These external applications can be located in different data centers, cloud environments, or network domains. By simulating factors such as network latency and bandwidth limitations, the complexity of cross-cluster or cross-network calls can be more realistically reflected. Furthermore, in cross-cluster or cross-network call scenarios, IP address ranges (CIDR) are used as matching information for traffic control. Specific IP address ranges are configured for core applications, allowing or denying network traffic based on the request source IP address. For example, a specific IP address range can be configured for network traffic from specific medical institutions or partners to ensure secure data transmission and access control. Another example is simulating calls between a bank's core system and external systems such as payment gateways and third-party credit reporting agencies. Configuring an IP address range for the core application: Select the bank's core system as the core application and configure an IP address range for it as matching information for traffic control. For example, the IP address range for the core application can be configured as 192.168.1.0 / 24. Through the above construction process, we successfully simulated the business scenarios of intra-cluster calls and extra-cluster calls in smart medical systems and financial systems, laying a solid foundation for the subsequent evaluation of the performance of the tools under micro-isolation network strategies.

[0087] In one embodiment of the present invention, for further explanation and limitation, in a first test environment, generating policy rules based on a flow control matching mechanism in the test environment and obtaining performance parameter information of the tool under test executing the policy rules includes:

[0088] generating an initial policy rule based on the tag information according to a traffic matching and routing control mechanism of the metadata tag based on the first preset test parameter and the tag information;

[0089] Sending the initial policy rule based on the tag information to the tool under test, and obtaining a first policy effective time and a first single-node performance parameter during the tool under test's execution of the initial policy rule;

[0090] The first policy effective time and the first single-node performance parameter are used as the performance parameter information under the first test environment.

[0091] In an embodiment of the present invention, based on the first preset test parameters and the tag information of the core application and associated applications, an initial policy rule based on the tag information is generated according to the traffic matching and routing control mechanism of the metadata tag. Among them, the first preset test parameters include the number of request tags, the number of first service ports, and the number of first container groups. The number of request tags, that is, the number of tag combinations carried when simulating calls between different applications / services in the cluster, is used to evaluate the policy processing capabilities of the tool under test in complex tag matching scenarios. The number of first service ports, that is, the total number of service ports exposed to the outside by the core applications in the cluster, reflects the complexity of the business traffic entrance. The number of first container groups, that is, the deployment scale of the core application and its dependent services in the Kubernetes cluster, reflects the distribution characteristics of the target nodes under the policy. In a specific application scenario, the number of request tags can be 1 to 10, the number of first service ports can be 10, and the number of first container groups can be 100. Of course, the above parameters can also be customized according to the actual application scenario, and the embodiment of the present invention does not make specific limitations.

[0092] The generated initial policy rules based on label information are distributed to the target nodes (such as Worker nodes in a Kubernetes cluster) through the API interface or configuration management module of the tool under test. The time interval from the completion of the initial policy rule distribution to the actual implementation of the core application is monitored, as well as the performance parameters of the first single node during the policy execution period.

[0093] In one embodiment of the present invention, for further explanation and limitation, after obtaining the first policy effective time and the first single-node performance parameter during the process of the tool under test executing the initial policy rule, the method further includes:

[0094] According to a first preset step size, gradually generating multiple groups of incremental policy rules based on the tag information until the number of the incremental policy rules meets the first policy rule upper limit;

[0095] The single-node performance parameters of the tool under test when executing each set of incremental strategy rules are obtained to obtain a first single-node performance parameter time series.

[0096] In an embodiment of the present invention, in the process of executing policy rules and obtaining performance parameter information for the tool to be tested (such as iptables or eBPF), in order to further quantitatively analyze its dynamic behavior in complex network policy scenarios, after obtaining the first policy effective time and the first single-node performance parameter under the initial policy rules, it is also necessary to dynamically adjust the number of rules, that is, incremental policy rules, to verify the upper limit of the number of rules supported by a single node. Specifically, according to a first preset step size (such as increasing the number of label combination rules by 10% each time), multiple groups of incremental policy rules based on label information are gradually generated. The incremental policy rules are expanded based on the label matching logic of the initial policy rules, and by combining more label dimensions, refining the port range or adding the target container group identifier, the scenario in which business rules in the smart medical system evolve over time or the business scale expands is simulated. Among them, the upper limit value of the first policy rule is calculated based on the number of requested labels, the number of first service ports and the number of first container groups, and the calculation formula is expressed as follows:

[0097] N max =C label ×P ports ×P pods ;

[0098] Among them, C label Indicates the number of requested tags, P ports Indicates the number of the first service port, P pods Indicates the number of the first container group.

[0099] Each set of incremental policy rules is sequentially distributed to the tool under test, and the performance parameters of the target node during policy execution are continuously monitored to form a time series of the first single-node performance parameters indexed by timestamps. The time series includes the following key dimensions: dynamic throughput, which records the throughput values in key time windows such as 1 minute, 5 minutes, and 10 minutes after each set of policy rules is distributed; latency jitter, which calculates the variance of latency during the incremental policy rule process; and resource utilization trends, which are 5-minute sliding averages of CPU, memory, and disk I / O. Performance parameters can be visualized using time series analysis tools (such as Prometheus + Grafana) to identify correlation characteristics (such as inflection points and saturation thresholds) between the number of policy rules and performance parameters.

[0100] In one embodiment of the present invention, for further explanation and limitation, in the second test environment, generating policy rules based on the flow control matching method in the test environment and obtaining performance parameter information of the tool under test executing the policy rules includes:

[0101] generating an initial policy rule based on the IP address range according to a classless inter-domain routing traffic matching mechanism based on the second preset test parameter and the IP address range;

[0102] Sending the initial policy rules based on the IP address range to the tool to be tested;

[0103] A second policy effective time and a second single-node performance parameter during the process of the tool under test executing the initial policy rule are obtained.

[0104] In an embodiment of the present invention, in a second test environment (i.e., simulating an out-of-cluster call business scenario, using a cross-cluster / cross-network architecture and IP address range traffic control mechanism), policy rules are executed for the tool to be tested (such as iptables or eBPF) and performance parameter information is obtained. Specifically, based on the second preset test parameters and the IP address range of the core application and the external caller, an initial policy rule based on the IP address range is generated in accordance with the Classless Inter-Domain Routing (CIDR) traffic matching mechanism. Among them, the second preset test parameters include the number of requested IP addresses, the number of second service ports, and the number of second container groups. In a specific application scenario, the number of requested IP addresses can be configured to be 10 to 200, the number of second service ports can be configured to be 10, and the number of second container groups can be configured to be 100. Of course, the configuration of the above parameters can also be customized according to actual application requirements, and the embodiment of the present invention does not make specific limitations.

[0105] The generated initial policy rules based on the IP address range are sent to the target node (such as a border firewall, gateway device or cross-cluster proxy node) through the API interface or configuration management module of the tool under test. Monitor and record the second policy effective time and the second single-node performance parameter during the execution of the policy rules by the tool under test. Among them, the second policy effective time is the time interval from the completion of the policy rule issuance to the actual effectiveness of the core application, reflecting the delay in policy synchronization and cross-domain network device rule updates. The second single-node performance parameter is the following indicators of the target node that are continuously collected during the policy execution period: throughput, request processing delay, and resource occupancy rate. Among them, throughput is the number of valid cross-domain requests processed by the core application per unit time, which can reflect the impact of policy rules on external business processing capabilities. The request processing delay is the response time threshold of 99% cross-domain requests, which is used to measure the sensitivity of policy rules to external business delays. Resource occupancy rate includes CPU usage, memory usage, network bandwidth utilization, etc., which is used to evaluate the degree of consumption of cross-domain network node resources by policy rules.

[0106] It's important to note that in smart healthcare scenarios, cross-domain data sharing must meet strict compliance requirements. By simulating the issuance of policy rules for different IP address segments, we verify the efficiency of the tools under test under complex security policies, providing a basis for medical institutions to select tools that support fine-grained cross-domain access control.

[0107] In one embodiment of the present invention, for further explanation and limitation, after obtaining the second policy effective time and the second single-node performance parameter during the process of the tool under test executing the initial policy rule, the method further includes:

[0108] According to the second preset step size and the second policy rule upper limit, gradually generating multiple groups of incremental policy rules based on the IP address range until the number of the incremental policy rules meets the second policy rule upper limit;

[0109] The single-node performance parameters of the tool under test when executing each set of the incremental strategy rules are obtained to obtain a second single-node performance parameter time series.

[0110] In an embodiment of the present invention, in a second test environment (i.e., simulating an out-of-cluster call business scenario, using a cross-cluster / cross-network architecture and IP address range flow control mechanism), in order to comprehensively evaluate the dynamic performance of the tool to be tested (such as iptables or eBPF) in a complex cross-domain network policy scenario, after obtaining the second policy effective time and the second single-node performance parameter under the initial policy rule, according to the second preset step size (such as increasing the number of IP address segment rules by 15% each time) and the second policy rule upper limit value, multiple groups of incremental policy rules based on the IP address range are gradually generated. The incremental policy rules are expanded based on the IP matching logic of the initial policy rules, and by introducing more IP address segments of external callers, refining the port range or adding cross-cluster proxy node identifiers, the scenario of cross-domain business rules evolving over time or expanding the scale of cooperation in the smart medical system is simulated. Among them, the upper limit value of the second policy rule is calculated based on the number of requested IP addresses, the number of second service ports and the number of second container groups. The specific method is the same as the calculation method of the upper limit value of the first policy rule under the first test environment, and will not be repeated here.

[0111] Each set of incremental policy rules is sent to the tool to be tested in sequence, and the performance parameters of the target nodes (such as border firewalls and gateway devices) during the policy execution process are continuously monitored to form a second single-node performance parameter time series indexed by timestamps. The dimensions of the time series include dynamic throughput, cross-domain delay jitter, resource occupancy trend, packet loss rate, and retransmission rate. The performance parameters are visualized through Prometheus+Grafana or ELK Stack, and the correlation characteristics between the number of policy rules and performance parameters (such as inflection points, saturation thresholds, and abnormal fluctuations) are identified in real time. By gradually increasing the number of cross-domain policy rules, the gradual expansion process of network policies in the medical system from regional pilots to national / cross-border collaboration is accurately simulated to ensure that the test results can truly reflect the cross-domain policy management needs in the production environment.

[0112] In one embodiment of the present invention, for further explanation and limitation, generating a global comparison test result of the tools under test based on the performance parameter information of each tool under test in the test environment includes:

[0113] For any tool under test, the policy effective time is converted into a delay factor, the single-node throughput and request processing delay in the single-node performance parameters are converted into an efficiency factor, and based on the fitting results of the single-node performance parameter time series, the performance change factor and the single-node policy rule upper limit achievement rate are extracted;

[0114] For any tool under test, retrieve an environment weighting model that matches the expected application business type of the tool under test, and calculate a test score index based on the weight coefficients assigned by the environment weighting model to the latency factor, efficiency factor, performance variation factor, and single-node policy rule upper limit achievement rate in the first test environment and the second test environment;

[0115] The test score index ranking results of the different tools to be tested are used as the comparison test results of the tools to be tested.

[0116] In the embodiment of the present invention, for any tool to be tested, its policy effective time t in the first test environment and the second test environment is actual (First policy effective time, second policy effective time) converted to delay factor T delay , the calculation formula is expressed as:

[0117]

[0118] Among them, t baseline The default standard policy takes effect time.

[0119] The single node throughput (Q actual ) and request processing delay (Dactual ) is converted to efficiency factor (E efficiency ), the calculation formula is expressed as:

[0120]

[0121] Among them, ω1 is the corresponding weight of single node throughput, Q max is the historical maximum single-node throughput, ω2 is the weight corresponding to the request processing delay, and D min is the historical minimum request processing delay, D max The maximum historical request processing delay.

[0122] Based on the fitting results of the single-node performance parameter time series (e.g., linear regression or polynomial fitting), the performance change factor S is extracted. Specifically, a trend line is fitted to the time series data, and the slope k and the coefficient of determination R2 are calculated. If the absolute value of the slope is less than a preset threshold (e.g., 0.01) and R2 is greater than 0.8, the performance is considered stable and S = 1; otherwise, S = max(0, 1 - |k| × Δt), where Δt is the time series span. The performance change factor reflects the stability of system performance during the incremental policy rule process.

[0123] Based on the single-node performance parameters under the first test environment and the second test environment, the single-node policy rule upper limit achievement rate is calculated, that is, the ratio of the actual single-node policy rule upper limit where the performance inflection point actually occurs to the policy rule upper limit value (the first policy rule upper limit value, the second policy rule upper limit value).

[0124] For any tool to be tested, the environment weighting model that matches its expected application business type is retrieved. The environment weighting model is constructed based on business demand analysis and includes weight allocation rules for the first test environment and the second test environment, as well as weight allocation rules for each factor in each test environment. For example, if the tool to be tested is mainly used for microservice isolation within a cluster, the first test environment has a higher weight (such as 0.7); if the tool to be tested needs to support cross-institutional medical data sharing, the second test environment has a higher weight (such as 0.6). According to the environment weighting model, the latency factor, efficiency factor, performance change factor and single-node policy rule upper limit achievement rate in the first test environment and the second test environment are respectively assigned corresponding weight coefficients, and then the corresponding weight coefficients of the above data sets are weighted and summed to obtain the test score index of the current tool to be tested. The test score indices of different tools to be tested are sorted, and the sorting results are used as the comparison test results of the global tool to be tested. The higher the test score index, the better the overall performance of the tool in the smart medical scenario.

[0125] The present invention provides a performance comparison test method for a network policy management tool. An embodiment of the present invention establishes at least one test environment, wherein different test environments are configured with different flow control matching mechanisms to simulate an actual business scenario in which a core application is called by multiple applications; for any tool to be tested, the tool to be tested is deployed into the test environment, policy rules are generated according to the flow control matching mechanism in the test environment, and performance parameter information of the tool to be tested executing the policy rules is obtained; a global comparison test result of the tool to be tested is generated according to the performance parameter information of each tool to be tested under the test environment, and by establishing a test environment configured with different flow control matching mechanisms, the test environment is made more in line with the actual business scenario, thereby comprehensively evaluating the adaptability, stability and scalability of the network policy management tool in a complex network, and meeting the needs of developers in this field for performance comparison test data.

[0126] Furthermore, as a response to the above Figure 1 The embodiment of the present invention provides a performance comparison test device for network policy management tools, such as Figure 3 As shown, the device includes:

[0127] A building module 31 is used to build at least one test environment, wherein different flow control matching mechanisms are configured in different test environments to simulate an actual business scenario in which a core application is called by multiple applications;

[0128] The testing module 32 is configured to deploy any tool under test into the test environment, generate policy rules based on the flow control matching mechanism in the test environment, and obtain performance parameter information of the tool under test executing the policy rules;

[0129] The generating module 33 is configured to generate a global comparison test result of the tools under test according to the performance parameter information of each tool under test in the test environment.

[0130] Furthermore, the building module 31 includes:

[0131] The first building unit is used to build a Kubernetes cluster containing multiple container groups to obtain a simulated microservice architecture;

[0132] A first configuration unit is configured to configure label information for the core application of the simulated microservice architecture, wherein the label information is used as matching information for flow control;

[0133] The second building unit is used to build a simulated cross-cluster or cross-network call architecture containing multiple external applications;

[0134] The second configuration unit is used to configure an IP address range for the core application that simulates a cross-cluster or cross-network call architecture, wherein the IP address range is used as matching information for flow control.

[0135] Furthermore, in the first test environment, the test module includes:

[0136] a first policy generating unit, configured to generate an initial policy rule based on the tag information according to a traffic matching and routing control mechanism of the metadata tag based on first preset test parameters and the tag information, wherein the first preset test parameters include the number of request tags, the number of first service ports, and the number of first container groups;

[0137] The first acquisition unit is used to send the initial policy rules based on the label information to the tool to be tested, and obtain the first policy effective time and the first single-node performance parameters during the process of the tool to be tested executing the initial policy rules; and use the first policy effective time and the first single-node performance parameters as the performance parameter information in the first test environment.

[0138] Furthermore, the testing module 32 further includes:

[0139] a second policy generation unit, configured to gradually generate, according to a first preset step size, multiple sets of incremental policy rules based on the tag information until the number of the incremental policy rules meets a first policy rule upper limit, wherein the first policy rule upper limit is calculated based on the number of request tags, the number of the first service ports, and the number of the first container groups;

[0140] The second acquisition unit is configured to acquire the single-node performance parameters when the tool under test executes each set of incremental strategy rules, and obtain a first single-node performance parameter time series.

[0141] Furthermore, in the second test environment, the test module 32 includes:

[0142] a third policy generating unit, configured to generate an initial policy rule based on the IP address range according to a classless inter-domain routing traffic matching mechanism based on second preset test parameters and the IP address range, wherein the second preset test parameters include the number of requested IP addresses, the number of second service ports, and the number of second container groups;

[0143] The third acquisition unit is configured to send the initial policy rule based on the IP address range to the tool under test, and acquire a second policy effective time and a second single-node performance parameter during the process of the tool under test executing the initial policy rule.

[0144] Furthermore, the testing module 32 further includes:

[0145] a fourth policy generation unit, configured to gradually generate multiple sets of incremental policy rules based on the IP address range according to a second preset step size and a second policy rule upper limit, until the number of the incremental policy rules meets the second policy rule upper limit, wherein the second policy rule upper limit is calculated based on the number of requested IP addresses, the number of second service ports, and the number of second container groups;

[0146] The fourth acquisition module is configured to acquire the single-node performance parameters when the tool under test executes each set of the incremental strategy rules, and obtain a second single-node performance parameter time series.

[0147] Furthermore, the generating module 33 includes:

[0148] a conversion unit configured to convert, for any tool under test, the policy effective time into a delay factor, convert the single-node throughput and request processing delay in the single-node performance parameters into an efficiency factor, and extract a performance change factor and a single-node policy rule upper limit achievement rate based on a fitting result of a time series of the single-node performance parameters;

[0149] A weight allocation unit is used to call an environment weighting model that matches the expected application business type of any tool to be tested, and calculate a test score index based on the weight coefficients assigned to the delay factor, efficiency factor, performance change factor and single-node policy rule upper limit achievement rate in the first test environment and the second test environment according to the environment weighting model;

[0150] The ranking unit is used to use the ranking results of the test score indexes of the different tools to be tested as the comparison test results of the tools to be tested.

[0151] The present invention provides a performance comparison test device for a network policy management tool. An embodiment of the present invention establishes at least one test environment, wherein different test environments are configured with different flow control matching mechanisms to simulate an actual business scenario in which a core application is called by multiple applications; for any tool to be tested, the tool to be tested is deployed in the test environment, policy rules are generated according to the flow control matching mechanism in the test environment, and performance parameter information of the tool to be tested executing the policy rules is obtained; a comparison test result of the global tool to be tested is generated according to the performance parameter information of each tool to be tested under the test environment, and by establishing a test environment configured with different flow control matching mechanisms, the test environment is made more in line with the actual business scenario, thereby comprehensively evaluating the adaptability, stability and scalability of the network policy management tool in a complex network, and meeting the needs of developers in this field for performance comparison test data.

[0152] According to one embodiment of the present invention, a storage medium is provided, wherein the storage medium stores at least one executable instruction, and the computer executable instruction can execute the performance comparison test method of the network policy management tool in any of the above method embodiments.

[0153] Figure 4 A schematic structural diagram of a computer device provided according to an embodiment of the present invention is shown. The specific embodiment of the present invention does not limit the specific implementation of the computer device.

[0154] like Figure 4 As shown, the computer device may include: a processor 402 , a communications interface 404 , a memory 406 , and a communication bus 408 .

[0155] The processor 402 , the communication interface 404 , and the memory 406 communicate with each other via a communication bus 408 .

[0156] The communication interface 404 is used for network communication with other devices such as clients or other servers.

[0157] The processor 402 is configured to execute the program 410 , and specifically to execute the relevant steps in the embodiment of the performance comparison test method for the network policy management tool.

[0158] Specifically, the program 410 may include program codes, which include computer operation instructions.

[0159] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The one or more processors included in a computer device may be of the same type, such as one or more CPUs, or may be of different types, such as one or more CPUs and one or more ASICs.

[0160] The memory 406 is used to store the program 410. The memory 406 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0161] The program 410 may be specifically configured to cause the processor 402 to perform the following operations:

[0162] Establishing at least one test environment, wherein different flow control matching mechanisms are configured in different test environments to simulate an actual business scenario in which a core application is called by multiple applications;

[0163] For any tool under test, deploy the tool under test into the test environment, generate policy rules based on the flow control matching mechanism in the test environment, and obtain performance parameter information of the tool under test executing the policy rules;

[0164] A global comparison test result of the tools under test is generated according to the performance parameter information of each of the tools under test in the test environment.

[0165] Obviously, those skilled in the art will appreciate that the various modules or steps of the present invention described above can be implemented using a general-purpose computing device, centralized on a single computing device, or distributed across a network of multiple computing devices. Alternatively, they can be implemented using program code executable by a computing device, which can then be stored in a storage device and executed by the computing device. In some cases, the steps shown or described can be performed in a different order than that shown, or can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0166] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A performance comparison test method for a network policy management tool, characterized in that: include: Establishing at least one test environment, wherein different flow control matching mechanisms are configured in different test environments to simulate an actual business scenario in which a core application is called by multiple applications; For any tool under test, deploy the tool under test into the test environment, generate policy rules based on the flow control matching mechanism in the test environment, and obtain performance parameter information of the tool under test executing the policy rules; A global comparison test result of the tools under test is generated according to the performance parameter information of each of the tools under test in the test environment.

2. The method according to claim 1, characterized in that The test environment includes a first test environment for simulating a business scenario of calling within the cluster and a second test environment for simulating a business scenario of calling outside the cluster. The process of setting up the first test environment includes: Build a Kubernetes cluster with multiple container groups to simulate a microservice architecture. Configuring label information for the core application of the simulated microservice architecture, wherein the label information is used as matching information for flow control; The process of setting up the second test environment includes: Build a simulated cross-cluster or cross-network call architecture that includes multiple external applications; An IP address range is configured for the core application simulating the cross-cluster or cross-network call architecture, wherein the IP address range is used as matching information for flow control.

3. The method according to claim 2, characterized in that In the first test environment, generating policy rules according to the flow control matching mechanism in the test environment and obtaining performance parameter information of the tool under test executing the policy rules include: generating an initial policy rule based on the tag information according to a traffic matching and routing control mechanism of the metadata tag based on first preset test parameters and the tag information, wherein the first preset test parameters include the number of request tags, the number of first service ports, and the number of first container groups; Sending the initial policy rule based on the tag information to the tool under test, and obtaining a first policy effective time and a first single-node performance parameter during the tool under test's execution of the initial policy rule; The first policy effective time and the first single-node performance parameter are used as the performance parameter information under the first test environment.

4. The method according to claim 3, characterized in that The performance parameter information further includes a first single-node performance parameter time series. After obtaining the first policy effective time and the first single-node performance parameter during the process of the tool under test executing the initial policy rule, the method further includes: According to a first preset step size, gradually generate multiple sets of incremental policy rules based on the tag information until the number of the incremental policy rules meets a first policy rule upper limit, where the first policy rule upper limit is calculated based on the number of request tags, the number of the first service ports, and the number of the first container groups; The single-node performance parameters of the tool under test when executing each set of incremental strategy rules are obtained to obtain a first single-node performance parameter time series.

5. The method according to claim 2, characterized in that In the second test environment, generating policy rules according to the flow control matching mode in the test environment and obtaining performance parameter information of the tool under test executing the policy rules include: generating, according to a second preset test parameter and the IP address range, an initial policy rule based on the IP address range in accordance with a classless inter-domain routing traffic matching mechanism, wherein the second preset test parameter includes the number of requested IP addresses, the number of second service ports, and the number of second container groups; Sending the initial policy rules based on the IP address range to the tool to be tested; A second policy effective time and a second single-node performance parameter during the process of the tool under test executing the initial policy rule are obtained.

6. The method according to claim 5, characterized in that The performance parameter information further includes a second single-node performance parameter time series. After obtaining the second policy effective time and the second single-node performance parameter during the process of the tool under test executing the initial policy rule, the method further includes: According to a second preset step size and a second policy rule upper limit, gradually generating multiple sets of incremental policy rules based on the IP address range until the number of the incremental policy rules meets the second policy rule upper limit, wherein the second policy rule upper limit is calculated based on the number of request IP addresses, the number of second service ports, and the number of second container groups; The single-node performance parameters of the tool under test when executing each set of the incremental strategy rules are obtained to obtain a second single-node performance parameter time series.

7. The method according to claim 1, characterized in that The test environment includes a first test environment and a second test environment, the performance parameter information includes a policy effective time, a single-node performance parameter, and a single-node performance parameter time series, and generating a global tool-under-test comparison test result based on the performance parameter information of each tool under test in the test environment includes: For any tool under test, the policy effective time is converted into a delay factor, the single-node throughput and request processing delay in the single-node performance parameters are converted into an efficiency factor, and based on the fitting results of the single-node performance parameter time series, the performance change factor and the single-node policy rule upper limit achievement rate are extracted; For any tool under test, retrieve an environment weighting model that matches the expected application business type of the tool under test, and calculate a test score index based on the weight coefficients assigned by the environment weighting model to the latency factor, efficiency factor, performance variation factor, and single-node policy rule upper limit achievement rate in the first test environment and the second test environment; The test score index ranking results of the different tools to be tested are used as the comparison test results of the tools to be tested.

8. A performance comparison test device for a network policy management tool, characterized in that: include: A building module for building at least one test environment, wherein different flow control matching mechanisms are configured in different test environments to simulate an actual business scenario in which a core application is called by multiple applications; A testing module is configured to deploy any tool under test into the test environment, generate policy rules based on a flow control matching mechanism in the test environment, and obtain performance parameter information of the tool under test executing the policy rules; The generating module is used to generate a global comparison test result of the tools under test according to the performance parameter information of each tool under test in the test environment.

9. A storage medium storing at least one executable instruction, wherein the executable instruction causes a processor to execute an operation corresponding to the performance comparison test method for a network policy management tool according to any one of claims 1 to 7.

10. A computer device comprising: A processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform an operation corresponding to the performance comparison test method of the network policy management tool according to any one of claims 1 to 7.

Images