Editor's note: The last article of our three-part series on how to buy application delivery controllers examines...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
benchmarking. In case you missed it, part 1 looked at ADC terminology and use cases, and part 2 addressed ADC feature sets and platforms to help you make a buying decision.
Many application delivery controller (ADC) vendors help you size your ADC by rating the maximum transactions per second (TPS) throughput each class of device can achieve. This raises the question of how to determine what an ADC can really deliver -- something you can only do by benchmarking it.
Specs are easy to write, but what do they mean?
When you're getting ready to buy that product, remember that spec sheets are easy to write. Sometimes vendors' capacity claims will be theoretical rather than actual -- without noting that fact. So performance benchmarking before you buy is always the best course. If that's not practical, at least get the vendor to guarantee that if the ADC's performance doesn't match its claims, it will offer a refund.
ADCs are powerful, complex systems. The only way to benchmark them effectively in a lab is to use commercial-class benchmarking tools like those offered by Ixia. In our most recent tests at The Tolly Group, we used a pair of Ixia XT80-V2 appliances to drive the ADCs with simulated application traffic, representing both the client and server sides of each conversation.
ADC performance is largely determined by two factors: the complexity of the workload chosen and object sizes. For ADCs, performance is typically measured in TPS.
Object size determines ADC performance and throughput
Let's start the discussion with TPS, specifically, object size. The object size represents the application data processed by the ADC. Unlike switches and routers -- where the "object" is typically referred to as a frame or packet that has a maximum standard size of 1518-bytes -- application objects are not constrained to fitting in a single packet. The typical ranges tested run from 128 bytes to 32 KB.
Most ADCs we've benchmarked do well across the range of object sizes. Keep in mind, however, that the larger the object size, the fewer transactions can be processed per second because it simply requires more time to move larger objects through the system than it does for smaller objects.
Ultimately, the performance of your ADC will be largely dictated by the complexity of the processing. Simply put, an ADC tasked with the simple processing associated with traditional load balancing will deliver a higher transaction rate than the same ADC responsible for header and URL rewrites associated with Web application functionality. Finally, an ADC handling all of the cryptography associated with Secure Sockets Layer traffic will have the lowest throughput of all. That's because server offload function consumes significant processing power.
Keep in mind: Not all ADCs are created equal
Of course, this performance is all relative within a single system. Our testing over the years has shown not all ADCs are created equal. Even competing systems that claim the same transaction throughput don't always deliver. In fact, our tests have shown that in some cases, comparable systems from different vendors can exhibit performance differences of greater than 100% when evaluating the throughput of the devices.
Last, keep this in mind: To get the best ADC for your money, make sure you model traffic that closely resembles your production environment.
Part 1: Honing your application delivery platform: Buying the right ADC
Part 2: Network load balancer and ADC options: What's best for you?