No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

10 Tips for Diagnosing Slow Applications

To diagnose a slow application, you’ve got to start with knowing something about how the application functions.

What protocols does it use (UDP or TCP)? What are the packet flows like (small, equally spaced packet flows like in VoIP or big encrypted data packets)? Does the application need real-time performance (again, like VoIP and video) or does it need to move a lot of data? Is QoS required? Do other applications run on the endpoints, competing for bandwidth, CPU, memory, and disk I/O? Where are the endpoints and what is the path between them? What is the application’s server architecture?

We should start by dividing the problems into groups:

  • Client-side processing -- things that happen on the client endpoint
  • Network transport -- factors that impact applications on the network
  • Server-side architecture -- application architecture and implementation factors
  • Multifunction interactions -- interactions between multiple groups that degrade applications

In this part, we’ll examine the first two groups. The second part will cover the final two groups.

Client-Side Processing

For reliable application performance, you have to be able to control what is happening on the client endpoints. The resources and timing of activities on clients can impact business application performance.

1. Some applications distribute their processing loads by running complex programs on the client. The complexity can be due to the algorithms, the size of the code, or the size of the data that must be processed. You must understand the client-side function of the application architecture in order to truly diagnose and understand the source of the problem. Use client-side diagnosis tools to learn the size of the application and whether it is consuming excessive amounts of memory or using a lot of CPU. Network utilization tools may help determine how much data is being loaded from the server.

2. Related to #1 is the use of old, underpowered client systems. The problem may be slow CPU, limited memory, network-based storage for virtual desktop systems, or perhaps a slow local disk storage system. Note that a nearly full disk system will function much like a very slow disk as the system searches for empty storage blocks. I’ve seen old virtual desktop infrastructure (VDI) clients that weren’t fast enough to run the video codec without dropping packets. The video would randomly display significant pixilation, which annoyed users and caused no end of complaints. One of the key data points was that switching to a more powerful VDI client hardware significantly reduced the pixilation. Another factor was the amount of motion in the video. Relatively static video content was fine, while high-motion video exhibited the problem. Another clue was that the pixilation only started after a few 10s of seconds of video -- after the client’s buffers filled.

3. Next on our list is other programs that compete for resources. A typical culprit is when a system starts to download a software patch/update or begins performing a system backup or running a virus scan. These processes are known for consuming client-side resources like network bandwidth, CPU, memory, and disk I/O bandwidth. Don’t forget about entertainment programs like streaming audio and video. Listening to music all day isn’t too bad. But watching the March Madness games or other significant streaming video entertainment program can have a big impact on a client system’s ability to run business applications.

  • 1