Making Apps Go Faster

As we continue to break up the data center by breaking applications and the networks on which they depend, one business aphorism remains true: speed is king. Performance remains a business level concern that impacts everything from sales to productivity, taking nibbles and sometimes bites out the bottom line.

A recent article on DZone, How Fast Are Web Applications in 2016, dove into some specifics with respect to performance, noting that “for a typical web application, 4.2% of the transactions are abandoned.” That’s based on “five billion user interactions with 500 different web-based applications.”

How that translates to dollars and impacts profit or productivity depends on the business model, of course. It could represent millions or billions of dollars, or hours lost and customers angrified by increasing call times.

Regardless, performance remains a significant consideration for both developers and operations. And by operations I mean all operations – infrastructure, network, storage, and security. Our most recent State of Application Delivery survey continued to support the attitude across all IT roles that performance is critical. It was the least likely to be given up for better security (only 9% would make such a deal) and was cited by 14% of respondents as a significant challenge faced in multi-cloud implementations.

Despite this, only 38% indicated they employ app acceleration services now, and only 22% planned on implementing in the next year. A somewhat surprising 40% said they had no plans to deploy or use app acceleration.

This may be because the perception of what “app acceleration” entails is somewhat cloudy. And not because of “the cloud”, either, but because it’s evolved and transformed over the years from QoS to browser-based delta refresh and caches to so called application front ends (AFE) that are in reality specialized proxies with very performance-focused capabilities.

Most of the time when we think “app acceleration” we think of compression and caching, minification and image optimization. We don’t think of protocol optimizations as part of the whole “We need Warp 9, Scotty” mentality that pervades business and user expectations today. But we should.

Oh, we’re seeing protocol offloading in use a lot these days. In the course of 2015, the use of client-side SSL offload (the side that manages secure HTTP with users) increase from just under 80% to nearly 100%. This is not surprising given the increased attention put on secure communications with efforts like “Let’s Encrypt!” and “SSL Everywhere.” SSL/TLS impacts performance (and not in a good way), especially as load increases. Offloading to a capable proxy makes sense, and we’re seeing organizations do just that to offset the performance impact of making everything secure.

But we aren’t seeing a similar increase on the back end, on the server-side, of the equation. The use of TCP Multiplexing to improve performance (and simultaneously increase capacity of resources) hasn’t changed much in the past year. Just under half (about 46% consistently) of organizations are using this unsung optimization technique.

Which is scary when you consider that many of those same organizations are currently experiencing container fever.

Why is it scary? Let me tell you why… While it’s entirely possible that virtualization has enabled organizations to fine-tune each instance’s TCP stack to ensure the highest performance per app possible, the arrival of containers threatens that model. That’s because containers share a single network stack. Tuning for one app deployed in one container does not assure the best configuration for a different app in a different container on the same host.

Because TCP-based optimizations like TCP multiplexing operate at the protocol layer, they’re like honey badgers. They don’t care if the app is in a container or a virtual machine or naked on a web platform. They will tune the heck out of that connection and improve performance regardless of how or where the app is deployed. Such services care only about the protocol, and take advantage of the separation of client-side from server-side  to further ensure that the client-side is optimized for the client, and the server-side for the app. That means performance improvements times two.

Traditional app acceleration services and techniques are awesome, don’t get me wrong, and as you can see from the particolored chart above, organizations take advantage of all of them to improve the performance of their applications. But there’s more that can be done and, as the aforementioned data on performance indicates, more than should be done.

It’s a good idea to look at your proxy (the one you probably just use for load balancing) and find out whether it can do more for the performance of your app than you’re currently employing.

Find out how F5 makes apps GO faster, smarter, and safer.