1 Chapter 1: Introduction: Application Performance Management 201

Application Performance Management 201
Chapter 1: Introduction
1.1 What is APM?

APM stands for Application Performance Management. It is a software
application which monitors the performance of the web applications being hosted on the
web server.
1.2 Need for APM:

In present scenario we have got lots of service providers who provide various
services like banking (ICICI, HDFC…), online reservations (Yatra, MakemyTrip…),
search engines (Google, Yahoo…) etc. So to be in the competition one should have an
application which runs remarkably with less downtime and drags number of clients
towards it.
But in real world achieving zero downtime is quite impossible; even though the
application is simple one might experience other factors influencing the proper
functioning of the application. To know what factors are influencing the application CA
Technologies have come up with a software tool called APM which helps the service
providers to monitor their applications and take necessary steps.
The scenario for a web application being hosted can be depicted from the fig 1.1.
It shows how exactly the things go on with the web applications.
As we can see the following are the steps involved in using a particular service on
the internet.
1. The client sends an http request to the web server from a browser for a
particular service (for example login into Google apps).
2. The server receives the request and sends to the particular domain (here
mlrinstitutions.ac.in).
3. The domain server sends the next action that is to be taken by the web server.
MLR Institute of Technology 1|Page
1
4. Now the web server interacts with the database for the data.
5. The Database server serves the request and sends the data to the web server.
6. Finally the web server sends the response back to the client.
Figure 1.1: Typical Web Scenario
One might wonder then where is the use of APM in this scenario. But let us recall few
things as described below.
1. We know that for a website to open and process the request it needs some time, but
can anyone guarantee the amount of time it will take to do so.

1
2. Of course it depends on various factors like speed of the internet, traffic, speed of the
server and complexity of the application and few more factors.
3. The above mentioned factors can be handled easily, but what if some other factors are
influencing the application. The problem could be server side like class doesn’t get
loaded properly; some unwanted code is running in a loop etc. All these lead to loss in
business from the service provider perspective.
To overcome the above problem we need to have something which could monitor
the applications running on a server. Since applications are a piece of software, the
something we require to monitor must also be software and here comes the APM.
APM monitors the applications hosted on the web server and sends the metrics to
the developers regarding the place where exactly the problem has arisen. These metrics
helps the developers to diagnose the problem.
1.3 Inside the APM:

APM is an integration of two tools namely Introscope and Customer Experience
Manager (CEM).
Figure 1.2: Logical grouping of APM

Both Introscope as well as CEM can be run independently and has got their own
importance for managing the performance of the applications. The logical grouping of
APM is as shown in the figure 1.2.
1
We will discuss about Introscope and CEM individually in coming chapters.
.
.
Chapter 2: Introscope

1
2.1 Architecture:
Introscope is a software tool which monitors any defect in the implementation
classes, methods or interfaces. It deals with the run time behavior of the code, providing
highly dynamic environment to monitor the web application.
Introscope is a combination of Enterprise Manager (EM), Agent, WorkStation

(WS) and a Database as shown in the figure 2.1.
Figure 2.1: Introscope Architecture.
2.1.1 Agent:

1
An agent is a piece of software which is bind to the web application which is to be

monitored to collect the metrics from the application and send it to the Enterprise
Manager.
2.1.2 Enterprise Manager:
Enterprise Manager is software running on the console which takes the metrics
from one or more agents, aggregates them and stores them in the database.
2.1.3 Work Station:
A Work Station is a UI based application at the developer end which gets the
metrics stored in the database to track the problem.
2.2 Working of Introscope:

The Introscope scope works in four phases, namely
1. Binding of the Agent to web application.
2. Reporting the metrics to Enterprise Manager.
3. Aggregation and storing of the metrics at Enterprise Manager.
4. Viewing of metrics at the Work Station.
Let us see each of these phases in detail.
2.2.1 Binding of the Agent to web application:

1
To monitor any web application, we need to bind an agent with the web
application that is to be monitored. The binding of web application with the agent deals
with the insertion of byte code into the implementation classes byte code of the
application.
For example if we want to monitor a method of a class, then we write a .pbd file
known as Probe Builder Directive which states that which method of which class is to be
monitored.
Using this .pbd file the agent software inserts some byte code at the start and the
end of the method body for the method which is to be monitored. The insertion of this
byte code into the actual byte code is known as probing, and the inserted byte code is
called as probes. The class or method in which the probes are added is called as
instrumented class/method.
The following figure shows binding of agent with the implementation classes.
Figure 2.2: Binding Agent to the Application.

