Quantcast



Docs


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Application Acceleration: Bigger is Not Always Better
posted on Thursday, September 27, 2007 1:30 PM

More bandwidth can't always solve your application performance problems

We have, over the years, come to the realization that application performance issues cannot always be solved simply by increasing the amount of bandwidth available. The concept was inherently flawed from the beginning anyway. You can increase the number of lanes on the highway but that doesn't mean that you'll get to your destination faster, it just means more people can get where they're going in about the same amount of time.

This is because there is an upper bound on the speed of a car, just as there is an upper bound on the speed at which an application can serve up data, and both boundaries depend highly on what's "under the hood". The performance of an application has more to do with the code, its underlying architecture, the size and type of data being exchanged, the distance traveled, and the workload of the server on which it is deployed than the size of the pipes in your data center and beyond.

That's why application acceleration solutions encompass a wide variety of technologies and techniques - because a good acceleration solution requires a number of technologies working in concert to address as many of the underlying factors that contribute to performance issues as possible.

Application Acceleration Technologies

  • Data Reduction
    Usually part of the core feature set of a WOC (WAN Optimization Controller), data reduction technologies use sophisticated algorithms to recognize repeating patterns of data and reduces the pattern to a few bytes, saving bandwidth. The downside of this technology is that it always require 2 devices, one at each end of the pipe.
  • Protocol Optimizations
    There are very few application acceleration solutions that do not support basic TCP protocol optimizations as defined by a number of RFCs. These optimizations improve how TCP works and, in doing so, improves the overall performance of any application that uses TCP as its transport layer.
  • Caching and Compression
    Caching and compression have long been the foundation of application acceleration. Compression reduces the size of data such that it requires fewer packets to deliver and therefore takes less time to arrive at its destination. Caching moves the data closer to the requestor and can often take advantage of the client's native caching mechanism to improve performance through the decrease in distance.
  • Server Offload
    Server offload capabilities are rarely thought of in the context of application acceleration, and yet the offloading of certain tasks, such as SSL management, certainly improves performance. This is usually because the device offloading the task from the server has hardware capabilities that improve the performance, such as in the case of SSL. But it can also be applied to network-focused tasks such as connection management. By providing the means through which intermediaries can manage connections between clients and servers the additional burden of opening and closing connections can result in more resources on the server which can be dedicated to processing requests, thus improving overall performance.
  • Application Specific Optimizations
    Application specific optimizations are least frequently seen in application acceleration products primarily because (1) there are so many applications to choose from and (2) these optimizations rarely do anything to help with the performance problems of custom built applications. Still, for third-party packaged applications like SharePoint, Exchange, SAP, Siebel, and Oracle, specific optimizations that improve the application by applying policies developed specifically for those applications can certainly improve performance, especially when combined with the use of other application acceleration techniques.

You will note that very few of these technologies deal with changing the size of data, or mention the need to increase the available bandwidth. Bigger isn't always better, and in the case of application acceleration it is rarely the case that more bandwidth can solve an application's performance problems.

Imbibing: Water




Email This
  del.icio.us
      

Feedback


9/27/2007 2:35 PM
Gravatar Great article! Yeah, bandwidth rarely solves application issues. It's the nature of the beast. Stick with Riverbed for application acceleration. They are the best of breed solution. I work for a Cisco partner and we are also partnered with Riverbed, because they have the best WAN optimization technology. I have a lot of comparison data on all the competitors if anyone is interested.

Justin Lofton
Systems Engineer
Tredent Data Systems, Inc.
WAN Optimization Specialists
justinl@tredent.com
http://www.tredent.com
Justin Lofton

10/2/2007 3:36 AM
Gravatar The area surround application acceleration is very interesting. It's very difficult to ascertain exactly what these appliances do over and on top of vanilla WAN acceleration to optimise applications. Do they use different layers...? Do they cache differently - perhaps on a file or object level rather than bit level...? Or are they just a configuration tweak to the vanilla WAN profile to work better with a specific app...? More specifically, when implemented just how much more performance is gained using specific application acceleration over vanilla WAN acceleration...? Is WAN acceleration + Application acceleration 5% better, 50% better, 150% better or 500% better that just WAN acceleration alone...? Sure it depends on the app, but let's take a range. I am not going to replace several hundred Juniper WX and WXC boxes (vanilla WAN acceleration) for a 5% increase in performance...! Nice little blog post though. Food for thought...
Rupert C Kent

10/5/2007 7:57 PM
Gravatar Hey Rupert,

You ask a great question. I think if you already have Juniper WX in place it would be a hard sell to management to justify installing another application acceleration solution unless you have had it long enough that their is budget to do so. In my experience, the reason Riverbed really stands out in the crowd is because they take each application that needs to be accelerated and write a specific algorithm to address all of the shortcomings of that application. Also, my understanding is that their NIC cards are proprietary. Bottom line is that unless there is pain with your current Juniper solution and budget for another solution it won't make sense to forklift upgrade to Riverbed or another solution.

Justin Lofton
Systems Engineer
Tredent Data Systems, Inc.
WAN Optimization Specialists
justinl@tredent.com
http://www.tredent.com
Justin Lofton

3/31/2008 5:04 PM
Gravatar Sorry Justin but riverbed sucks. They have no method of compressing non-repeating data real-time. Riverbed is only good at repeating data. big deal, who isnt good at repeating data?

steve cabello
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 4 and 1 and type the answer here: