Major Changes for Big-IP: Page 2 of 4

Practical Application

I tested Big-IP 4.5 in our Green Bay, Wis., Real-World Labs® on a Big-IP 2000. The Big-IP 2000 has 16 10/100 ports, 2 GB of fiber and 512 MB of RAM. Using Ixia's IxWeb, I set up a test with four server ports and seven client ports. The clients requested 2-KB files and sent a custom HTTP header.

I ran a baseline test to determine F5's core switching capabilities without custom rules based on TCP content. I then created two Web server pools on the Big-IP, one for requests containing the custom header and one for requests without the header. In both tests, the requests were routed correctly. The results were nearly equivalent in terms of gets per second, with the Big-IP handling approximately 10,900 gets/second in baseline and subsequent tests. But latency was an issue when the Big-IP had to switch based on TCP content. The average time to first byte jumped to 1,850 ms from 292 ms in baseline tests.

Considering the intense demands placed on the device to buffer and search the payload, this performance was acceptable. However, the Big-IP 2000 produced a lower transaction rate than expected for a content-aware device compared with previous versions of the Big-IP and devices from Array Networks. Still, the increased flexibility in switching the traffic and in server-farm design more than make up for the increase in latency.

I reconfigured the Big-IP to search the TCP content for a value found within the payload (the value of an XML tag posted by a client) and also ran a test using ApacheBench, and discovered the Big-IP can route traffic based on specific content in the payload.