Understanding NSv Firewall Performance

This article provides a general guideline in assessing and improving the SonicWall NSv's performance and reliability when deployed in a Virtual Network.

In Virtualization, the same physical resource is shared by multiple Virtual Machines. Virtual Machines share access to CPUs, physical network cards, storage, memory etc. In an ESXi environment on default settings, all VMs on the same ESXi host utilize an equal share of available resources. A hypervisor also enables competitive memory and CPU utilization ratios, and it is possible to commit memory/processors to a VM that exceeds the available resource on the physical machine itself. This is called memory/processor overcommitment or oversubscription.

Performance of the NSv or any VM will be directly dependant on the hardware infrastructure of the virtual environment (including the network connections), and the availability of the shared resources. The overall performance of the NSv will also be dependent on the CPU architecture of the ESXi host, including the clock speed, L2 cache, core type and number of cores.

If the NSv is deployed in an environment that is already overutilized, then the NSv installation will have to compete for existing CPU resources and can result in suboptimal performance.

A general rule of thumb for ensuring peak performance would be to have the number of available physical cores on the host's CPU to at least equal the maximum cores supported by the NSv version being used. More is better when considering CPU clock speed and L2 cache. Choosing the right CPU microarchitecture (eg. Haswell, Broadwell, Skylake, Kaby Lake) is important for multi-threaded workloads.

TIP: Further reading: Memory Overcommitment in the ESX Server, Comparison of CPU microarchitectures, vSphere Resource Management Guide