Page Comparison

The Response Time Histogram displays response times for selected servers.
To view the histogram, select ANALYZE > Graphs > Statistics > Histogram.
The histogram consists of 10 individual bars.
Each bar represents the percentage of replies within a given milliseconds interval.
This way you can very quickly find out if a particular server is potentially overloaded—like the blue one Image Modified in the example image.
Image Modified
In the example, we use the histogram to spot a potentially overloaded server. However, the main benefit of the histogram is that it helps you verify if a high average response time is caused by a major or a minor ratio of the total requests. This in turn can help you determine whether a high average response time is really a problem.
How can a high average response time not be a problem?  If a high average response time is caused by a few responses in the 2000-500000 milliseconds interval while the majority of responses are in the 0-10 milliseconds interval, the high average may not be a problem. This of course also depends on your type of organization, which types of applications and servers you run, how business-critical your applications are, etc.

Image Modified

Image Modified

1. Servers: Select which servers or server groups you want to base your histogram on. Server groups are enclosed in <>. You can only select server groups and monitored servers. See Server Lists for details about monitored servers.

Select multiple servers and server groups by pressing the CTRL key while selecting the servers.

1. Agents: Select the group of computers you want to base your histogram on. Super groups, that is groups of groups, are enclosed in <>.
2. 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.
3. Ports: Select which port or port group you want to base your histogram on. Port groups are enclosed in <>. You can only select port groups and monitored ports. See Port Lists for details about monitored ports.

1. Specify required server, either by selecting it from the list, by specifying required Server hostname or by specifying required Server IP address (or parts of it).
2. In the Agents list, select the required location or group of computers.
3. 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.
4. Click the Update button.

Click the Update Simple or Update Detailed button.
What's the difference between Update Simple and Update Detailed?  Update Simple will show the information that users most often want to view, including process names, total response times, sent/received packets and bytes, etc. Update Detailed will show the same information plus information about retransmissions, connections and response times grouped into intervals.

1. If you want to filter the results on a particular process that has been used in the communication, select the required process from the Process list and click the Update Simple or Update Detail button again.

Why can't I select process to start with?  You may often be able to do so, but it's generally better to select the required process after you have defined your other criteria and updated the table. This is because the list of relevant processes depends on your other selections. For example, more processes may have been active during the last 30 days than during the last 30 minutes.
IP data process information is not collected on computers that run Windows XP.
Based on your parameters, the table lists some or all of the following:

1. Server hostname: The name of the server that the computers communicated with.

When servers are monitored servers, you can click their names to view more details on the IP traffic by application graph.

1. Server IP: The IP address of the server that the computers communicated with.
2. Process name: Name of process used in the communication, for example chrome.exe.
3. Process version: Version of process used in the communication.
4. Port: The port through which communication took place, for example HTTP.
5. Protocol: The protocol type used for the communication, TCP or UDP.
6. Total response time: The time, in milliseconds, until the server/port response was received by all the computers on the server/port.
7. Received bytes: The total number of bytes received by all the computers on the server/port.
8. Sent bytes: The number of bytes sent from all the computers on the server/port.
9. Received packets: The total number of IP packets received by all the computers on the server/port.
10. Sent packets: The total number of IP packets sent from all the computers on the server/port.
11. Retransmissions: The number of TCP retransmissions by all the computers on the server/port.
12. Responses: The total number of trains received by all the computers on the server/port.
13. Requests: The total number of requests made by all the computers on the server/port.
14. No application response within 500 seconds: The number of times that no application response with payload was received within a time frame of 500 seconds.

15. Wiki Markup
    *\[Response times grouped in milliseconds intervals\]{*}: The number of response measurements in the respective intervals by all computers on the server/port.

16. Reports: The total number of times the server/port has been contacted by all computers.
17. Connections: Total number of TCP connections to the sever/port by all computers.
18. Connection resets: Total number of times that TCP connections to the sever/port were reset by all computers.

What's a connection reset?  A connection reset is typically the sign of a busy server that puts clients "on hold" until it is 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 high number of connection resets 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.
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.

1. Selecting multiple servers allows you to compare the performance between different servers in an application cluster.
2. Selecting multiple agent groups (client locations) allows you to compare performance delivered to different client locations
3. Selecting both multiple servers and multiple client locations allows you to view the performance by server for each client location

Each bar represents a server location combination. The length of the bar represents the value of the selected data type, that is response time, sent bytes, etc.
This graph is useful because ... you can verify servers' performance as experienced by your organization's individual locations. Even if you initially base the graph on high-level groups of servers and/or computers, you can use the graph's Split features (see the following) to, for example, view server performance as experienced by individual subnets.

1. Servers: Select which servers to include in the chart. You can select multiple servers or server groups by pressing the CTRL key while selecting.

Only monitored servers are listed.

1. Agents: Select which groups of computers you want to include in the chart. You can select multiple groups by pressing the CTRL key while selecting. Super groups and locations are enclosed in <>.

If you select super groups or locations, a check box will appear that lets you split the super groups or locations into their members. This is useful, for example, if you want to create a chart that compares performance across different cities in a country. If you use this option on a chart that's added to a custom report, your report will always dynamically represent all members of the selected super groups/locations.

1. Ports: Select which port to include in the chart.

Only monitored ports are listed, see Port Lists for details.

1. X-axis Min and Max: Enter the required range for the bar chart's horizontal axis. If you leave the fields empty, the range will automatically reflect the minimum and maximum values found in the data.
2. 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.
3. Type: Type of data that the graph will contain. The options are described in Graph Terms & Definitions.
4. Update: Click to generate the chart.
5. Split Agents: If you have based your chart on one or more locations or super groups (that's logical groups of groups of computers), this button will appear. If you click the button, it'll split the locations/super groups into their members in the Agents section.
6. Split Servers: If you have based your chart on one or more server groups, this button will appear. If you click the button, it'll split the server groups into their members in the Servers section.

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.