You can use timestamp values to analyze performance of the CX PCA.
Passive Capture provides a rich set of time values available for analysis.
The following assumptions apply to timestamps.
- All timestamps are created by the Passive Capture software at the point of capture. When the software sees data at its capture point, it then assigns a timestamp.
- The Passive Capture host machine is a short, negligible distance from the HTTP generating source. However, this factor must not impact the timestamps, since data typically flows unimpeded from the web server to the client.
- Data is sent as fast as the end-to-end network path permits. There are potential issues that can affect the timestamp accuracy of the traffic that is arriving at the PCA. If the capture point is a switch span port, the internal buffers that are used to aggregate the span traffic can change its real-time data arrival. Buffers can hold and burst the span port traffic at any time that impacts the accuracy. Other network devices can also change the data arrival times if it's part of the capture traffic path but not in the live traffic path.
- All timestamps are specified in GMT with microsecond granularity. A microsecond is one-millionth of a second.
- The Tealeaf CX UI Capture for AJAX is a separately licensed component of the Tealeaf CX platform.
Example timestamps in the request
The following example values are displayed in the request after the PCA generates its timestamps.
RequestTimeEx=2009-02-26T15:33:58.347692Z
RequestEndTimeEx=2009-02-26T15:33:58.347836Z
ResponseStartTimeEx=2009-02-26T15:33:58.352928Z
ResponseTimeEx=2009-02-26T15:33:58.552479Z
ResponseAckTimeEx=2009-02-26T15:33:58.693390Z
TLapiArrivalTimeEx=2009-02-26T15:33:58.676361Z
ReqTTLB=144
RspTTFB=5092
RspTTLB=199551
RspTTLA=140911
ConnSpeed=628604
ConnType=DSL
WS_Generation=5092
WS_Grade=ExcellentWS
WS_GradeEx=0
NT_Total=340462
NT_Grade=ExcellentNT
NT_GradeEx=0
RT_Total=345554
RT_Grade=ExcellentRT
RT_GradeEx=0Where
RequestEndTimeEx=2009-02-26T15:33:58.
ResponseStartTimeEx=2009-02-26T15:33:58.
ResponseAckTimeEx=2009-02-26T15:33:58.
WS_Generation=5092
NT_Total=340462
RT_Total=345554are used to calculate timestamps and network behavior, and
347836
352928
693390are the timestamp values that are used for later calculations.
The following table provides an explanation for each of the values in the [timestamp] section of the request.
| Value | Description |
|---|---|
RequestTimeEx |
Start of the request. The timestamp when the PCA saw the first packet of the request. |
RequestEndTimeEx |
End of the request. The timestamp when the PCA saw the last packet of the request. |
ResponseStartTimeEx |
Start of the response. The timestamp when the PCA saw the first packet of the response. If no response packets were seen, then the RequestEndTimeEx value will be used. |
ResponseTimeEx |
End of the response. The timestamp when the PCA saw the last packet of the response. If no response packets were seen, then the RequestEndTimeEx value will be used. |
ResponseAckTimeEx |
Timestamp when the PCA saw that client/browser acknowledged the last TCP packet of the response. If no response packets were seen, then the RequestEndTimeEx value will be used. |
TLapiArrivalTimeEx |
This timestamp indicates when the hit arrives within the PCA pipeline process. The completed reassembled hit time may be much later if an incomplete hit was reassembled or was delayed due to a very late last data packet. In an otherwise normal case, this timestamp should be roughly the same as the ResponseTimeEx. A large difference could indicate a network issue. |
ReqTTLB |
Time in microseconds from the first packet of the request to the last packet of the request (RequestEndTimeEx minus RequestTimeEx). This value does not include network time. |
RspTTFB |
Time (in microseconds) from the start of the request to the first of the response page (ResponseTimeStartEx minus RequestTimeEx). This value is usually an accurate approximation of the time that the Web server required to generate the response page. In particular, if the entire page is buffered (the default for ASP .NET and many J2EE environments), then this measurement is an exact predictor of how long the server-side infrastructure took to respond.
This value may not be accurate if the Web server served the data in chunks. |
RspTTLB |
Time in microseconds from the first packet of the response to the last packet of the response (ResponseTimeEx minus ResponseStartTimeEx). This value does not include network time. |
RspTTLA |
Client/browser acknowledgment time of the last data packet (ResponseACKTimeEx minus ResponseTimeEx). This value is an indication of network round trip.
To compute one-way time, divide this value by 2. |
ConnSpeed |
Connection speed, specified in bits per second (bps). This value is calculated by dividing the average size of the response by the average time it took to deliver.
When determining connection speed, any detected client user interface events are ignored. |
ConnType |
Based on the ConnSpeed setting, this value is set to Dialup, ISDN, DSL, or T1. |
WS_Generation |
Time in microseconds for the web server to generate the response. This value is computed as: ResponseStartTimeEx - RequestEndTimeEx |
WS_Grade |
The grade assigned to the web server page generation time (WS_Generation).
This value is indexed by default. |
WS_GradeEx |
A number representing the TimeGrades time range grouping between 0 and 4 for web server page generation time. |
NT_Total |
Time in microseconds for the network travel time. |
NT_Grade |
The grade assigned to the network travel time (NT_Total).
This value is indexed by default. |
NT_GradeEx |
A number representing the TimeGrades time range grouping between 0 and 4 for network travel time. |
RT_Total |
The total round trip travel time in microseconds. |
RT_Grade |
The overall grade for network performance. Possible values are the following
This value is indexed by default. |
RT_GradeEx |
A number representing the TimeGrades time range grouping between 0 and 4 for round trip travel time. |
Factors affecting timestamp values
The following factors must be considered when evaluating timestamps.
- In a multitier networked environment, there is usually no storage on the network. However, large and sophisticated server farms can employ a load balancer (for example, F5), so some data storage of the HTTP request can affect timestamp values. Since these dedicated devices are highly customized for speed, this impact is hardly noticeable.
- Content-caching devices in the environment can distort time values. When content is cached, the time values are reduced.
- For large average page sizes, it is more efficient to compress data for faster transfer.
- If the HTTP/1.1 Keep-Alive option is enabled, it can affect the rate at which multiple HTTP requests can be made.
- Application Delivery settings impact performance measurement. Is buffering turned on? I.e., does the application start transmitting when the first byte is ready, or does it wait for the entire page to first be ready?
- Chunking affects timestamp values. The answer can be delivered in one chunk, or it can be chunked and delivered on demand, such as a PDF file with byte serving.
- Client-side browser settings can affect performance and time values. For example, if caching is enabled, transfer times of pages that are containing cached content are reduced. The size of the cache is a factor.
Timestamps in ReqCancelled hits
When a request is canceled either by the visitor or the server, timestamps may not be inserted as normal based upon the time of cancellation.
Tealeaf inserts timestamps according to the following table.
| Current action at time of cancel | Request Timestamp | Response Timestamp |
|---|---|---|
| Request submitted, Response not started (Response Size = 0) | request timestamp | Use RequestEndTimeEx value |
| Request submitted, Response started (Response Size > 0) | request timestamp | response timestamp |
The reason for a response not starting can include any of the following:
- Visitor cancellation
- Server cancellation
- Network issue
- Server took too long to response and PCA packet timeout was exceeded
- PCA unable to match request to response
Req Cancelled Count event, you can tabulate the counts of all occurrences by specifying the data type for the event to be a [Sum], instead of a [Count].Hits without timestamps
If a hit is received with improperly formatted or incomplete timestamp information, the PCA does not generate these associated timestamps.
When the hit is passed to the Processing Server for evaluation, the Processing Server applies a timestamp value of 01/01/1970 to the hit. The hit is then written to a session file with the same timestamp.
Each hour, the Processing Server deletes session archive files that are older than the number of days of data that is configured to be retained in the Processing Server. So, the hit is automatically deleted every hour.
The number of days of data that is retained by the Processing Server is defined in the Canister Services tab of Canister configuration in TMS.
In addition to malformed or missing timestamps, the following types of hits cannot have timestamps:
- Tealeaf system statistics hits submitted by various Tealeaf components to report on their status cannot be filtered out of the Canister capture stream by the Session Router session agent.
- If the cxReveal search database is deployed, there can be references to these hits in the data that is inserted into the database. When a cxReveal search is executed, the hits can already be purged. While the database indicates that the hits exist, they do not exist in the Canister data.
Reporting of timestamps in portal and RTV
The portal and RTV provides the following timestamp values.
| Timestamp value | Description |
|---|---|
| Page Generation Time |
Page Generation Time is the time that is required, after the request is received, for the web infrastructure (WS/AS/DB) to process the response and to begin transmitting it to the client browser. This time value in microseconds is the time between the PCA saw the last packet of the request to the time when the first packet of the response is received by PCA. This value is calculated and inserted into the request as: In the example request that is displayed above, the |
| Network Time |
Network Time is the time difference between when the web server starts sending the response to when the PCA receives the acknowledgment from the visitor. This value is calculated and inserted into the request as: In the example request that is displayed, the |
| Round-Trip Time |
Round-Trip Time is the time difference between when the final packet of the request is received by the PCA and when the PCA receives the acknowledgment from the visitor that the entire response is received. This value is calculated and inserted into the request as: In the example request that is displayed above, the Reviewing the two previous sections: |
| Render Time |
Tealeaf UI Capture can be deployed to capture user interface events in the client browser and to monitor client-side metrics, such as the time required to render the page in the browser. If UI Capture is deployed, render time is reported to Tealeaf in milliseconds. |
Reporting
Reports that are based on timestamp information that is captured and computed by Tealeaf, can be configured and reviewed through the Portal.
If you deploy the CX UI Capture for AJAX library, more client-side timing information is available in Portal-based reports.