1
Once the probes are inserted into the byte code of the implementation
classes/methods, we can say the binding of agent to the application is done and the agent
is ready to report the metrics to the Enterprise Manager (EM).
As we can see from the figure, the byte code is added at the start and a t the end of
the method body. And this code acts as the agent to send the metrics to the EM.
2.2.2 Reporting of metrics to Enterprise Manager:
Before we see how the Agent reports metrics to the EM, we see what is a metric
and types of it.
2.2.2.1 Metrics:
A Metric is a measurement of application performance. The types of metrics are:
S. No Metric Purpose
1 Bandwidth JVM and CLR-level file and socket activity.
2 Concurrency Number of method invocations started but not yet finished.
3 Count Number of method invocations to date.
4 Exception Captures exceptions.
5 Memory Memory allocated to the JVM or CLR in use, as related to

garbage collection.
6 Rate Number of method executions per second or time interval.
7 Response time Average method execution time in milliseconds.
8 Stalled methods Number of methods started but whose invocation times have
exceeded a threshold.
9 System logs Monitors system out and system error output.
10 Threads Number of instrumented threads.
The above metrics are used by the developer to reach to the problem and solve
them before it affects a large number of customers.
1
Once the agent binding is done with the web application, the next step is to report
the above metrics to the EM. This reporting is done by the agent.
Whenever the application is running the agent becomes active and it sends the
above metrics for the class/method with which the agent is bind, to the Enterprise
Manager. This reporting is done at the runtime only, so that we get the performance of
the application in run time with the real time end user.
Once the agent reports the metrics to the EM, the task of the agent is finished.
Now the Enterprise Manager comes into action.
2.2.3 Aggregation and storing of metrics at Enterprise Manager:
Once the Enterprise Manager receives the metrics from the agent, it periodically
aggregates the metrics and stores in the database.
The EM aggregates for every 15 minutes by default, this value can be changed by
the administrator of the EM for more flexibility.
The Enterprise Manager has the capability of receiving the metrics from more
than one agent.
2.2.4 Viewing of metrics at the work station:
The metrics stored in the above phase by the EM in the database can be viewed by
the developer at the Work Station window.
The Work Station is an UI window which provides all the metrics in the graphical
notation to the developer. The use of graphical notation for the representation of metrics
provides the developer with an ease of understanding the problem.
The Work Stations browser window looks this way.

1
Figure 2.3: WorkStation Browser - hierarchy view.
As we can see from the figure the part which is encircled in red shows the metrics
reported by the agent to the EM. These metrics are generated when the application
“hello_jsp” was run.
MLR Institute of Technology 10 | P a g e

1
If we click on the “hello_jsp” tab in the above window we get the graphical
notation of these metrics as shown in the below figure.
Figure 2.4: Graphical notation of metrics.
The Phases can be grouped as shown in the figure below.

1
Figure 2.5: Phases in Introscope.
2.3 Security and overhead:

Even though the Introscope adds byte code to the implementation classes/method
it doesn’t affects the security of the application and highly transparent to the end user.
Moreover the overhead of the probes in the source code is very less, that it doesn’t
affect even the efficiency of the application.
.
.
Chapter 3: Customer Experience Manager (CEM)

1
3.1 Introduction:
Customer Experience Manager (CEM) is yet another software module in
Application Performance Management.
CEM deals with the management of application performance from a level higher
than Introscope. Unlike Introscope it doesn’t works with the source code, rather monitors
the entire web server as a whole. As the name implies it manages the customer
experience in true sense.
In general it watches which customer faces problem by which application. CEM

is built up of two tools namely TESS (Transaction Events and Statistics Server) and TIM
(Transaction Impact Monitor).
3.2 Architecture of CEM:

The architecture of CEM is as shown in the figure below.
Figure 3.1: Architecture of CEM
3.3 Working of CEM:

1
The working of CEM refers to working of TIM and TESS. To understand the
working of TIM and TESS, first we see what are TIM and TESS, and then we will go for
their functionalities.
3.4 Transaction Impact Monitor (TIM):

TIM is a Linux box which runs the TIM services, like sniffing the transaction
packets from the network port, matching them with the pre defined conditions and storing
them in a file.
A TIM is located inside the customer’s network and is configured to sniff a

particular port; this port is usually SPAN port of a network switch. The switch mirrors the
entire data onto this SPAN port that passes through the switch. Now the data at this port
is being pulled by the TIM monitor and is filtered based on the conditions specified by
the administrator as defects or not a defect. The defects are stored in a file and the rest all
transactions are dropped.
The analysis that a particular transaction is defect or not is done by the SLA’s
(Service Level Agreements) specified by the developer. The transactions are compared
against these SLA’s and the defective transactions are saved in a file at TIM. These files
are again pulled up by the TESS to store in the database as well as to be made available
to the developer through the TESS UI.
The TIM generates a new file of defects for every 7.5 seconds and these files are
destroyed once been copied by the TESS.
The configuration of TIM is done by the CEM administrator from the TESS UI
itself. One need not move to the TIM box to specify the types of transactions, SLA’s,
recordings etc.

