IT Experiences Episode II

Network and Application Latency

While consulting, I was asked to look into why a network was slow. The company was confident the network needed to be overhauled. The application developer blamed everything on the network but recently did some application upgrades. At that point, I could have gone down that path based on their perception, however I wasn't convinced as based on what I saw, yes the network needed some improvement but it wasn't the root cause.

After doing some network analysis, I did notice some improvements were needed, but still didn't explain why the application was slow. So I asked the client if they would mind I look some more time analyzing root cause.

I spent a couple of days reading some of the code and used a packet sniffer. I noticed that there where references to folders that no longer existed. I recommended the application developers remove the reference to the folders. Of course we had some discussion and their references that I didn't know what I was talking about. All I can say about that is, the old phrase 'Rumor Me' sometimes goes a long way. Long and short they modified the code and surprisingly for them, problem was resolved.

What is the lesson? Most times the network is blamed for latency and at times it's not the actually root cause. I'm not saying that keeping a network up to date using best practices isn't my recommendation, but I am saying take a deep look into root cause before blaming the network. I'm a strong advocate of monitoring as it provides essential visibility into what's happening behind the scenes on compute. It's also essential application developers and network engineers work closely as much as possible when diagnosing a problem.