Load Balancer Performance: Key Considerations for Optimal Results
Article ID: 316296
Updated On:
Products
Issue/Introduction
Below is a screenshot of LB performance metric for XL BM Edge, and various sizes of the Edge VM.
Virtual Server (VS) maximums for various LB sizes are as follows:
L7_MAX_CONNECTIONS_XLARGE = 8400000 L7_MAX_CONNECTIONS_LARGE = 4200000 L7_MAX_CONNECTIONS_MEDIUM = 525000 L7_MAX_CONNECTIONS_SMALL = 105000
These numbers do not represent fixed values from a specific LB setting but result from internal tests conducted on various NSX LB sizes and form factors, specific to NSX-T 3.0.
Another important factor is the LB size, also we do not recommend fixed settings for optimal LB performance. The effectiveness depends on factors such as application type, traffic characteristics, throughput, and other parameters. Fine-tuning settings is recommended based on these dependencies.
The below information breaks down LB processes for various sizes, and gives clarity on the relationship between LB size, Edge Size, and the number of processes. It also highlights the importance of aligning LB size with available resources (Edge size) for optimal performance.
LB Form factor and LB processes:
LB Small = 1 LB process
LB Medium = 3 LB process
LB Large = 6 LB process
LB XLarge = 12 LB process (or if running on Edge Node for BareMetal #processes = # BM_Cores / 4)
Results for the LB_Small on EdgeNode-VM_Large
We do not test LB_Small on EdgeNode-VM_Large because we expect the performance to be same as LB_Small on EdgeNode-VM_Medium.
This is because EdgeNode-VM_Medium already can provide all the cpu resources needed by LB_Small, adding more resources (via EdgeNode-VM_Large) won't have any significant impact.
Results about Large-LB on EdgeNode-VM_Large:
An EN VM_Large uses 4 of its vCPU for DPDK and so has 4 remaining for other services such as LB.
LB Large runs 6 LB process.
So even if we support LB_Large on Edge_VM_Large, the LB_Large will not run at its full potential on EdgeNode-VM_Large (6 processes running on 4 vCPU).
For best performance, we recommend running LB_Large on EdgeNode-VM-XLarge or EdgeNode-BM.
Performance impact on an EdgeNode with many LB
We do not reserve CPU for each of the LBs, so it cannot be answered that cut-and-dry.
Performance depends on the traffic pattern, and it will be hard to generalize what to expect.
If there are 2 Medium LBs but say all the traffic is sent to only one of them.
Then expected performance will be same as or very close to what it would be if there was only one 1 Medium LB.
Second LB should have no observable impact.
On the other hand, if both LBs are stressed at the same time, then the performance of each may be lower than half as there is some overhead associated with context switching between the two.
As evident from the preceding notes, the performance of the LB is intricately linked to its size. This variation is further influenced by the number of processes operating on each size, which, in turn, is connected to the size of the Edge, given that each Edge is equipped with a set number of vCPUs. The performance of a LB, even with the provided details, continues to be subject to the dependencies discussed earlier.
It is essential to recognize that the internal tests conducted on NSX version 3.0 serve as a foundation for understanding LB performance but may not precisely mirror real-world customer setups. The variables encountered in customer environments, such as diverse applications, traffic patterns, and infrastructure configurations, can impact LB performance differently. Therefore, it is advisable to use the internal test results as a guideline while considering the unique characteristics of each deployment.
Environment
Feedback
