F5 Friday: Protocols are from Venus. Data is from Mars.

Accelerating protocols via optimization is actually very different from accelerating the transfer of data.

It is often the case that we, as an industry, use the terms “optimization” and “acceleration” interchangeably. Consider that solutions designed to improve the transfer of data across a WAN can be called WAN Optimization as easily as it is known as WAN Acceleration.

Interestingly enough, solutions that make web applications specifically go “faster” were always termed Web Acceleration and never Web Optimization. The difference lies underneath, in what each focuses upon: optimization is almost always related to protocol efficiency and processing speed, while data acceleration is always focused on improving the transfer of data across a network. If you aren’t careful, applying a protocol optimization solution to what is really a data transfer issue can actually result in making the problem worse, and vice versa.

THE ACCELERATION HIERARCHY

In general, acceleration solutions are a means of achieving a business goal: faster delivery of data while optimization remains a technique applied generally to protocols as a means of achieving that goal. Acceleration is strategic, optimization is a tactic.

Acceleration is what we want to do – whether that’s by improving the transfer of data across a WAN or by improving the speed at which web application responses are delivered to end-users. How we do that is through the use of technology and techniques that either act upon the relevant protocols, e.g. TCP, IP, HTTP, or by manipulating data by compressing, de-duplicating or caching it.

The difference is important because acceleration techniques that act upon data only are often divorced from the protocols such that solutions can be deployed individually, i.e. as stand-alone solutions. Consider web acceleration solutions like F5 BIG-IP WebAccelerator (WA). WA can be deployed as part of a unified delivery strategy, integrated with other application delivery solutions like load-balancing and web application security, or it can be deployed all on its own. Acceleration solutions generally modify and manipulate data as a means to achieve faster transfer of data.

Optimization, however, is a technique that is generally applied to protocols and primarily focuses on improving processing, i.e. execution, speed. In most cases an improvement in processing speed reduces latency which ultimately results in a faster response, hence the reason it is often conflated with acceleration. But optimization does not always result in accelerated transfer of data. Consider the case where the problem is a congested WAN connection. Optimizing the TCP protocol by using technology like OneConnect to more efficiently manage TCP connections or leveraging TCP Express improves the processing speed but it does nothing to address the impact of WAN congestion on TCP-based communication. The savings in response time that come from the improved processing speed may be offset by the congestion such that the response is barely, if at all, accelerated.

Conversely, the data deduplication techniques used by WAN optimization controllers like BIG-IP WAN Optimization Module (WOM) only address the transfer speed of data across the WAN. It cannot improve efficiency or processing speed on downstream infrastructure components or for the application itself. If the cause of poor performance is a degradation of responsiveness by the web application server due to high load, a WAN optimization solution will not be able to address the problem and its improvements in transfer speed may be offset negatively by the increase in response time that comes from highly loaded servers.

LEVERAGING the RELATIONSHIP

This is why it’s important to understand where the problem with performance may lie within the delivery chain. Trying to use a data-focused acceleration solution to address what is a protocol-layer inefficiency issue may be counter-productive.

Conversely, speeding up the processing of protocols when the issue is a highly congested WAN link or poorly performing web application server may leave you scratching your head as to why the “acceleration” solution didn’t achieve the positive outcome for which you implemented it.

It is also the case that a set of disconnected acceleration solutions can be part of the problem. Solution sprawl induces latency that is not easily addressed by any solution. There is a certain amount of network overhead required each time a new infrastructure component is introduced into the architecture. There’s the transfer time over the network, the processing time on the device to perform its function, and all associated protocol overhead – TCP session setup and teardown is not inexpensive in terms of latency. If you aren’t viewing “acceleration” as the aggregation of solutions that address individual performance challenges you may end up with multiple pieces of infrastructure that actually make performance worse because the improvement in performance on each device is offset by the increase imposed by overhead. For an in-depth (read: very technical and fascinating) discussion on how this impacts web application performance, I highly suggest you take a read of Joe Weinman’s latest paper, “ As Time Goes By: The Law of Cloud Response Time" Joe again leverages his phenomenal understanding of mathematics and takes a formulaic approach to the complex relationship between network, infrastructure and applications in a way that makes it possible to logically assess performance. Joe’s approach provides insight into cloud-hosted application performance – in particular those factors that are most impactful. The results may surprise you.

UNIFIED APPLICATION and DATA DELIVERY

It is for this reason we continue to support the notion of unified application and data delivery ; of a “top to bottom” approach that addresses not only the “end-to-end” performance challenges inherent in delivering applications today but also addresses those challenges that exacerbate or arise from implementing solutions to solve the former.

Leveraging an integrated, unified application and data delivery platform like F5 BIG-IP that recognizes the relationship between acceleration and optimization, between protocols and data, between the network and applications, can positively enhance performance holistically, applying the right optimization and the right acceleration technique at the right time based on context. A contextually aware, unified application and data delivery service platform means that optimization does not negatively impact attempts at data acceleration, and vice-versa. It also allows the technique most likely to produce a positive outcome to be applied to the problem with little-to-no impact on delivery chain performance. In the mathematical formula laid out by Joe, leveraging a unified application delivery system can reduce n and thus have a positive impact on distributed web-application performance.

In the rush to improve application performance and comply with service level agreements it is often the case we apply techniques that while improving individual component performance do not positively impact the aggregate performance of the application delivery process. It is important to not only understand where performance challenges are hiding in an architecture, but that we understand which of the many techniques available will address those challenges in such a way as to affect a positive outcome for the entire application delivery chain. A unified application and data delivery service platform can reduce the negative impact of solution sprawl while simultaneously improving the performance of both protocols and data transfers, resulting in an aggregate net gain in performance.

Published Apr 15, 2011

Version 1.0

dynamic infrastructure

f5 friday

infrastructure

integration