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:
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.
