Specifications

Rule Development Process
the individual events do not generally add up to the overall elapsed time for a
transaction. To account for the entire duration of a transaction, you must
provide for the inter-event gaps when computing a transaction's response time
breakdown.
In general, every event has a duration that contains the same five components
as a transaction:

Client Processing Time. Elapsed time spent processing at the application
client. For Terminal Services, this refers to processing time on the terminal
server system itself, not the end-user client system.

Client Think Time. Elapsed time waiting for user input.

Network Time. Transmission time exchanging data with the application
server.

Server Processing Time. Elapsed time waiting for a response from the
application server.

Terminal Server Latency. Elapsed time transmitting application
input/output between the end-user client system and the terminal server
system.
To compute the response time breakdown for a transaction, the transaction is
divided into intervals based on the starting and ending time of all application
events that occur during the transaction. Application Response computes a
separate response time breakdown for each interval, and the sum of
components for all intervals determines the overall response time breakdown
for the transaction. Although a transaction's response time contains five
components, the response times that appear in reports typically do not include
the Client Think Time component. This component is subtracted to provide
focus on other causes of performance issues (client, network, or server).
Rule Development Process
To use the BT Studio tool set to develop rules that recognize transactions,
follow this general process:

Determine which transactions you want to monitor for performance.

Install BT Studio.

Generate an event log file.

Develop rule sets using the event log file as input to BT Studio.

Update Application Response with new rules.
The BT Studio Tool Set 23