Connection capacity is important because a single user request can involve many TCP connections. For example, a single request for the home page of many news sites can involve 100 or more TCP connections due to web design trends, ad servers, streaming media servers, and other factors.
Connection rate matters because web sites may be hit with huge bursts of traffic. One common example is flash mobs, where some event (e.g., availability of a new product or concert tickets) causes a huge spike in connection request rates. Another common use case is disaster recovery, where the loss of one set of servers causes traffic to be migrated to a new set of servers.
In the capacity tests, we configured Spirent Avalanche never to request one web object per connection and then do nothing for the rest of the test. Since Avalanche doesn't age out TCP connections by default, we were able to build up progressively larger connection counts, well into the tens of millions.
F5 claims the BIG-IP 10000v supports 36 million concurrent connections. We validated that claim, sustaining 36,000,291 unique TCP connections for a 60-second period.
In the rate tests, we used HTTP 1.0 to ensure each new Web request would force a new TCP connection. Here again, F5 exceeded its rated capacity of 850,000 connections per second. In our tests, the BIG-IP sustained an average of 869,183 new connections per second for a 60-second period.
We did find a couple of fit and finish issues in the F5 firewall, both minor. The firewall failed to process a minuscule percentage of TCP connections on the order of dozens to hundreds of failures out of millions to tens of millions of transactions. We'd configured Spirent Avalanche to abort any transaction taking more than 1 second, which is an eternity at 10G Ethernet rates. For a tiny number of attempts, TCP handshakes never completed. (All tests ran without errors between a pair of Avalanche C100 appliances.)
In an even smaller number of cases, the F5 firewall transmitted an extra TCP reset (RST) packet during connection shutdown. This is odd considering we'd configured Spirent Avalanche to close connections with TCP finished (FIN) and not RST flags. F5's explanation is that connection state between the firewall's client and server sides wasn't synchronized for a tiny number of connections, and in these cases the firewall sent a gratuitous RST packet. (Older versions of Windows Windows XP and earlier, and Windows Server 2003 and earlier tear down TCP connections with a RST rather than a FIN packet. This saves a little memory on the client, but it's a terrible idea for intermediate devices like firewalls, since they will continue to try to track connection state). Again, though, we consider both issues minor annoyances.