IP Traffic by Application/Location/Process (Time View)

Owned by Youssef Benarab
Last updated: Nov 29, 2019
7 min read

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.

Search this documentation

On this page

In this section