Use Resource Monitor to monitor network performance

In my TechRepublic series on Microsoft’s Resource Monitor tool, I have covered the ways by which you can receive real-time performance metrics related to storage performance and CPU utilization. In this installment of my four-part series, I’ll discuss the various network-related metrics that you can view with Resource Monitor, explain the graphs you see in the tool, and provide some context around each metric.

For the purposes of this post, we’ll use the screenshot in Figure A. This figure shows a Resource Monitor view from a production server running Windows Server 2008 R2 and Exchange Server 2010 with all Exchange roles installed. As such, this server has significant need for network resources that operate within acceptable boundaries. (Note: Like all of our other servers, this server is running as a virtual machine under VMware vSphere 4.1.)
Figure A

A look at Resource Monitor in Windows Server 2008 R2 (Click the image to enlarge.)

Let’s start with an overall look at the console. Occupying most of the window is the statistics area, which I’ll be explaining in depth. At the right side of the window are a number of graphs, each depicting a key network-based performance metric.

In the sections below, I provide details for each metric. I don’t repeat metrics; if one type of metric appears in multiple areas, I only list it once.

Processes With Network Activity

This section of the Resource Monitor window shows a list of all of the running processes that are using disk resources. You see the name of the executable and a number of performance statistics.

• Image. Process executable file name. This is the name of the process that is actively using the disk.
• PID. The ID number associated with the process. This is useful if you want to use other utilities to manage processes, or you want to easily match up processes with Task Manager.
• Send (B/sec). Average number of bytes per second that the process has sent over the network in the past minute.
• Receive (B/sec). Average number of bytes per second that the process has received from the network in the past minute.
• Total (B/sec). Average total network activity (in bytes) that the process has generated in the past minute.

The information in this section isn’t particularly useful for troubleshooting except to show you which processes are consuming the most network resources. In Figure A, you can see that the processes named FSEContentScanner64.exe are receiving quite a bit of information from the network.

Network Activity

This section of the Resource Monitor window provides more useful troubleshooting information. In particular, the two boxes next to the heading offer the most impactful, immediately useful metrics.

• Network I/O. This box shows the current total network utilization in Mbps (megabits per second). This is a useful data point, but the metric next to it is the one that provides you with really good information.
• Network Utilization. This metric wraps up all total utilization into a single, easily accessible metric that can help you determine exactly how loaded your network really is. If this number is approaching 100% and stays there on a regular basis, you likely have network congestion issues and should add more network capacity.

Below this header information, you will find the following new metric:

• Address. This is the name or IP address with which the process is communicating.

The remaining metrics in this section repeat the information from the previous section.

TCP Connections

• Local Address. Many servers have multiple network adapters, and each network adapter can have multiple IP addresses assigned to it. In order to better determine which network adapter and IP address may have congestion issues, this sections adds more granular IP address information to the list of metrics.
• Local Port. Likewise, you may have services that run services using a multitude of TCP ports. If you’d like to determine on which ports communication is happening, you can see that here.
• Remote Address. Every local connection requires some kind of communication with a remote system. In this column, you will see the remote address that makes up the other half of the communication stream.
• Remote Port. Here you will find the remote port that makes up the other end of the communication.
• Packet Loss (%). This is a key metric. The more packet loss that you’re experiencing, the worse the quality of the connection, and the more inefficiency that is introduced as a result of retransmissions.
• Latency (ms). This is another key metric. Latency is a measure of the time it takes for data to make it from point A to point B. The higher the number, the longer it takes. High latency values can be detrimental to network-sensitive applications, such as real-time video. High latency values can also introduce noticeable delays to users, which can affect support desk call volume.

Listening Ports

• Address. Some services are intentionally tied to specific local IP addresses for either IPv4 or IPv6. If that service is not tied to a specific address, this column will simply read <IP version> unspecified.
• Protocol. TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). TCP is a guaranteed delivery mechanism, whereas UDP doesn’t verify delivery.
• Firewall Status. If your firewall is blocking traffic, you’ll know that by looking at the information in this column.

The graphs

The graphs are very useful tools. The Network graph shows the network bandwidth in use for the past 60 seconds for all connections. The TCP Connections graph shows how many new TCP connections have been created. An unexpectedly high rate of TCP connection creation can signal an out of control process, spyware, or some other problem. The Local Area Connection graph shows overall network utilization as a percentage. In Figure A, there is only a small amount of utilization at present in this server.

Summary

Today’s super fast networks have helped to quash many network related problems, but these issues certainly still exist. You can use the information in this post to delve a little deeper into Resource Monitor’s performance stats and track down problems.