View Data Collected by Aternity for All Activities

Aternity collects a wide range of data for every activity reported. An activity is an end user interaction or event in a managed application (like a mouse click, or pressing Enter), together with its response (like a change on the screen). Aternity measures the activity response time, which is the time between the activity's start event and its response (end event). For example, it can monitor the launch of an application, or the time to respond to a menu choice.

You can view this information in most Aternity dashboards, including the Troubleshoot Application dashboard, Troubleshoot Activity dashboard and the Activity Resource Analysis dashboard.

Times Collected for an Activity

For every activity in the system, Aternity measures the following times:

Field Description Source
Activity Response

An activity response is the time taken for an application to complete an activity in seconds.

Activity response time

Use the actual response times (not scores) to check the performance of chronic (long term) problems. You cannot rely on measurements based on the recent baselines, as those responses would be chronically slow for some time, thereby skewing baselines to make those times look normal.

The response times of activities are split into client time ( dark blue), and the combination or union of the server time ( light blue) and the network time ( blue).

Server, network and client time

The Aternity Agent calculates the activity response time by measuring the time between the start event and the end event of an activity, as defined in the activity itself (its signature).

Client Time

Client time is the time used by the device itself as part of an activity to process data before sending its first message request to the server and after the last message response arrives back from the server.

Client time is the time on the device side to process data as part of the activity response

The Aternity Agent calculates the client time as the total activity response time minus the infra time.

Infra Time

Infra time is the total time spent outside the client. It starts with the first request to the server and ends when the final response arrives at the client.

Definition of infra time

This field is also known as Total Network Response Time.

The infra time is calculated as the total of network time and server time. If there are multiple overlapping calls to one or more servers, the total infra time is the combination (union) of all server and network times.

Network Time

Network time is the total time (union) taken for all messages to cross the network in either direction, between the client and the target server, while performing an activity. This does NOT include the time used for processing the request on the server (server time).

This forms part of an activity's infra time.

Network time is the time for all messages to cross the network and back as part of an activity response

The network time is calculated as the infra time minus the server time.

Server Time

Server time is the time required by the server to process data on the server side. It starts when the client requests the target server's help to respond to an activity, when the last message of that request arrives at the target server side. It ends when the server sends out the first message of its response.

This forms part of an activity's infra time.

Definition of server time in a client-server application

The server time for a single request-response pair is from the last send to its first response minus the round trip time. If the activity calls a server more than once, or several servers, the reported time is the combination (union) of all the individual times together. If the target server calls other back-end servers, Aternity's server time is the total (union) of all network times and server times of all back end servers in that chain, ending when the activity's target server sends its response to the client.

Round Trip Time

Round trip time (RTT) is the time between sending a message to the server and the return of its echo acknowledgment back to the client.

Each request from the client generates an acknowledgment from the server that it received the request. RTT measures the time of a single request and its acknowledgment. It does NOT include the response of the request, which would require the server to process the request.

The system displays the Average Network Round Trip Time for all the RTTs performed while the activity is ongoing.

A single message and its acknowledgment, before any server processing

The Aternity Agent retrieves the RTT of each server connection from the logs of the Windows TCP/IP driver.

It also reports the time stamp when the activity occurred:

Field Description
Measurement Time

An activity's measurement time is the time stamp when the Aternity Agent on the device noted the occurrence of the activity. The time stamp is translated to the time zone of the Aggregation Server.

Server Analysis Time

An activity's server analysis time is the time stamp when the Aternity servers received the report of the activity and analyzed it.

Measurements Accompanying an Activity

Alongside the core times of an activity, Aternity also collects several measurements which happen at the same time as the activity.

Field Description
CPU Usage of Application during Activity

View the percentage CPU utilization of this Windows process while it performs an activity, measured as a percentage of the total power of all CPU cores available.

During an activity, if an application uses resources (x% CPU or RAM), or sends x MB of network traffic, it is not the same as saying that it is because of the activity. They happen at the same time, so they are correlated (see Correlation vs. Causation). However, you can be reasonably confident that these device measurements occurred because of the activity.

Memory (RAM) Usage of Application During Activity

View the percentage utilization of memory (physical RAM) for this Windows process, while it performs an activity.

If the activity always coincides with a spike in memory consumption, this is probably the cause of slow performance.

During an activity, if an application uses resources (x% CPU or RAM), or sends x MB of network traffic, it is not the same as saying that it is because of the activity. They happen at the same time, so they are correlated (see Correlation vs. Causation). However, you can be reasonably confident that these device measurements occurred because of the activity.

Network Incoming / Outgoing Traffic

Aternity monitors the total volume of network traffic in both directions while an application performs an activity, and then reports the average of those totals in KB during each one hour slot.

Remote Display Latency

The remote display latency is the average time taken for the round trip of a network data packet to travel between the front line user and a virtual server (both ways).

Practically, it is the time between performing an action in a virtual session on the front line user's machine, then sending that action to the virtual desktop server (VDI) or virtual application server, and then viewing that action back on the front line terminal again. This does NOT measure the time for the application to respond.

Effective response time of a VDI end user
Target Servers

Displays the name or IP address of the server which the device contacted as part of performing the activity. For example, if the activity is in SAP, this field would display the FQDN of the SAP server.

This is used for backward compatibility, but is now more clearly defined In the Server Hostname, Server IP and Server Name fields.

Virtual Memory Usage of Application During Activity

View the percentage utilization of virtual memory for this Windows process, while it performs an activity.

If the activity always coincides with a spike in memory consumption, this is probably the cause of slow performance.

During an activity, if an application uses resources (x% CPU or RAM), or sends x MB of network traffic, it is not the same as saying that it is because of the activity. They happen at the same time, so they are correlated (see Correlation vs. Causation). However, you can be reasonably confident that these device measurements occurred because of the activity.

Activity Scores and Statuses

Aternity uses the collected data to calculate statuses and scores based on established baselines, as detailed below:

Field Description
Activity Score

The activity score is a value between zero and 100 (with a status and color) which condenses many activity statuses into a single value, and is calculated with an Apdex-inspired formula.

Use the Score to measure short term (acute) sudden changes in performance, as they rely on recent baseline measurements. The score clearly reflects a recent change because it would be significantly different from the established baseline response times. For example, if a mail usually opens in 1.5s, (the baseline response time), it creates a minor baseline (small departure from the baseline) and a major baseline (significant departure). If performance is suddenly (acutely) much slower, like 5s, it would be beyond the major baseline, and therefore have a red status with a low score.

Use the actual response times (not scores) to check the performance of chronic (long term) problems. You cannot rely on measurements based on the recent baselines, as those responses would be chronically slow for some time, thereby skewing baselines to make those times look normal. In this example, if the activity for opening mails has been 5s for several weeks, the system adjusts its baselines to 5s, so this now looks normal, and therefore has a green status with a good score, which is misleading.

Aggregating many end user activities into a single score and status
Activity Status

The status of an activity is based on one response time compared to the recent expected (baselined) response time. The statuses are measured in severity: Normal , Minor , Major or Critical .

Activity response measured time with a status
SLA Activity Status

The SLA status of an activity determines if the response time complies with the SLA requirement (colored green ), or if it crossed the internal SLA threshold showing you risk breaking the SLA (colored yellow ), or if it crosses the external SLA threshold showing you have broken your SLA (colored red ).