With the Server Activity overview (ANALYZE > Overview > IP Traffic > Server Activity) you can view detailed data about servers that your organization's computers have communicated with. You can then select specific processes that have been involved in the communication, and view details such as sent/received bytes and packets, response times, etc. for each process.

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).
In the Agents list, select the required location or group of computers.
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.
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.
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:

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.
Server IP: The IP address of the server that the computers communicated with.
Process name: Name of process used in the communication, for example chrome.exe.
Process version: Version of process used in the communication.
Port: The port through which communication took place, for example HTTP.
Protocol: The protocol type used for the communication, TCP or UDP.
Total response time: The time, in milliseconds, until the server/port response was received by all the computers on the server/port.
Received bytes: The total number of bytes received by all the computers on the server/port.
Sent bytes: The number of bytes sent from all the computers on the server/port.
Received packets: The total number of IP packets received by all the computers on the server/port.
Sent packets: The total number of IP packets sent from all the computers on the server/port.
Retransmissions: The number of TCP retransmissions by all the computers on the server/port.
Responses: The total number of trains received by all the computers on the server/port.
Requests: The total number of requests made by all the computers on the server/port.
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.
[Response times grouped in milliseconds intervals]: The number of response measurements in the respective intervals by all computers on the server/port.
Reports: The total number of times the server/port has been contacted by all computers.
Connections: Total number of TCP connections to the sever/port by all computers.
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.

Search this documentation

On this page

In this section

Browser not supported