Saturday, September 24, 2016

How Do You Improve WAN Application Performance?

Let's say you are a CIO of a company with established WAN infrastructure and are getting complaints from the users .....that the applications are sluggish. Will you contact the network vendor (e.g. Cisco, Juniper), invest in WAN accelerators (e.g. Packeteer, Riverbed), or hire a consulting firm to investigate? What will you do to resolve the situation?

To start....take a step back and take a deep breath. You're jumping the gun suggesting the WAN is responsible. More information is needed.

The moral of the story....get data first.

Find out what is the performance of specific actions when the client is running in the same building as the application server.

Repeat that for a client in various other locations and compare the results.

This may point to specific WAN links to check. In other words what are the bandwidths and response times across different segments. [Are some locations longer than others, does distance seem to play a part, is there one specific congestion point.]

It may also point out the need to analyze the client traffic flow. Does the application require 100+ round trips between the client and server (over the WAN) for even the simplest of actions? Something like this can only be solved by changing the application. (Don't care who the providers are. You can't do much about the speed of light around the globe that many times.)

So part of the answer is......asking any specific vendor to "fix" it before you know what "it" is will waste your time.

The short answer is.....get data, analyze it, then fix.

Performance problems can be attributable to the network, the servers, the database(s) and applications themselves, so its important to step back and look at the complete infrastructure including the applications and all their components before assuming the WAN is the culprit.

Ask yourself......

- What is the current “end-user experience” for business applications in terms of performance and availability?

- What is the current response time contribution of client, network and server tiers?

- What are the current resource utilization levels on the critical servers that support the business?

- What is the current utilization of network resources (i.e., WAN links) and which applications are using the most bandwidth?

- Which servers, workstations and business locations represent the “top talkers” on the network?

If you believe that you already have these questions answered.....and your primary suspect is still WAN performance.....you need to ask whether you have sufficient bandwidth for the application traffic traversing the WAN and/or whether the problem applications are suitable for WAN deployment in the first place. (A chatty 2-tier database app is not going to scale well across the WAN no matter how much h/w you throw at it).

A network monitoring tool that can help deliver a comprehensive network asessment over a period of time, be it peak volume traffic a 24hr work day or busy business period, can help you understand the worst offenders. Once you know who they are you can do two things .....

- look at the network readiness for the application(s)

- look at the applications themselves to determine whether they are optimized for your environment.

If the issue is just bandwidth, the question becomes how much more do I need? A network profiling tool with predictive capabilities can help you assess the impact of network changes on application performance and whether more bandwidth or reduced latency will solve the problem.

If latency is an issue you may seriously have to look at the problematic applications in question to see whether they are suitable for WAN deployment. The same profiling capability from above can help you determine the effects of less round-trips between client and server(s) allowing you to determine the cost/benefits between changing the application or the infrastructure.

Dont just thow accelerators at it however without first knowing what the problem is. They may be a waste of money for certain applications and not solve the problem.

This is a typical issue for most organizations at some point in time and I would follow the steps below to resolve it.

First, define and quantify the problem. Poor WAN application performance can be the results of many things; lack of bandwidth, failing network gear, telecom vendor issues, poor application design, unanticipated network demand. The symptoms of the problems need to be documented. Does it happen at a particular time of the day or is it constant? Does it occur when a certain application is running? Which users are effect? What nodes on the WAN are effected? Is it a localized issue or does it seem to effect several locations? Have there been a changes made to the WAN recently (new hardware, new applications, new telecom vendors, etc).

To be able to define the issue you have to start collecting good information to help in the process. Places to start collecting information would include:

- Help desk. Great source for defining symptoms of the issue.

- Network Gear. Routers, Switches, CSU/DSU logs can be reviewed for problem identification.

- Telecom vendors. Especially for shared networks (frame relay, atm, etc) they will be able to provide statistics on burst rates and usage.

- User Interviews. Some users don’t log all their problems

Through these sources you should be able to characterize the problem. And the nature of the problem will dictate the solution. Some problems and solutions would include....

- Poorly Designed WAN Application. Possible solutions are; re-work the application, move servers in network topology, increase WAN bandwidth or use terminal server software (i.e. Citrix). The band aid and no brainer approach is to use Citrix and take the WAN out of the equation.

- Poor Telecom Vendor support. Possible solutions are changing out Telecom vendors or have them re-engineer the links. For example, move from Frame Relay to Point-to-Point topology. But be careful. Most of the time the last mile is usually the same physical medium which may be the problem. Meaning changing topology would not help.

- Limited Bandwidth. The possible solution is increasing bandwidth. Sometimes natural organizational growth and uses of the WAN account for the poor WAN performance and you have to buy more bandwidth. Or, once again, you can limit this growth by falling back to using Citrix or maybe relocating servers.

- Failing network gear. The possible solution would primarily be either replacing components or the whole piece of equipment. This is the one situation you might want to consult with an outside expert depending on the level of skill you have internally.

- Odd situations. There are always the unusual situations. For example; I have seen WANs slow down when people start to email around MPEGs. This is more of a policy issue.

The bottom line is sometimes you may have to bring a consultant in. But in many situations, by using common sense, you can determine the cause and solution to the problem internally.

Should analysis show that increased bandwidth is warranted....you can obtain no cost assistance in finding the right bandwidth solution for your specific application at

DS3 Bandwidth

Their no cost support covers T1, DS3, OC3, OC12, OC48, OC192, MPLS, Fast Ethernet, and Gigabit Ethernet in all possible configurations....fractional, full, bonded, integrated, point-to-point, private, etc.

==============================

Labels: , , , , , ,

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home