1
The pictorial representation of connection of a TIM with switch is as shown

below.
Figure 3.2: Connecting TIM to Monitor SPAN port.
As we can see in the figure the TIM monitors all the transactions that are moving
between the switch and the load balancer.
In a typical environment where the traffic is very high, one can have more than
one TIM to monitor the same port. In addition to that one TIM can report to only one
TESS at a time but one TESS can be connected to multiple TIM’s.
3.5 Transaction Events and Statistics Server (TESS):

1
The TESS is integrated inside the Introscope Enterprise Manger (EM). Whenever
the EM is started, it also starts the TESS.
The TESS provides various services like TIM collection service, Database
cleanup and Stats aggregation.
To utilize the services of a TESS, the developer or the TESS administrator at the
customer side must login to the TESS UI and follow the following steps for TIM
collection service.
3.6 Procedure for TIM collection service:

The following are the steps to be performed by the developer to utilize TIM
collection service.
3.6.1 Specify the TIM machine:
The developer must login into the TESS UI using his/her credentials. Once logged
in they can specify the TIM machine name and IP address from which they want to
receive the defects file.
The example figure shows the UI to specify the TIM machine as below.
Figure 3.3: Specifying TIM machine.
3.6.2 Record Transaction:

1
Now a recording of transactions must be done through recording tab, which lists
all the transactions present at the SPAN port related to the particular application.
The recording module records all the transaction that occurs for the application
being monitored.
Figure 3.4: Record Transaction window.
Specify the client IP address and click on record it will start recording all the
transaction from that IP address.
3.6.3 Identify the Transaction:
Now from all the transaction recorded above the developer has to select the
transactions which he/she want to monitor.
For example if we record the transaction for the www.mlrinstitutions.ac.in, it lists

all the sub transactions that takes place to load this page from the server to client side.
The transaction could be image loading, getting the script file, getting the text etc related
to that particular page.

1
Now if we want to monitor that how much time doe it takes to get the particular
image in that page, we select that transaction in this step.
Figure 3.5: Identifying Transaction window.
The above shows the list of all transactions recorded, the developer can select or
identify the transactions which he wants to monitor by checking the appropriate
transaction.
3.6.4 Promote Transaction:
After selecting the transactions that are to be monitored, the developer has to
promote the transaction, this can be done by clicking the promote button in the same tab
as shown below.

1
Figure 3.6: Promoting Transaction window.
3.6.5 Set the SLA’s:
Now as we have identified the transaction to be monitored, we specify the SLA’s

for this transaction. The SLA’s could be like the minimum time to get the image from the
server onto the client browser for example 5 seconds.
Figure 3.7: Setting SLA’s window.

1
3.6.6 Synchronize the monitors:
Since these rules are set at the TESS UI, we need to send an xml file to the TIM
as well stating the above conditions so that it can filter the transactions against the
conditions in this file. Any transaction which fails to satisfy the minimum conditions is
considered to be defect and stored in a defect file as discussed earlier.
The synchronization of the monitors can be done just on click of button labeled
synchronize all monitors. Once the synchronization is done the TIM is configured to
report the defects and even TESS is ready to collect the defects file from TIM.
Figure 3.8: State before and after the synchronization.
3.7 Watching the defects at TESS:

1
To watch the defects which are generated by the TIM whenever a client request a
particular application which we are monitoring, we go to the TESS UI, under cem tab we
find incidents under which we get a tab for defects.
On clicking the defects tab, all the defects get listed which have been captured by
TIM as shown below.
Figure 3.9: Defects window.

1
As one can see the defects are listed in a tabular format with all the information
related to the defect. One of the defects we captured can be seen as marked with a red
rectangle in the figure 3.9.
.
.

1
Chapter 4: Scope and Conclusion
4.1 Scope of APM:

The scope of APM is not restricted to only particular applications. Till the
application makes use of the http protocol for request and response, the APM can monitor
it. Hence extending its services to variety of business applications.
The UI are so simple that any naive user can understand the application and make
use of it. On the other hand it provides sensible information which a developer can use to
rectify the problem in the application being monitor. Hence the scope for users lies from
Naïve to high end developers.
4.2 Future Enhancement:

The product is being modeled in such a way that the TESS UI and Work Station
can be accessed even from a mobile device to from more flexibility with the product.
4.3 Conclusion:
The APM provides a large number of functionalities for the service providers to
manage their applications and to come up to the solution without affecting the users at
large.
Both the products under APM are of high use from the business point of view to
monitor the applications at two different locations. One at the implementation level using
Introscope and the other at network level using the CEM.
.
.

