Enterprises today rely heavily on sophisticated and complex software applications to conduct their business, meet customer expectations, remain competitive, and achieve profitability.
To effectively manage, troubleshoot, and scale these applications in a rapidly changing business environment, it is imperative that system administrators and managers have access to detailed, accurate, and meaningful application performance data.
Iain Goodway of Concord South Africa, says the complexity of business applications and the network infrastructures that support them, have historically made it difficult to accurately monitor the performance and reliability of applications - which is where Concord eHealth Application Response - a software product specifically designed to monitor and report on actual end-to-end response times of business applications, as experienced by application end-users -steps into the breech.
Concord`s eHealth Application Response is a data management and reporting tool that collects performance data and provides detailed snap shots, views of historical trends, and summary reports that give managers a view of the overall health of their applications.
Goodway explains: "Application Response captures performance data using AR Agents and stores this data in the eHealth database. The eHealth console provides a graphical user interface for management of AR Agents, database management, and reporting."
The architecture of the eHealth Application Response environment, he says, is relatively simple.
The AR Agents are small software components that reside on client devices and monitor application response from the end-user`s point of view.
AR Agents record the total end-to-end transaction response time, along with a breakdown of processing time spent on the client machine, processing time spent on the server, and time spent sending data back and forth across the network. Information collected by AR Agents is stored in the eHealth database.
The eHealth console provides a graphical user interface for the management of Application Response. Performance data collected by AR Agents is forwarded to eHealth and stored in the eHealth database.
"When considering how AR makes response time measurements it is important to remember that there are two components that make up the response time measurement," Goodway explains. "One is the mechanism or engine that the agent uses to calculate the specific components of response time (client, network and server); this is constant, meaning that the agent uses the same mechanism to make the measurements every time. The other is the rule(s) that defines the boundaries of the specific transaction that AR is monitoring.
"Therefore the accuracy of the rules has a direct impact on the overall accuracy of the response time measurements."
The following table provides a simple example of how the AR Agent measures application response time in a client-server environment.
In this example, the user of a client, accessing an application on an application server, clicks a "Submit Order" button and waits for a "Confirmation" window to be displayed. The details of the exchanges are shown below.
T1. Mouse Click on Button
T2. Request Packet 1 Sent by Client
T3. Request Packet 1 Arrives at Server
T4. Request Packet n Sent by Client
T5. Request Packet n Arrives at Server
T6. TCP Acknowledgment for Request Packet n arrives at client
T7. Response Packet 1 Sent by Server
T8. Response Packet 1 Arrives at Client
T9. Response Packet m Sent by Server
T10. Response Packet m Arrives at Client
T11. Client Screen Fills Up With Data
Client think time and client processing time - Client think time is the time between users events, where as client processing time is the time between a user event and network activity. Consider the following example, a user clicks a dialogue box, fills in a form and then clicks submit.
* The time between when the user clicked on the dialogue box and the new windows appears is client processing time.
* The time between when the window appears and the user clicks the submit button is Client think time.
* The time between when the submit button is clicked and network activity is detected for the target application is client processing time.
In the above example,
Client Time = (T2 - T1) + (T10 - T9)
Remote time - Remote time is the amount of time that a transaction spends outside the client system (network time + server time). The actual measurement is made from the point when the client sends a request and ends when the client finishes receiving the response.
Remote Time = T9 - T2
Network time - Network Time is the amount of time the interactions between the client and server spends in transmission through the network (or time on the wire). Network Time is actually comprised of two components: the time it takes a client to send a request and the time it takes the server to send a response. Therefore Network Time = Trequest + Tresponse
Trequest:
Because AR makes all its measurements from the client`s perspective it is impossible for AR use time T5. Alternatively AR could use T5` as a reasonable approximation of the end of the client request. The problem with using T5` is that the TCP specification (RFC-1122) allows the server to delay sending an ACK to a client request for up to 500 mSec, this would artificially inflate network time if a delayed ACK occurs. Therefore AR approximates Trequest time as the time between that the first client request was sent and the time the last client request was sent plus the one-way trip time.
Trequest = T4 - T2 + delayCS
Where delayCS (delay client to server) represents an estimate of the one-way trip time of request packet n from the client to the server using SYN-ACK as an approximation.
Tresponse:
Again because AR makes all its measurements from the client`s perspective it is impossible for AR to use time T6. Therefore AR approximates Tresponse time as the time the client receives the first packet of the server response to the time that the client receives the last packet of the server response plus the one-way trip time.
Tresponse = T9 - T7 + delaySC
Where delaySC (delay server to client) represents the one-way delay of response packet 1 from the server to the client using SYN-ACK as an approximation. Based on the above, Network Time = Trequest + Tresponse
Server time - Server Time is the amount of time it takes a transaction to be processed by the business logic on the Application Server. Server time is calculated by subtracting network time from remote time.
Server Time = Remote Time - Network Time.
In a Thin Client Terminal Services environment, the AR Agent resides on the terminal server, not the client machine. Application Response breaks down the end-to-end response time for standard and custom transactions for Terminal Services applications into the following components:
Client Think Time - In a Terminal Services environment there is no monitoring agent on the client machine, so the amount of time between a frame arriving and a screen being painted on the client cannot be measured. However, because Terminal Server Client software is generally very efficient, it is safe to assume that these delays will be very small. The AR Agent attributes the periods of time between machine actions and client actions to Client Think Time. This is calculated the same way in a non-Terminal Services environment.
Client Processing Time - This is time spent by the Terminal server, processing the commands of the application which is being served. This is the work that has been offloaded from the client to the Terminal Server, through the use of terminal server software.
Network Time - Network Time represents the sum of the following:
* Client to terminal server - Traffic between terminal server and the thin client consists of packets sent asynchronously, so only unidirectional terminal-server-to-thin-client latencies are used. This time component is calculated in the same way as the client-system-to-server network time, with the terminal server in the role of "client" and the thin client in the role of "server." The term is nonzero only for transactions that require screen updates. A running average of terminal-server-to-thin-client latencies is kept for each client session and the Network Time component is the average of the last several network times, up to a maximum of ten.
* Terminal server to Application server - The amount of time the interactions between the terminal server and server spend in transmission through the network, calculated in the same fashion as Network Time, described above, with the terminal server in the role of "client system"
At specified intervals, the AR Agent calculates an average transaction response time for each instance of an application and pushes this data to the eHealth database where it is stored.
Data stored in the eHealth database can be accessed through the eHealth Console where it can be used to generate a wide variety of reports.
AR Agents calculate and transmit response time averages, rather than detailed data, to ensure that the reporting process does not have an adverse affect on network performance. The complete detailed data may be retained at the client and can be retrieved using the Application Response Agent Transaction Viewer which is available through the eHealth console. This allows users to drill down into response time data on a transaction-by-transaction basis when necessary.
Share
Editorial contacts