 |
More Details on Our Performance Tests
Throughput testing typically consists of bit-blasting the device under test
(DUT) to find when the DUT begins to fail. And though bit-blasting is fine for
testing Layer 2/3 infrastructure devices, it doesn't really test the performance
of DUTs that have to maintain session state while passing traffic. With
firewalls?both stateful packet filtering and application proxies?new TCP/UDP
sessions start and end while traffic is flowing through the DUT. Because the
firewall is kept busy tracking a dynamic traffic load, session management
becomes a serious performance factor.
We created three tests to test specific aspects of firewall performance. Our
connection-rate test determined how many connections per second the firewall
could handle. Although typical traffic patterns are predictable and can be
scaled to, you'll always need to accommodate spikes in traffic. Our maximum
sustained connections test determined how many connections the DUT could hold
open. This finds the upper limit of sustained connections. Finally, our
throughput test determined how much data could be passed through the firewall
over HTTP while opening and closing sessions. This test is a better determiner
of firewall performance than a bit-blast test over a few open sessions because
the firewall is doing real work similar to what you would see on a real network.
Connection Rate
In WebReflector, we created four Web servers for the clients connect to and set
up 500 connections per second for a 60-second time period. The connections were
HTTP/1.0 with KeepAlive turned off, and the file was an 8-byte file (we didn't
want to saturate the link). Next, we increased the connections per second by 500
over a 60-second time period. That gave us a gradual increase in connections per
second without triggering SYN flood detection. We continued to increase the
connections per second until we saw failures. We then stepped the test back to
the failure point and ran each test for 10 minutes until we found the sustained
connection rate. Since the WebAvalanche simulated Web users, as one connection
closed, another was opened, maintaining the desired connection-per-second rate.
This exercised the firewall's state and TCP tables.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
