What infrastructure efficiency means at service provider scale

Shoaib YusufPrincipal Product Marketing Manager | F5

Service providers have always measured network performance closely. Throughput and latency remain important, but they do not tell operators how much infrastructure is required to deliver that performance.

CPU and memory consumption affect server requirements, workload density, power, cooling, and the amount of capacity left for other services. Those factors become increasingly important as more network functions move into Kubernetes environments.

F5 commissioned The Tolly Group to independently evaluate the infrastructure efficiency and performance of F5 BIG-IP Cloud-Native Edition compared with a tested virtual network function, or VNF, deployment. Both were evaluated in a Red Hat OpenShift environment using two representative service provider workloads: DNS query processing and Layer 4 plus Carrier-Grade NAT, or L4+CGNAT.

Tolly measured throughput and latency together with CPU and memory consumption. The goal was to understand how much useful work each deployment could deliver and what infrastructure resources were required to deliver it.

Measure the infrastructure behind performance

The test results show why resource consumption is worth looking at alongside traditional performance metrics.

In a Kubernetes environment, unused CPU and memory can remain available for the platform to schedule other workloads, depending on cluster resource policies. Lower resource consumption can therefore provide more flexibility in how operators use the infrastructure already deployed.

The two Tolly workloads produced different performance profiles, but both showed substantial reductions in CPU requirements for BIG-IP Cloud-Native Edition in the tested configuration.

DNS: Higher throughput with less CPU

DNS is a high-volume service where large numbers of relatively small transactions must be processed quickly. The Tolly DNS test used DNS Express functionality within BIG-IP and measured sustained query throughput, CPU consumption, memory efficiency, and average latency.

BIG-IP Cloud-Native Edition sustained 64,985 DNS queries per second, compared with 34,463 queries per second for the tested VNF. That represents nearly 1.9 times the DNS query throughput.

The CPU requirements were also substantially different. BIG-IP Cloud-Native Edition consumed 341 mCores, while the VNF consumed 4,003 mCores, essentially the full CPU resource of the four cores allocated to the test. CNE therefore used 91.5% less CPU in the tested configuration.

Average DNS latency was 1.47 milliseconds for CNE compared with 2.82 milliseconds for the VNF, a 48% reduction.

Tolly also normalized DNS performance against memory consumption. BIG-IP Cloud-Native Edition delivered 515,759 queries per second per gigabyte of memory, compared with 4,194 for the VNF, resulting in 123 times as many DNS queries per gigabyte of memory in the test.

F5 BIG-IP Cloud-Native Edition delivered nearly 1.9× higher DNS throughput while using 91.5% less CPU and cutting average latency by 48% in the tested configuration.

For operators running high-volume DNS services, the practical consideration is how much infrastructure is required to support a given workload. Lower CPU and memory requirements can leave more capacity available within the Kubernetes environment for additional services or future growth.

L4+CGNAT: Similar throughput, fewer resources

The L4+CGNAT test produced a different result.

Both deployments delivered approximately 3 Gbps of throughput. BIG-IP Cloud-Native Edition sustained 3,064 Mbps, while the tested VNF sustained 3,177 Mbps, making the VNF result about 3.7% higher.

The difference in infrastructure consumption was considerably larger.

BIG-IP Cloud-Native Edition used 812 mCores, compared with 4,000 mCores for the VNF. That represents 79.7% lower CPU consumption.

Memory consumption was 129 MiB for BIG-IP Cloud-Native Edition and 8,396 MiB for the VNF, resulting in a 98.5% reduction in the tested configuration.

Tolly also measured p95 latency of 4.73 milliseconds for BIG-IP Cloud-Native Edition compared with 26 milliseconds for the VNF, an 82% reduction.

In the tested environment, throughput remained within 3.7%, while BIG-IP Cloud-Native Edition used substantially less CPU and memory and delivered lower p95 latency.

F5 BIG-IP Cloud-Native Edition maintained comparable L4+CGNAT throughput while reducing CPU consumption by 79.7%, memory by 98.5%, and p95 latency by 82% in the tested configuration.

Why resource efficiency matters

Service provider environments often need to support high traffic volumes across infrastructure where CPU, memory, power, and physical capacity are finite.

Resource efficiency can affect how many workloads fit within a cluster, how much capacity remains available for new services, and how much infrastructure is required as demand increases.

That is where the Tolly results are most useful. DNS and L4+CGNAT were two representative workloads selected for independent testing. They do not represent every function available within BIG-IP Cloud-Native Edition, but they provide concrete examples of how a Kubernetes-native deployment model can change the resource profile of network services. The findings should therefore be understood as results for the tested workloads and configurations, rather than performance claims for other BIG-IP Cloud-Native Edition services.

The results also give operators another metric to consider when evaluating network-function architecture. Throughput remains essential, but CPU, memory, and latency help show what it costs in infrastructure terms to deliver that throughput.

For service providers planning Kubernetes-based network services, that information can help inform capacity planning, workload placement, and infrastructure utilization decisions.

To learn more, read the full Tolly Group report for an independent assessment of F5 BIG-IP Cloud-Native Edition service provider infrastructure efficiency. Also, check out our blog, “Cloud-native modernization for the AI and 5G/6G era.”

About the Author

Shoaib YusufPrincipal Product Marketing Manager | F5

More blogs by Shoaib Yusuf