Part 1 of a three-part series
Organizations looking to amp up application performance have lots of options today, including WAN optimizers, application delivery controllers, FTP accelerators, wide-area file services, managed optimization services, and overlay network services.
Any of these options may help if you are experiencing persistent problems in delivering good application performance to your remote end users. Some can help ensure the performance of Software as a Service (SaaS) solutions--or even an organization's own applications hosted on external cloud resources--to users anywhere on your network. But, to really solve performance problems you need to pick the right flavor of WAN optimization
The first step on the road to performance improvement is to determine your needs. What are the persistent problems and who is experiencing them? This requires going beyond squeaky-wheel problem reporting to careful testing. When a user says soft-phone audio quality is bad, is it because of the WAN? Or does it relate more to task prioritization in the desktop operating systems? Or does the problem actually lie in the TCP stack?
Performance is an end-to-end phenomenon, and optimizing the middle won't fix the endpoints. Look to see whether other users in the same location are experiencing the same performance problems as those who report them. Also, look to see whether users in other, similar locations are experiencing similar problems with the same applications.
Be sure to document test results and network performance numbers in all the locations, and compare results to the same tests conducted at other locations not experiencing the problems. Are the afflicted sites experiencing higher packet losses or more variability in network performance (jitter), or are they simply short of bandwidth?
WAN prioritization: QoS, CoS and effect
The second step is to look at options for remediation. Endpoint issues aside, fixing network traffic may not require adding new optimization gear or services. In some cases, bandwidth is available, but high-requirements traffic (like voice, video, and even that associated with remote desktops) is tossed around in the rapid flux of other applications' traffic.
The first, fast, and relatively cheap thing to try here (assuming the current network equipment allows) is setting up class-of-service (CoS) and quality of service (QoS) features to prioritize real-time traffic over other classes and to push the most forgiving things, like email, into a below-normal priority class.
If that is impossible or insufficient, three options remain:
1. Reduce demand on the WAN through application re-engineering.
2. Reduce demand on the WAN by moving applications closer to users.
3. Optimize the WAN.
The first choice is great for folks who rely mostly on applications they develop themselves. The second option runs counter to the movement that is still sweeping through most organizations -- to centralize IT in an effort to wring the greatest efficiencies out of IT resources and staff.
So WAN optimization is the best solution for most. In our latest research, Nemertes found nearly 73% of organizations currently deploying some WAN optimization. To select the right kind of optimization, it helps to have the two taxonomies of optimization in mind: optimization patterns and optimization techniques.
Picking a pattern for network performance
The patterns for deploying optimization are: symmetric, asymmetric, carrier/cloud/managed, and overlay.
The techniques available are content-reducing, aimed at cutting the amount of stuff that has to move across the wire, or behavioral, aimed at improving the behavior of traffic crossing the network. Content-reducing optimizations include caching and compression. Behavioral-optimizations include:
IT can select which techniques (compression, acceleration, etc.) are most appropriate to remediate, based on the applications having the most problems. They can then move through a vendor selection process that emphasizes fixing the core problem.
A network sometimes has more than one problem in delivering applications, of course, so it is important that your chosen platform resolve as many as possible and not interfere with whatever you have to layer on to resolve what remains.
Next in the series: How to proceed with optimization and pilot deployments once you have developed a set of requirements and settled on a preferred architecture.