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.

Tip

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 Web Activities (Time View)).

Generate and view the graph

Set up the graph on the Setup tab, and then click Update. The graph opens on the Graph tab.

Caution

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 also select All Servers(Not Just Monitored). 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.

  Sometimes the list contains a process called No process name found or UNKNOWN. This happens when a process starts and ends within a very short time frame: PerformanceGuard registers the process, but doesn’t have time to collect its 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 and Definitions. For some types, a Histogram list appears where you select the response time interval to show.

• 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 Custom Time Periods on Graphs.

• Disconnect samples: By default, the samples in the graph are connected by a line. Select this check box to show the samples as separate points. On the Graph tab, you can switch between the two with the Connect samples/Disconnect samples button.

  

  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.

• split: This button appears next to Update when you have selected one or more server groups (or, on the IP Traffic by location graph, locations or super groups). Click it to split the selected groups into their members.

Thresholds

For the data types Response time (ms) and Retransmissions (%), 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. On the Graph tab, you can toggle threshold display off by clicking Hide thresholds (and on again with Show 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.

Statistics table

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 Computer 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.

Important

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.

Important

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.

On a larger system with 1000 computers with PerformanceGuard agents installed, only 100 of the 1000 computers have used Skype.exe, and 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 I Want to Know if Performance Is Good or Bad.