Protocol Transactions

PerformanceGuard is able to measure business transaction response times from TCP/IP streams. Because we measure on the actual TCP/IP protocol stream, we call this protocol transactions. You can view data about protocol transactions on the IP Traffic time view graphs in the PerformanceGuard web interface.

In the following we will go through the criteria that PerformanceGuard uses to determine when one protocol transaction ends, and another one begins:

Protocol transactions are made up of requests from the client, each of which is serviced by the server. The client continues to request data from the server until the transaction has been completed.

Because the client typically waits for the user to perform some manual processing, a considerable amount of time may pass between protocol transactions. In order to determine when a protocol transaction is complete PerformanceGuard therefore uses a dead time period of 500 milliseconds (known as latch time in agent configuration group settings). When the TCP/IP socket has been silent for the dead time period, or when the socket is closed, PerformanceGuard records a protocol transaction.

There is an exception, however: If the client sends a request to the server, it doesn't matter how long it takes before the server responds, even if the wait is longer than the dead time period—unless the client itself sends another request after not having received any response from the server for the duration of the dead time period.

A protocol transaction is thus defined as follows:

• When a socket has been without packets for the duration of the dead time period, a measurement for a new protocol transaction will be initiated if the client sends a packet to the server.
  
  
• The protocol transaction response time measurement will be complete once the socket has been silent for the duration of the dead time period, provided a response has been received from the server at some point.
  
  
• If an unsolicited packet is received from the server after a silent dead time period, a new protocol transaction won't be started until a silent dead time period has been observed.
  
  
• If a packet is sent from the client to the server, and no reply is received from the server within the dead time period, a silent dead time period must be observed before a new protocol transaction can be started.

Examples

• A simple protocol transaction consisting of packets to and from the server. The boundaries of the transaction is defined by silence on the socket for at least the duration of the dead time period:
  
  
  
• The silent time on the socket is greater than the dead time period. PerformanceGuard thus records two separate transactions:
  
  
  
• Here, two transactions are recorded because more time than the dead time period has elapsed without packets on the socket:
  
  If the client sends a request to the server, it doesn't matter how long it takes before the server responds, even if the wait is longer than the dead time period. So why doesn't the second transaction start in the middle of the illustration? Because the client itself sends another request after the second dead time period has elapsed.
  
  
• Again, two transactions are recorded because unsolicited packets have been received from the server: