View Activities Data Collected by Aternity

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, part of the overall response time of an activity. It starts when the client sends a request to the target server, 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. For more server-side visibility, view the transaction details in SteelCentral AppInternals™.

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

Displays 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.

Physical Memory (RAM) Usage of Application During Activity

View the amount of working set 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.

Network Incoming / Outgoing Traffic

Aternity reports the total volume of network traffic in KB in both directions while an application performs an activity.

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
Server Hostname

Displays the actual hostname of the server (NOT its DNS alias), when an application on the device contacts a server. For example, on a device using Outlook 365, the hostname might be outlook-emeacenter.office365.com while its DNS name is shortened to outlook.office365.com. This is a clearer definition to replace Target Server.

If you contact more than one server during an activity, it reports the server whose total server time was longest during that activity.

Server IP

Displays the IP address of the server, when an application on the device contacts a server. For example, on a device using Outlook, it displays the IP address of the Exchange server. This is a clearer definition to replace Target Server.

If you contact more than one server during an activity, it reports the server whose total server time was longest during that activity.

Server Name

Displays the DNS alias of the hostname of the server (not the computer's actual hostname), when an application on the device contacts a server. For example, on a device using Outlook 365, the DNS name might be outlook.office365.com while its full hostname might be outlook-emeacenter.office365.com. This is a clearer definition to replace Target Server.

If you contact more than one server during an activity, it reports the server whose total server time was longest during that activity.

Target Server

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.

If you contact more than one server during an activity, it reports the server whose total server time was longest during that activity.

Virtual Memory Usage of Application During Activity

View the amount of reserved memory (commit size) 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 (0-100) with a status and color which condenses many activity statuses into a single value, and is calculated using our Apdex-inspired formula.

Use the Score to measure short term (acute) sudden changes in performance, as they rely on recent baseline measurements. The score 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 ).

SLA internal and external thresholds