Graph Terms and Definitions

When you generate a graph in the PerformanceGuard web interface, you are typically able to select the exact type of data that you want to view. This list explains what the data types mean.

Individual graphs may offer fewer data types than listed here. Also, some graphs may offer other data types that are not listed here.

• Acc. histogram (%): Accumulated histogram in percent. When you select this, you are also able to select a histogram interval (for example > 10 ms).

• Active agents: The number of computers that contributed to a graph.

• Availability (%): The ratio between failed requests (that is requests that did not receive a response within acceptable time) and all requests in percent. In other words: (all requests - failed requests) / all requests × 100.

   When is something considered to be available?

  To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible,PerformanceGuardconsiders the service, etc. to beunavailable.
  By default,PerformanceGuardloses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes).
  Everything that's notunavailable, is considered byPerformanceGuardto be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week.
  
  

   Do you measure availability of application pings (HTTP request, ICMP ping and/or traceroutes)?

  For application pings, PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of 404 Not Found, PerformanceGuard considers the service to be unavailable, even if the response was received within acceptable time.

   I just set up a new server. Nobody has used it yet. How can it be 100% available?

  Bear in mind that PerformanceGuard looks at your new server based on how the PerformanceGuard agents experience it: If none of the computers with PerformanceGuard agents have used the new server, there have not been any unacceptably long response times, and the server has thus not been unavailable. Everything that's not unavailable, is considered by PerformanceGuard to be available, and that explains the 100% availability, even though nobody has yet used your new server.

• Bytes / request: The average number of bytes per request.

• Connection resets (%): Percentage of connections that were reset.

   What's a connection reset, and how can connection resets be higher than 100%?

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

• Connections / sec: The number of connections made per second.

• Number of protocol transactions: The total number of protocol transactions made by an application.

  Protocol transactions are measured on the TCP/IP socket. Basically, when there has been a break of more than 500 milliseconds in the client/server communication (also known asdead time),PerformanceGuardconsiders a transaction to be complete. The number of transactions will therefore typically relate to the nature of the transaction that has taken place. For example, if a user has listened to streaming radio, there will have been few breaks in the client/server communication, and the number of transactions will therefore be low. On the other hand, if a user has worked with multiple features in an ERP application, there will typically have been several breaks in the client/server communication, and the number of transactions will therefore be higher.

  For this parameter to work your PerformanceGuard administrator must have selected the agent configuration group setting Enable Protocol Transaction.

• Packets / request: The average number of packets that each request consists of.

• Prot. trans. acc. histogram (%): Accumulated protocol transaction histogram in percent. When you select this, you are also able to select a histogram interval (for example > 10 ms).

  Protocol transactions are measured on the TCP/IP socket.Read more about protocol transactions.

  For this parameter to work your PerformanceGuard administrator must have selected the agent configuration group setting Enable Protocol Transaction.

• Prot. trans. avg. response time [sec]: The average response time for protocol transactions made by an application. This value is in seconds.

  Protocol transaction response times are measured on the TCP/IP socket.Read more about protocol transactions.

  For this parameter to work your PerformanceGuard administrator must have selected the agent configuration group setting Enable Protocol Transaction.

• Prot. trans. max. response time [sec]: The maximum response time for protocol transactions made by an application. This value is in seconds.

  Protocol transaction response times are measured on the TCP/IP socket.Read more about protocol transactions.

  For this parameter to work your PerformanceGuard administrator must have selected the agent configuration group setting Enable Protocol Transaction.

• Received bytes / sec: The number of bytes received by a computer per second.

• Received packets / sec: The number of packets received by a computer per second.

• Requests / sec: The number of requests made by a computer per second.

• Response time: The time it takes for a client to receive a response from a server. This value is in milliseconds.

• Retransmissions (%): Percentage of TCP packets that were retransmissions. This number tells you how much data has been sent again because the original sending failed. It thus tells you about the amount of data that has traveled on the network twice.

• RTT avg: The average round-trip time (RTT) for an application. This value is in milliseconds.

  RTT is the length of time it takes for a client to send a request plus the length of time it takes for an acknowledgment from the server to be received by the client. RTT does therefore not include the time it takes for server applications to respond or the time required for data transfer.

• Sent bytes / sec: The number of bytes sent from a computer per second.

• Sent packets / sec: The number of TCP packets sent from a computer per second.

• Total connections: The total number of connections made by an application.

• Total received bytes: The total number of bytes received by an application.

• Total requests: The total number of requests for an application.

• Total response time [sec]: The total response time for an application. This value is in seconds.

• Total sent bytes: The total number of bytes sent by an application.