How do I interpret synthetic transaction data?
Article ID: 166139
Updated On:
Products
Issue/Introduction
Synthetic transactions provide a means to baseline service response times from any PacketShaper in the network, eliminating delays in non-controllable parts of the network and delays caused by slow clients.
Retrieval and interpretation of the results of transaction is the same as for regular transactions.
See RTM Overview in PacketGuide for details on response time measurement.
Resolution
While interpreting the results of synthetic transaction is the same as for other transactions, there are a couple of things to be aware of.
The synthetic transaction feature makes no effort to parse the responses, neither does the RTM engine on PacketShaper; however the measurement engine does record, for all HTTP transactions, the category of the response in variables named "web-response-NXX."
You can examine them to see, for example, whether the response to the GET was a good 200 OK or some error such as a 404 Not Found.
If web, ftp, or email services are no longer running on the server, the connection will be refused. Because there are no transactions, no response time is measured.
The Service Level degrade will show up as Server connection refuses in the TCP Health graph.
Response Time Statistics
To retrieve response time statistics, you first need to go to the appropriate class. Use the child classes created for you in the SyntheticTransactions classes. If the server contacted in a transaction is on the inside of PacketShaper, then the class under /Inbound will hold the statistical information; the Outbound class will only have zero-values.
PacketShaper offers two basic reporting types: graphical or numerical data. Both types can be accessed via the statistics menu in the manage tab.
In addition, the statistics menu has a response time option. This will display a summary screen giving the average transaction total delay, network delay, and server delay for the class (see ResponseTimeScreen.gif attachment). It also allows you to set the delay threshold and service level compliance level.
As can been seen from the attached screen, 69% of the transactions were good and there were 5 non-compliant service minutes during the time analyzed. As the actual time analyzed was only 5 minutes (shown top right) there were no service level compliant time periods. Setting the service level threshold below 100% will increase the value.
This information can be displayed in more detail using the graphical representation.
See the DelayGraph1.gif attachment.This graph shows the delay break down between server and network as well as the delay threshold. Network delay is measured as the time between sending the SYN and receiving the SYN-ACK. The assumption is that the SYN-processing is done in the kernel of the operating system and has a negligible delay.
The DelayGraph2.gif (see attachment) is an example that this is not always a correct assumption. The server in this second graph was actually a Windows 2000 Server connected via a local 100Mbps segment. A load generator on the machine was used to cause 100% CPU utilization.
Feedback
