Network Performance Part I

Application performance issues arise for multiple reasons. Poorly written codes, server degradation or performance of the network are some of the common causes to application issues. Invariably it’s also true that when there is performance issues everyone looks to the network group for answers. The network team is considered guilty until they have proved that, the network is performing up to standards.  

As network engineers become increasingly accountable for the performance of applications that run over their networks, they need a better, more proactive approach to troubleshooting.  Over the years I have come across various issues contributing to Network Performance. Two of those that stand out are latency and packet loss.

Latency

Latency in a network is measured either one-way (the time from the source sending a packet to the destination receiving it), or round-trip (the one-way latency from source to destination plus the one-way latency from the destination back to the source). Round-trip latency is more often quoted, because it can be measured from a single point. Many software platforms provide a service called ping that can be used to measure round-trip latency. Ping performs no packet processing; it merely sends a response back when it receives a packet (i.e. performs a no-op), thus it used to be a relatively accurate way of measuring latency. It’s important to note that Note that round trip latency excludes the amount of time that a destination system spends processing the packet.

 

Packet Loss

Packet loss occurs when one or more packets of data traveling across a network fail to reach their destination. The factors for packet loss could include signal degradation over the network medium, oversaturated network links, corrupted packets rejected in-transit, faulty networking hardware, maligned system drivers or network applications, or normal routing routines.

 

When caused by network problems, lost or dropped packets can result in highly noticeable performance issues. Now having said that it is also true that packet loss may not always cause performance issue, the degree to which the performance degradation can be felt also depends on the application. Applications that use TCP could benefit from error checking built into the TCP protocol itself. TCP may be able to balance small amount of packet loss without users actually noticing any performance issues. 

Now there are tons of tools out there that can help you monitor your network for various issues. It is important that you understand what each tool does the best before you go a buy a bunch of tools. Before you deploy the tools understand what protocols and algorithm they follow to identify issues. This will help you understand the findings more clearly. It’s not just tools that you need but you also need to understand how to co-relate their findings to come to an accurate conclusion.

 

In my upcoming blog I will include basic troubleshooting steps to identify the problem areas.

 

Next Step   Ready for the next step? Contact us here - http://www.tblocks.com/BLOG/contact.aspx

About the author:

Nitish is a multi-certified IT professional with over 10 years of proven experience in Networking and Security The former Director and Founder of a leading networking and security firm, Nitish's expertise and in-depth knowledge of Network technology, Unified Communications and VOIPstand unparalleled. 

 


Comments are closed

About Me

Please follow the TechBlocks web site to find out more about us.

Recent posts

Recent comments

Search

Disclaimer

The opinions expressed herein are personal opinions of the TechBlocks employees and do not represent TechBlocks view in anyway.

© Copyright 2010