Do you suspect that something is eating up your bandwidth? Or do you simply want to know if a particular application or location generates a lot of traffic? Would you like to know when traffic occurs? PerformanceGuard provides the answers:
Which Applications Generate Most IP Traffic?
In PerformanceGuard an application consists of a server/port combination, for example server.organization.org on TCP port 80 (HTTP).
The IP Traffic by Application time view graph (ANALYZE > Graphs > Time View > IP Traffic by application) shows which applications generated IP traffic, and when they did it. You can view this data for combinations of all servers and ports, groups of servers and ports, and individual servers and ports.
The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days.
If you simply want to find out if a particular program (such as Skype) generates a lot of traffic, it is often easier to look for the process (such as skype.exe) instead. See Which Processes Generate Most IP Traffic? in the following.
Which Processes Generate Most IP Traffic?
- The quick overview: The Load Overview (ANALYZE > Overview > IP Traffic > Load Overview) is a pie chart that very quickly lets you find the processes that are responsible for the largest amounts of IP traffic. When you generate the pie chart, try to select Type = Processes and Data type = Load (Sent + Received Bytes).
- The details: The Process Traffic hotspot (ANALYZE > Overview > HotSpots > Process Traffic) provides detailed data about traffic-generating processes, and you can drill down to view details about which servers the process communicated with as well as details about which computers and user accounts ran a given process.
- The timing aspect: The IP Traffic by Process graph (ANALYZE > Graphs > Time View > IP Traffic by process) is ideal when you want to check if certain processes generate traffic at specific times. You can view this for all servers, for groups of servers, or for individual servers.
Which Locations Generate Most IP Traffic?
The IP Traffic by Location time view graph (ANALYZE > Graphs > Time View > IP Traffic by location) shows which locations that generated IP traffic, and when they did it. You can view this for individual servers and ports that the locations have communicated with.
The graph is also available in a trend view variant. It contains the same type of information, but the trend variant is more suitable if you want to view data from more than the last few days.
If you want to compare locations, select all the locations you require in the graph's Agents list. Don't simply select All agents because that won't let you view the traffic generated by individual locations.
IP Traffic by Application/Location/Process (Time View)
This time view graph offers an overview of response times, sent bytes, received packets, etc. The graph comes in three different variants:
- IP traffic by application
- IP traffic by location
- IP traffic by process
To use the graph, select ANALYZE > Graphs > Time View and then either IP Traffic by application, IP Traffic by location or IP Traffic by process.
This graph is useful because ... it lets you compare performance across servers. Use this type of graph for anything that's not accessed through a web browser (for stuff that's accessed through a web browser you would typically use the Transactions time view graph).
Generate and View Graph
Depending on which of the three variants of the graph you have selected, you may not see all of the following parameters when you set up the graph.
- Servers: Select the server or server group that you want to base the graph on. Server groups are enclosed in <>. Only server groups and monitored servers are listed, see Server Lists for details about monitored servers.
On the IP Traffic by application graph you can select multiple servers and server groups by pressing the CTRL key while selecting servers.
- Agents: Select the group of computers that you want to base the graph on. Super groups, that is groups of groups, are enclosed in <>.
On the IP Traffic by location graph you can select multiple groups by pressing the CTRL key while selecting groups.
- Processes: Select which processes you want to base the graph on. You can select multiple processes by pressing the CTRL key while selecting processes.
IP data process information is not collected on computers that run Windows XP.
Why is there sometimes a process called "No process name found" or "UNKNOWN"? Occasionally, a process may start and then end within a very, very short time frame. When that's the case, PerformanceGuard registers the process, but it simply doesn't have time to collect the name of the process. That's the reason why a process may sometimes appear in the list without a name.
- Ports: Select which port or port group you want to base the graph on. Port groups are enclosed in <>. Only port groups and monitored ports are listed, see Port Lists for details about monitored ports.
- Type: Determines which type of data the graph will contain. The options are described in Graph Terms & Definitions.
- Hide thresholds ...: Only relevant for certain types of data: Response time (ms) and Retransmissions (%).
For such data, a threshold—that is a baseline that the displayed values must ideally be below—can be displayed as a horizontal line in the graph when:
-
- Your PerformanceGuard administrator has defined such thresholds
- You have selected one server group and one agent group (if you have selected multiple groups, threshold display is not available, because thresholds can be different across groups)
You may sometimes see more than one threshold on a graph. This is because your PerformanceGuard administrator is able to set up multiple thresholds for the same type of data. This can be useful in order to indicate different severities, for example if values above 80 are acceptable for short periods of time, whereas values above 90 require immediate attention.
On the graph each threshold has a name, so it is easy for you to see what the threshold is about.
Display of thresholds is by default on. When you generate or view a graph, you can toggle threshold display off by selecting Hide thresholds. This can be useful, for example if you think that a threshold blocks your view of the graph's data points.
If a graph has thresholds, the thresholds will also appear if you use the graph in a report, except when they're hidden.
Displayed thresholds are always the currently valid ones.
- Y-axis Min and Max: Specify the range that you require for the graph's vertical axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
- Interval: Select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
- Disconnect samples: The samples in the graph will by default be Automatic. If you don't want this you can select Connect All
or set them to Disconnect All
Connected samples
Disconnected samples
- Moving Average: Adds moving average information to the graph. The moving average is by default calculated based on the last ten points.
Without moving average information
With moving average information
You can change the number of points to use for calculation of the moving average: Select ADMINISTRATION > Setup > Parameters, then select the Display tab, scroll down to the Graphs section and edit the Moving Average setting.
When you view the graph, you'll also see a Statistics table below the graph. Note that the Statistics table shows the weighted average for the graph's samples. That means that each value to be averaged is assigned a weight based on the number of occurrences of that value.
What's a Connection Reset, and How Can It Be Higher than 100%?
A connection reset is typically the sign of a busy server that puts clients "on hold" until it's ready to serve them. It does this by forcing clients to connect again. This buys the server time, so that it is able to get rid of its current queue of tasks before taking on new tasks. From the server's perspective the advantage of this is that it can keep the queue of clients waiting on the network rather than on the server itself.
The amount of time that a connection reset takes is very small, so it typically takes several connection resets before users begin to feel that the server is hard to reach. Once the server has accepted the connection, it will normally respond quickly. That's why connection resets mainly affect users' ability to get in touch with the server in the first place, not their subsequent use of the server.
Technically, PerformanceGuard records a connection reset when it receives a data packet with the RST bit set to 1. If a client attempts to connect to a server, and the server responds with a connection reset, and the server then accepts the client's next connection, PerformanceGuard will record a connection reset percentage of 100. A busy server that keeps several client connections "on hold" will lead to connection resets above 100%.
In our experience, it typically takes connection resets of 250% or above before users begin to notice. On very busy servers, we've momentarily seen 10.000% connection resets.
If a high connection reset percentage is a problem, you need to look at the performance of the server: Is the server's CPU heavily loaded? Does the server have enough RAM? Is there a disk I/O bottleneck? If you're monitoring the server with PerformanceGuard, you can easily find out, for example by looking at the server's Utilization Index.
Special Notes About the IP Traffic by Process Graph
When you use the IP Traffic by process graph, you should know the following:
All Processes Is an Average
You are able to base your graph on All processes and/or one or more individual processes. If you select All processes, the graph will show an average value for all of the processes that you are able to select. That average value can sometimes be very different from the value of an individual process.
Example: You generate a graph based on the response time for All processes as well as for two individual processes, APSDaemon.exe and Dropbox.exe. You wonder why the response time for Dropbox.exe can be many times higher than the response time for All processes. The reason is that the All processes value is an average—and not only an average of the response times for APSDaemon.exe and Dropbox.exe, but also for all other processes that ran in the selected time interval.
A Single Process May Contact Multiple Servers
If you want to view data of the type Contacted servers, be aware of the fact that a single process may contact multiple servers, and that this will be reflected in the numbers that you'll see on the graph:
If you have selected a process that communicates with more than one server (for example Skype.exe, which is a process that's known to communicate with a lot of different servers), the number of contacted servers shown on the graph will reflect the sum of server IP addresses to which all computers running that process have connected during the graph's time interval.
Example: On a simple system with only one computer with the PerformanceGuard agent installed, you select to view data of the type Contacted servers for the process Skype.exe. Because Skype.exe has communicated with 12 different server IP addresses, the graph will show you that there have been 12 contacted servers.
Example: On a larger system with 1000 computers with PerformanceGuard agents installed, you select to view data of the type Contacted servers for the process Skype.exe. Even though only 100 of the 1000 computers have used Skype.exe, the process has communicated with 12 different server IP addresses for each of those 100 computers. The graph will thus show you that there have been 1200 contacted servers.
How do I know if a process is likely to connect to many servers? This is often a question of having prior experience. However, you can get a good indication by searching for a representative computer (ANALYZE > Computers > Computer Search), then selecting the computer in the search results, and then selecting the Traffic Table tab to see which of the computer's processes have generated network traffic. We did that for a computer that we knew to run Skype, and the Traffic Table showed us that a single process, Skype.exe, had connected to multiple servers: 
Is performance good or bad? That depends on the type of work that you do in your organization, but you can often follow our rules of thumb.
IP Traffic by Application/Location/Process (Trend View)
The trend view IP traffic graph gives you an overview of periodical trends. The graph comes in three different variants:
- IP traffic by application
- IP traffic by location
- IP traffic by process
To view the IP traffic trend graphs, select ANALYZE > Graphs > Trend View and then either IP Traffic by application, IP Traffic by location or IP Traffic by process.
This graph is useful because ... you can compare performance across servers. Use this type of graph for anything that's not accessed through a web browser (for stuff that's accessed through a web browser you would typically use the Transactions trend view graph).
Generate & View Graph
Depending on which of the three variants of the graph you have selected, you may not see all of the following parameters when you set up the graph.
- Servers: Select the server or server group that you want to base the graph on. Server groups are enclosed in <>. Only server groups and monitored servers are listed, see Server Lists for details about monitored servers.
On the IP Traffic by application graph you can select multiple servers and server groups by pressing the CTRL key while selecting servers.
- Agents: Select the group of computers that you want to base the graph on. Super groups, that is groups of groups, are enclosed in <>.
- Processes: Select which processes you want to base the graph on. You can select multiple processes by pressing the CTRL key while selecting processes.
IP data process information is not collected on computers that run Windows XP.
Why is there sometimes a process called "No process name found" or "UNKNOWN"? Occasionally, a process may start and then end within a very, very short time frame. When that's the case, PerformanceGuard registers the process, but it simply doesn't have time to collect the name of the process. That's the reason why a process may sometimes appear in the list without a name.
- Ports: Select which port or port group you want to base the graph on. Port groups are enclosed in <>. Only port groups and monitored ports are listed, see Port Lists for details about monitored ports.
- Type: Determines which type of data the graph will contain. The options are described in Graph Terms & Definitions.
- Hide thresholds ...: Only relevant for certain types of data: Response time (ms) and Retransmissions (%).
For such data, a threshold—that is a baseline that the displayed values must ideally be below—can be displayed as a horizontal line in the graph when:
-
- Your PerformanceGuard administrator has defined such thresholds
- You have selected one server group and one agent group (if you have selected multiple groups, threshold display is not available, because thresholds can be different across groups)
You may sometimes see more than one threshold on a graph. This is because your PerformanceGuard administrator is able to set up multiple thresholds for the same type of data. This can be useful in order to indicate different severities, for example if values above 80 are acceptable for short periods of time, whereas values above 90 require immediate attention.
On the graph each threshold has a name, so it is easy for you to see what the threshold is about.
Display of thresholds is by default on. When you generate or view a graph, you can toggle threshold display off by selecting Hide thresholds. This can be useful, for example if you think that a threshold blocks your view of the graph's data points.
If a graph has thresholds, the thresholds will also appear if you use the graph in a report, except when they're hidden.
Displayed thresholds are always the currently valid ones.
- Y-axis Min and Max: Specify the range that you require for the graph's vertical axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
- Trend Period:
Example: If you select Day, the graph will display one data point per day.
An hour-based trend period is particularly useful when you view data from up to one week. A day-based trend period is useful when you view data from up to one month. A week-based trend period is useful when you view data from more than one month. A month-based trend period is useful when you view data from more than six months.
- Interval: Select the period of time that the graph should cover.If the predefined intervals don't suit you, select Custom to specify your own interval.
- Disconnect samples: The samples in the graph will by default be Automatic. If you don't want this you can select Connect All
Connected samples
Disconnected samples
- Fitted line: Include a fitted regression line (that is the best-fitting straight line through the graph's points).
- Split: This button is only visible on the Setup tab (next to the Update button) when you have selected one or more server groups and then generated the graph. When that's the case, you can return to the Setup tab and use the Split button to split the selected server groups into individual servers.
Data is aggregated on a per-period basis. The available periods depends on the PerformanceGuard configuration (ADMINISTRATION > Reporting > Period).
When you view the graph, you'll also see a Statistics table below the graph. Note that the Statistics table shows the weighted average for the graph's samples. That means that each value to be averaged is assigned a weight based on the number of occurrences of that value.
What's a Connection Reset, and How Can It Be Higher than 100%?
A connection reset is typically the sign of a busy server that puts clients "on hold" until it's ready to serve them. It does this by forcing clients to connect again. This buys the server time, so that it is able to get rid of its current queue of tasks before taking on new tasks. From the server's perspective the advantage of this is that it can keep the queue of clients waiting on the network rather than on the server itself.
The amount of time that a connection reset takes is very small, so it typically takes several connection resets before users begin to feel that the server is hard to reach. Once the server has accepted the connection, it will normally respond quickly. That's why connection resets mainly affect users' ability to get in touch with the server in the first place, not their subsequent use of the server.
Technically, PerformanceGuard records a connection reset when it receives a data packet with the RST bit set to 1. If a client attempts to connect to a server, and the server responds with a connection reset, and the server then accepts the client's next connection, PerformanceGuard will record a connection reset percentage of 100. A busy server that keeps several client connections "on hold" will lead to connection resets above 100%.
In our experience, it typically takes connection resets of 250% or above before users begin to notice. On very busy servers, we've momentarily seen 10.000% connection resets.
If a high connection reset percentage is a problem, you need to look at the performance of the server: Is the server's CPU heavily loaded? Does the server have enough RAM? Is there a disk I/O bottleneck? If you're monitoring the server with PerformanceGuard, you can easily find out, for example by looking at the server's Utilization Index.
Special Note About the IP Traffic by Process Graph
When you use the IP Traffic by process graph, you should know the following:
You are able to base your graph on All processes and/or one or more individual processes. If you select All processes, the graph will show an average value for all of the processes that you are able to select. That average value can sometimes be very different from the value of an individual process.
Example: You generate a graph based on the response time for All processes as well as for two individual processes, APSDaemon.exe and Dropbox.exe. You wonder why the response time for Dropbox.exe can be many times higher than the response time for All processes. The reason is that the All processes value is an average—and not only an average of the response times for APSDaemon.exe and Dropbox.exe, but also for all other processes that ran in the selected time interval.
Is performance good or bad? That depends on the type of work that you do in your organization, but you can often follow our rules of thumb.
Multicast Traffic
Multicast is when someone sends a single set of data packets across a network to multiple selected users at the same time. Multicast is subscription-based: Computers that want to receive multicast traffic use ICMP messages to let routers know which multicast addresses they want to subscribe to. The routers are then able to calculate which multicast messages they need to send to receivers on their different interfaces. A packet is considered a multicast packet if the destination IP address is in the range 224.0.0.0 to 239.255.255.255.
The Multicast time view graph (ANALYZE > Graphs > Time View > Multicast Traffic) lets you view the number of sent and received UDP packets and bytes on multicast IP addresses.
You can view such numbers measured on either the sender or on the receivers of the multicast traffic.
When you view data about multicast traffic, be aware of the fact that senders will not know who receives the outgoing multicast traffic. This is because they send data to a general multicast IP address rather than to specific IP addresses of receivers and because the UDP protocol doesn't support acknowledgment of received data. Receivers, on the other hand, will know who sent the incoming multicast traffic.
This graph is useful because ... it lets you view the amount of multicast traffic on all or individual parts of your network over time. When viewed in isolation this may provide limited value, but if—for example—you know that a particular part of your network suffers from long response times, you can use this graph to quickly verify if large amounts of multicast traffic on that part of the network may contribute to the long response times.
View Multicast Traffic Measured on Sender
Use this view if you want to know about multicast traffic measured on a computer that sends multicast traffic.
In the example illustration (click thumbnail to view image in full size) sent multicast traffic is measured on the computer with the green dot:
In the example illustration sent multicast traffic is measured on the computer with the green dot:
- Make sure that Measured on Sender is selected.
- Select required multicast sender. You can only select a single sender per graph.
- If you want to limit your results to a particular type of multicast traffic, select required multicast group. Otherwise select All Multicast.
What's a multicast group? Multicast groups help you filter your data if you are only interested in a particular type of multicast traffic. PerformanceGuard comes with preconfigured groups for common types of multicast traffic, LLMNR and SSDP, and PerformanceGuard administrators can set up additional groups. See also Manage Multicast Groups.
- In the Type menu, select what you want to view on the graph: Number of sent packets per minute or second, or number of sent bytes per minute or second.
- In the Interval menu, select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
- Click the Update button.
View Multicast Traffic Measured on Receivers
Use this view if you want to know about multicast traffic measured on selected computers that receive multicast traffic.
In the example illustration (click thumbnail to view image in full size) received multicast traffic is measured on the computers with the green dots:
In the example illustration received multicast traffic is measured on the computers with the green dots:
- Select Measured on Receiver.
- Select required multicast receivers. The receivers are grouped into locations and/or groups based on which network they belong to. If you want to know about multicast traffic received on any computer, select All agents.
- If required, you can use the Multicast Servers menu to limit your results by selecting a specific multicast server from which the received traffic must have been sent. The server that sent the multicast traffic doesn't have to be a server on your own network, it can also be an external one. If you want to know about multicast traffic received from any server, select All servers.
I can't select the multicast server that I want. What's wrong? Only monitored multicast servers are listed. See Server Lists for details about monitored servers.
- If you want to limit your results to a particular type of multicast traffic, select required multicast group. Otherwise select All Multicast.
What's a multicast group? Multicast groups help you filter your multicast data if you are only interested in a particular type of multicast traffic. PerformanceGuard comes with preconfigured groups for common types of multicast traffic, LLMNR and SSDP, and your PerformanceGuard administrator may have set up additional groups. See also Manage Multicast Groups.
- In the Type menu, select what you want to view on the graph: The number of received packets per minute or second, or the number of received bytes per minute or second.
- In the Interval menu, select the period of time that the graph should cover. If the predefined intervals don't suit you, select Custom to specify your own interval.
- Click the Update button.
Why can't I view response times for multicast traffic? Multicast messages are unacknowledged (that is receivers don't confirm that they have received the messages). Therefore, you can't be sure of exactly when the messages were received, and therefore PerformanceGuard doesn't monitor multicast response times or multicast network transmission times.
You can also view multicast activity in a table format by selecting ANALYZE > Overview > IP Traffic > Multicast Activity. See Multicast Activity Overview.
Multicast Activity Overview
Multicast is when someone sends a single set of data packets across a network to multiple selected users at the same time. Multicast is subscription-based: Computers that want to receive multicast traffic use ICMP messages to let routers know which multicast addresses they want to subscribe to. The routers are then able to calculate which multicast messages they need to send to receivers on their different interfaces. A packet is considered a multicast packet if the destination IP address is in the range 224.0.0.0 to 239.255.255.255.
The Multicast Activity overview (ANALYZE > Overview > IP Traffic > Multicast Activity) lets you view multicast activity in a list format.
- If you want to limit your results to a particular type of multicast traffic, select required multicast group. Otherwise select All Multicast.
What's a multicast group? Multicast groups help you filter your data if you are only interested in a particular type of multicast traffic. PerformanceGuard comes with preconfigured groups for common types of multicast traffic, LLMNR and SSDP, and PerformanceGuard administrators can set up additional groups. See also Manage Multicast Groups.
- Select required direction:
- Sent: Outgoing multicast traffic measured on servers that send multicast traffic.
In the example illustration (click thumbnail to view image in full size) sent multicast traffic is measured on the computer with the green dot:
-
- Received: Incoming multicast traffic measured computers that receive such data.
In the example illustration (click thumbnail to view image in full size) received multicast traffic is measured on the computers with the green dots:
- If required, you can limit your overview to a particular group of computers with the Agent menu:
- If you selected Sent in the previous step, use the menu to limit your overview to multicast traffic sent from a particular location/network
- If you selected Received in the previous step, use the menu to limit your overview to multicast traffic received at a particular location/network
If you don't want to limit your overview this way, select All agents.
- Select the required Interval (that is the period of time that you want to cover). If the predefined intervals don't suit you, select Custom to specify your own interval.
- If required, you can enter all or part of a server IP address to limit the search to multicast servers with that IP address.
Examples: To limit your search to a server with the IP address 192.168.40.72, specify that IP address. To limit your search to servers with an IP address that begins with 192.168.40, specify those IP address segments in the first three fields, and leave the last field blank.
- Click the Update button.
It may take some time to generate the list, especially if you have selected all multicast groups and all computers.
You can also view multicast activity in a graph format by selecting ANALYZE > Graphs > Time View > Multicast Traffic. See Multicast Traffic.