How to troubleshoot sluggish apps

There's more at stake than lost productivity when application response times slow to a standstill. Company revenue also takes a hit.

Aberdeen Group recently surveyed 200 organizations and found that issues with application performance affect overall corporate revenue by as much as 9 per cent.

"No one is safe today from the negative impact of poor application performance, whether you're a gamer, a retail outlet or a Salesforce.com user," says Jasmine Noel, principal analyst at Ptak, Noel & Associates. "The question is how much money do you have to lose if the application starts crawling along at traffic-jam speeds?"

On the one hand, multi-tiered applications help companies do better business, but on the other, the complexity of the environment in which they reside challenges network managers looking to prevent problems before they reach users and customers. Adding to the problem is the growing adoption of such technologies as virtualization, VoIP and service-oriented architecture -- which require sophisticated environments that could hinder troubleshooting efforts when problems arise.

"In the past, we were managing the infrastructure, which really doesn't get into how the application is performing for the end users," says Jason Norton, director of operations and telecommunications at media and marketing company Scripps Networks. "We need to be able to be aware of and see all of the pieces that make up an application and how they affect the end user to understand when performance is going to be impacted, he says."

Here we analyze three scenarios in which application-performance problems could elude network managers.

Can you hear me now?

Symptom: VoIP calls begin to experience poor quality and latency, some even dropping altogether.

When Koie Smith, IT administrator at law firm Rainey, Kizer, Reviere & Bell, noticed VoIP calls performing inconsistently across the network, he first tried to trace the problem to a specific port.

"We have had instances in which a performance problem would occur because something had been put on the network, such as a network-interface card or a port, that causes a problem with an application, such as voice," Smith explains.

But the performance issues with the application couldn't be traced back to a specific port. Smith began looking further into the QoS settings he had established when he rolled out voice traffic and discovered why the voice users were suffering: Undefined priority tags on voice packets across multiple switches meant that only some of the traffic was given priority, which resulted in spotty performance.

The solution? Updating the QoS tags and specifically defining the priority tags for voice traffic across all network switches.

"From the network side of it, it is critical to define tagging and assign priorities on the switch for such specific traffic as voice or video," Smith says. "A lot of switches will identify and acknowledge that QoS tag, but if you don't also have a priority tag on each switch - even if you have it tagged at the source - the switch just dumps that traffic in with all general traffic, and it doesn't get the allocated bandwidth it needs to perform well."

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark