Chapter 10. When Applications Fail

This chapter includes the following topics:

• QoS troubleshooting tools

• Diagnostic tools

• Troubleshooting methodology

• Identifying responsibility

• Resolving performance problems

• Redefining delivery requirements

• Redefining service level criteria

In the majority of enterprises today, it is rare to see a complete application failure. What normally occurs is that an application fails to perform to end-user expectations, with a resulting loss in productivity and frustration for the user.

Performance problems are seldom caused just by overloaded WAN or LAN links. Application transactions depend on many outside influences, and any one discrepancy in the process can cause the whole system to crumble. You need to profile the application (from a network point of view) to understand the client/server traffic necessary to complete the transaction.

This understanding of the process helps to close the gap between application developers and support staff. When they see the interaction between their applications and the infrastructure components and protocols, they then can work together to expedite resolution, eliminate the majority of finger pointing associated with cross-group issues, and (probably most importantly) provide baseline information. Armed with this information, developers can then scale their applications for deployment and provide network architects with realistic figures to design and upgrade their underlying infrastructure.

To manage faults, you need to discover, isolate, and correct problems. This chapter discusses how the user can employ Cisco best practices to facilitate fault discovery using the system monitoring commands to isolate problems with the system test commands and to resolve problems with other commands, including debug commands.

This chapter then introduces a simple troubleshooting methodology through which you use this information.

It covers the importance of identifying and assigning responsibility for problem resolution, discussing the general default approach of determining which area is responsible for resolving the performance degradation, and allocating responsibility instead of using predetermined metrics (as previously defined in Chapter 3, "Detailing the Business Transaction," and Chapter 8, "Monitoring the Delivery").

The chapter then moves on to discuss the capture of the application transaction as it traverses the infrastructure, defining application and architecture along the way, and discusses relevant capture points and approaches.

Finishing off, the chapter explains why the observed performance figures will ultimately not be improved. It discusses the review process required to redefine the delivery requirements and subsequently adjust expectations and measures.