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

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

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

The Aternity Agent calculates the client time as the total activity response time minus the 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.

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

The network time is calculated as the infra time minus the 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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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 .

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