The feature in Big-IP that lets it respond to applications via Web services has been a part of the product line for nearly two years, but developers can just now take advantage of it. Although SNMP typically can be used within an application, developers often hesitate to use it because of its inherent complexity (see sidebar below for more on SNMP versus Web services for load-balancing).

Applications use SOAP (Simple Object Access Protocol) to manage the Big-IP 4.5. For example, an application overburdened with requests can remove the server on which it runs for scheduled maintenance. It later can have the server added back to the pool by making a simple SOAP-based call to the Big-IP. This lets developers design applications that can leverage Web services to control the load sent.

All is not perfect in Big-IP land, however. Although you can route traffic based on content in the TCP payload, the task must be done manually--including the conversion of string-based content to hexadecimal values. The work is nightmarish, but once you're done, the system works like a charm.

Good • Routes traffic and persists connections based on TCP payload. • Web services management puts apps in control. • Supports HTTP, HTTP/S, SOAP and custom protocols. Bad • TCP payload switching rules must be written manually, and content must be represented hexadecimally. • Some protocols, such as POP3 and SMTP, won't benefit from the new switching capability.

Admins also need to be aware of introducing latency. The location of the data in the packet stream affects the amount of time it takes to process the request. The Big-IP must buffer the packets until it can find matching content. The default buffer size is 16 KB, and F5 says performance is likely to degrade with larger buffers.

Even if you don't use Big-IP 4.5 for Web services deployments, you can route traffic and persist connections based on any HTTP header. This gives you more control over application traffic and more flexibility in server-farm design than you get with most load-balancing solutions.

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.

Vendor Info Big-IP 4.5, $9,990 to $57,990 (software upgrade is free for those with maintenance support contracts), F5 Networks, (888) 882-4447, (206) 272-5555. www.f5.com

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.

Technology editor Lori MacVittie has been a software developer, network administrator and member of the technical architecture team for a global transportation and logistics organization. Write to her at lmacvittie@nwc.com.

Load-Balancing: SNMP vs. Web Services

Using Web services in the load-balancing decision-making process is more flexible and easier to implement than other methods, including using SNMP.

Load balancers have had, for many years, a given number of algorithms to use when determining to which server a request should be directed. The industry standard, round-robin-based algorithms give little concern to the load on any server, while methods such as least connections and response-time average give at least some weight to the responsiveness of the individual servers in the farm.

Several years ago a few load-balancing vendors introduced the ability to utilize SNMP variables as a means of determining whether a server could handle a request. But these variables were attached to the server and host OS, not an application. Most application servers offer more detailed information on the server, such as memory and heap usage, but offer little in the way of detailed performance information on specific applications.

Although a developer can embed SNMP functionality into an application, this is almost never done because of the complexity of the task--even if using a development library specifically designed for the task.

That's what makes the ability to utilize Web services so exciting. With Web services you can give the load balancer more accurate information regarding to which servers traffic should be routed, based on specific, application-level performance indicators that are decided upon by the people who know best what the application can handle: the developers.