- BlackBerry Storm vs. the iPhone
- Digg's Kevin Rose: "We have to do better"
- Blogger warns: "Nortel doesn't make it out alive"
- Financial quagmire bringing out the scammers
- Verizon plays with the wrong e-mail addresses
Newsletters | Podcasts | Chats | Opinions | RSS Feeds | This Week In Print | IT Careers | Community | Reports | Downloads | Slideshows | New Data Center
Partner Sites:Application Performance Solutions | App Performance | Networking Solution | SafeGuard Enterprise Solution Center | SOA | Test your Web Filter | Value of WDS
WAN experts Steve Taylor and Jim Metzler analyze and share best practices on WAN issues from optimization to management.
As noted in the last newsletter, the Mean Time to Repair (MTTR) of application performance issues can be quite lengthy. One of the factors is that the issues are often improperly diagnosed. In particular, in many IT organizations, if an application is performing badly the general assumption is that the WAN is the cause. However, our research indicates that in only a minority of cases is the WAN at fault.
We discussed this issue with a network engineer for a financial services organization. He stated that in his last company, 90% of issues were originally identified as being network problems even though the reality was that only 10% of issues were network related. He pointed out that such false assumptions increase the amount of time it takes to accurately diagnose the problem. He recommended that when a problem is called into the help desk the caller should be encouraged to describe the symptoms of the problem in detail, and not just what they think the source of the problem is.
In a previous newsletter we discussed some of the reasons why traditional fault management was easier than application management and used the example of a defective interface on a router. Sticking with that example, another one of the reasons why fault management is easier than application management is because once it is determined that a given interface on a router is defective, the remedy is obvious – replace the interface.
Once the source of the application degradation has been identified, the solution is not necessarily quite so obvious. For example, consider the situation in which the IT organization has determined that the source of the application performance issue is the application itself. In particular, the application was written in such a way that it performs badly over the WAN. If the application was developed internally, then perhaps some future revision of the software will run better over the WAN. While the same could be said for software that is acquired externally, it is highly likely that the IT organization that is trying to make the application run better has little influence over an outside supplier. In that case the IT organization is stuck with trying to implement a workaround and hoping that it will eliminate most if not all of the application degradation.
We will come back to the topic of the MTTR application performance in future newsletters.
Steve Taylor is president of Distributed Networking Associates and publisher/editor-in-chief of Webtorials. Jim Metzler is vice president of Ashton, Metzler & Associates.
Partner Content
Simplify Your Branch Infrastructure
Learn how to simplify your branch infrastructure while dramatically increasing app performance with Citrix Branch Repeater.
Download the Free Info Kit
Next-Gen Load Balancing
Free Guide: "Next Gen Load Balancing: 8 Things You Need to Handle Today's Network Traffic" shows you the functionality needed in your next load balancer.
Download the Free Guide
Accelerate Your Web Apps by up to 5x
Free Guide: "The Secret to Getting Maximum Speed from your Web Applications." Learn how you can deliver Web apps up to 5x faster.
Download the Free Guide
Comments (4)
Biggest lie in the enterprise: `The network is down'By Julie Bort on July 12, 2007, 1:09 pmThe network is rarely down. So why do network folks constantly take the rap? One reader wrote a thoughtful essay on this -- and what network folks need to do to...
Reply | Read entire comment
Why are we reinventing the wheel?By Fitz on July 5, 2007, 10:19 amAs a retired Network Geek I don't know how many times I've seen this very same problem over the twenty odd years I've trouble shoot networks. In the Mainframe era...
Reply | Read entire comment
Great topic. One of theBy Ben Haley on June 26, 2007, 10:05 amGreat topic. One of the issues I see is a desire for monitoring to show the end user experience is or the business transaction. That approach is great at identifying...
Reply | Read entire comment
Don't blame the network for application problemsBy Anonymous on June 26, 2007, 9:15 amSteve, Every time I come across an article of interest, it is co-written by you. Re: Don't assume application performance problems are always network-related. Your...
Reply | Read entire comment
View all comments