1
Appendix A: List of figures
S. No Name of the figure Page No.

1 1.1 Typical web scenario 2
2 1.2 Logical grouping of APM 3
3 2.1 Introscope Architecture 5
4 2.2 Binding Agent to the application 7
5 2.3 Work Station browser- hierarchy view 10
6 2.4 Graphical notation of metrics 11
7 2.5 Phases in Introscope 12
8 3.1 Architecture of CEM 13
9 3.2 Connecting TIM to monitor SPAN port 15
10 3.3 Specifying TIM machine 16
11 3.4 Record transaction window 17
12 3.5 Identifying transaction window 18
13 3.6 Promoting transaction window 19
14 3.7 Setting SLA’s window 19
15 3.8 State before and after the synchronization 20
16 3.9 Defects window 21

1
References
1. Wily Introscope guide from CA Technologies.
2. Wily CEM guide from CA Technologies.
3. Technical report on G- Gears.

1
INDEX

1
Specifying TIM machine, 16

Storing Metrics, 9
Synchronize monitors, 20
Security and overhead, 12
T
TESS, 16
TIM, 14
Connection, 15
Collection Service, 16
Transaction
Identifying, 17-18
Promoting, 18-19
Recording, 17
Types of metrics, 8
V
Viewing of metrics, 9
W
What is APM? , 1
Working
CEM, 14
Introscope, 6-12
Work Station, 5-6, 10-11

1 Chapter 1: Introduction: Application Performance Management 201

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

1 Chapter 1: Introduction: Application Performance Management 201

Hochgeladen von

Copyright:

Verfügbare Formate

Application Performance Management 201

1.1 What is APM?

1.2 Need for APM:

Figure 1.1: Typical Web Scenario

MLR Institute of Technology 2|Page

1.3 Inside the APM:

Figure 1.2: Logical grouping of APM

We will discuss about Introscope and CEM individually in coming chapters.

MLR Institute of Technology 4|Page

Introscope is a combination of Enterprise Manager (EM), Agent, WorkStation

Figure 2.1: Introscope Architecture.

MLR Institute of Technology 5|Page

An agent is a piece of software which is bind to the web application which is to be

2.1.2 Enterprise Manager:

2.1.3 Work Station:

2.2 Working of Introscope:

1. Binding of the Agent to web application.

2. Reporting the metrics to Enterprise Manager.

3. Aggregation and storing of the metrics at Enterprise Manager.

4. Viewing of metrics at the Work Station.

Let us see each of these phases in detail.

2.2.1 Binding of the Agent to web application:

MLR Institute of Technology 6|Page

Figure 2.2: Binding Agent to the Application.

MLR Institute of Technology 7|Page

2.2.2 Reporting of metrics to Enterprise Manager:

A Metric is a measurement of application performance. The types of metrics are:

1 Bandwidth JVM and CLR-level file and socket activity.

2 Concurrency Number of method invocations started but not yet finished.

3 Count Number of method invocations to date.

4 Exception Captures exceptions.

5 Memory Memory allocated to the JVM or CLR in use, as related to

6 Rate Number of method executions per second or time interval.

7 Response time Average method execution time in milliseconds.

9 System logs Monitors system out and system error output.

10 Threads Number of instrumented threads.

2.2.3 Aggregation and storing of metrics at Enterprise Manager:

2.2.4 Viewing of metrics at the work station:

The Work Stations browser window looks this way.

MLR Institute of Technology 9|Page

Figure 2.3: WorkStation Browser - hierarchy view.

MLR Institute of Technology 10 | P a g e

Figure 2.4: Graphical notation of metrics.

The Phases can be grouped as shown in the figure below.

MLR Institute of Technology 11 | P a g e

Figure 2.5: Phases in Introscope.

2.3 Security and overhead:

Chapter 3: Customer Experience Manager (CEM)

MLR Institute of Technology 12 | P a g e

In general it watches which customer faces problem by which application. CEM

3.2 Architecture of CEM:

Figure 3.1: Architecture of CEM

3.3 Working of CEM:

MLR Institute of Technology 13 | P a g e

3.4 Transaction Impact Monitor (TIM):

A TIM is located inside the customer’s network and is configured to sniff a

MLR Institute of Technology 14 | P a g e

The pictorial representation of connection of a TIM with switch is as shown

Figure 3.2: Connecting TIM to Monitor SPAN port.

3.5 Transaction Events and Statistics Server (TESS):

3.6 Procedure for TIM collection service:

3.6.1 Specify the TIM machine: