8.1 Preparation for measurement and configuration

< Day Day Up >

Before measuring the real-time performance of any e-business application, it is very import to consider whether or not a business transaction is a candidate for being monitored, and carefully decide which data to gather. Depending on what data is of interest (User Experienced Time, Execution Time of a specific subtransaction, or total Back End Service Time are but a few examples), you will have to select monitoring tools and configure monitoring policies according to your requirements. In addition, factors related to the nature and implementation of the e-business application and your local procedures and policies may prevent you from being able to use playback monitoring tools such as Synthetic Transaction Investigator or Rational Robot (Generic Windows) because of the fact that they will generate (what to the application system seems to be) real business transactions, for example, purchases. In case you cannot back out of or cancel the transactions originating from the monitoring tool, you might want to refrain from using STI or GenWin for monitoring these transactions.

Several factors affect the decision of what to monitor, how to monitor, and from where to monitor. Some of these are:

Use of naming standards for all TMTP policies

To be able to clearly identify the scope and purpose of a TMTP monitoring policy, it is suggested that a standard for naming policies be developed prior to deploying TMTP in your production environment.
Including network related issues in you monitoring data

If you want to simulate a particular business transaction executed from specific locations in order to include network latency in your monitoring, you will have to plan for playing back the transaction from both the corporate net (intranet) and Internet in order to be able to compare end-user experienced time from two different locations. This may help you determine inexpedient routing in your network infrastructure.

This technique may also be used to verify transaction availability from remote locations.
Trace levels for J2EE and ARM data collection

Depending on your level of tracing, you might incur some additional overhead (up to as much as 5%) during application execution.

Please remember that only instances of transactions that are included in the scope of the filtering defined for a monitoring policy will incur this overhead. All other occurrences of the transaction will perform normally.
Back-out updates performed by simulated transactions

If Synthetic Transaction Investigator or Generic Windows is used to playback a business transaction that updates a production database with, for example, purchase orders, you might need an option to cancel or back out of the playback user's business transaction records from the database.

8.1.1 Naming standards for TMTP policies

Before creating any policies, a standard for naming discovery and listening policies should be developed. This will make it easier and more convenient for users to recognize different policies according to customer name, business application, scope of monitored transactions, and type of policy. Developing and adhering to a naming standard will especially help in distinguishing different policies and creating different type of real-time and historical reports from Tivoli Enterprise Date Warehouse.

One suggestion that may be used to name TMTP policies is:

 <customer>_<application>_<type-of-monitoring>_<type-of-policy>

Using a customer name of telia, and application name of trade, the following examples would clearly convey the scope and type of different policies:

 telia_trade_qos_lis telia_trade_qos_dis telia_trade_j2ee_dis telia_trade_j2ee_lis telia_trade_sti_forever

The discovery component of IBM Tivoli Monitoring for Transaction Performance enables you to identify incoming Web transactions that need monitoring. When you use the discovery process, you create a discovery policy in which you define the scope of the Web environment you want to investigate (monitor for incoming transactions). The discovery policy then samples transaction activity and produces a list of all URI requests, with average response times, that have occurred during the discovery period.

You can now consult the list of discovered URIs to identify transactions to monitor in detail using specific listening policies, which monitor incoming Web requests and collect detailed performance data in accordance with the specifications defined in the listening policy.

Defining the listening policy is the responsibility of the TMTP user or administrator responsible for a particular application area.

8.1.2 Choosing the right measurement component(s)

IBM Tivoli Monitoring for Transaction Performance Version 5.2 provides four different measuring tools, each with different capabilities and providing data that measures specific properties of the e-business transaction. The four are:

Synthetic Transaction Investigator	Provides record and play-back capabilities for browser-based transactions. Works in conjunction with the J2EE monitoring component to provide detailed analysis for reference (pre-recorded) business transactions. STI is primarily used to verify availability and performance to ensure compliance with Service Level Objectives.
Quality of Service	Is primarily used to monitor real-time end-user transactions, and provides user-specific data, such as User Experience Time and Round Trip Time.
J2EE	Monitors the internals of the J2EE infrastructure server, such as WebSphere Application Server or Weblogic. Provides transaction and subtransaction data that may be used for performance, topology, and problem analysis.
Generic Windows	Provides similar functionality as STI; however, the Rational Robot implementation allows for recording and playback of any Windows based application (not specific to the Microsoft Internet Explorer browser), but does not provide the same detailed level of data regarding times for building the end-user browser-based dialogs.

These four components may be used alone or in conjunction. Using STI or Generic Windows to play back a pre-recorded transaction that targets a URI owned by the QoS endpoint and is routed to a Web Server monitored by a J2EE endpoint will basically provide all the performance data available for that specific instance of the transaction.

The following sections provide more details that will help decide which measurement tools to use in specific circumstances.

Synthetic Transaction Investigator

TMTP STI can be used as a synthetic transaction playback and investigator tool for any Web server, such as Apache, IBM HTTP server, Sun One (formerly known as iPlanet), and Microsoft Internet Information Server, and with J2EE applications hosted by WebSphere Application Server and BEA Weblogic application servers.

Synthetic Transaction Investigator is simple to use. It is easy to record synthetic transactions and uncomplicated to run transaction playback. Compared to Generic Windows, STI playback has more robust performance measurements, simpler content checking, better HTTP response code checking, and more thorough reporting. The most important advantage is the ability of STI to instrument a HTTP request with ARM calls, thus allowing for decomposing a STI transaction in the same way that transactions monitored by the Quality of Service and J2EE monitoring components are decomposed.

STI is the first-choice monitoring tool, partly because it provides transaction and subtransaction response time data.

Theoretically, it is possible to use 100 STI monitoring policies inside and 100 outside the corporate network simultaneously. STI runs all the jobs in a serial fashion, which is why you should avoid running an large number of transaction performance measurements from every STI. To avoid collision between playback policies and thus ensure that all transaction response measuring tasks completes successfully, it is recommended to limit the concurrent number of tasks at a single STI monitoring component to 25 within a five minute schedule. You should also consider changing the frequency for each run of the policies from five to 10 minutes, and distribute the starting times within a 10 minute interval.

Important:

The number of simultaneous playback policies you want to run depends on several factors, such as policy iteration time, the number of subtransactions in each business transaction, retry count, lap time, and timeouts.

In Version 5.2 of IBM Tivoli Monitoring for Transaction Performance the capabilities of STI have been greatly improved and now includes features like:

Enhanced URL matching
Multiple windows support
Enhanced meta-refresh handling
XML parser support
Enhanced JavaScript support

However, despite all of these enhancements, a few limitations still apply.

Limitations of Synthetic Transaction Investigator

When working with STI, you might encounter any of the following behaviors:

Multiple windows transactions

The recorder and player cannot track multiple windows.

Multiple JavaScript requests

The recorder and player cannot process JavaScript that updates the contents of two frames. When you click the Change frame source.... button, the newSrc()javaScript call executes function newSrc(). Example 8-1 illustrates this behavior.

The content of both the left and the right frame are updated, but STI only records the first URL navigation (the one to the left frame) of the two invoked by this JavaScript.

Example 8-1: JavaScript call

 {  parent.document.getElementById("myLeftFrame").src="/books/4/3/1/html/2/frame_dynamic.htm"    parent.document.getElementById("myRightFrame").src="/books/4/3/1/html/2/page2.html" }

Dynamic parameters	Certain parameters may be filled with randomly generated values at request time. For example, a HTML page containing a form element could fill at request time. A hidden input field value could be updated with a random value generated from JavaScript before the request is sent. The playback uses the result from the recorder JavaScript (it does not execute the JavaScript) when filling in the form data. This can cause incorrect data or the request to fail.
JavaScript alerts	Since the STI playback runs as a service without a user interface, the JavaScript alert cannot be answered and hangs the transaction.
Modal windows	Since the STI playback runs as a service without a user interface, the window cannot be acted upon and hangs the transaction.
Server side redirect	When a Web server redirects a page (server side redirect), a subtransaction may end prematurely and fail to process subsequent subtransactions. Usually, the server redirect occurs on the first subtransaction. To avoid this behavior, you may initiate the recording by navigating to the server side page to which STI was redirected.

In addition, you should be aware of the following:

Synthetic Transaction Investigator playback does not support more than one security certificate for each endpoint.
STI might not work with other applications using a Layered Service Provider (LSP).
STI cannot navigate to a redirected page if the Web browser running STI is configured through an authenticating HTTP proxy and a STI subtransaction is specified to a Web server redirected page. Generic Windows can be used to circumvent these problems.

Quality of Service

Quality of Service is used to provide real-time transaction performance measurements of a Web site. In addition, QoS provides metrics such as User Experienced Time, Back End Service Time, and Round Trip Time.

Note

QoS is the only measurement component of IBM Tivoli Monitoring for Transaction Performance Version 5.2 that records real-time user experience data.

Like STI, monitoring using QoS may be combined with J2EE monitoring to provide transaction breakdown and subtranaction response times for each transaction instance run through QoS. For details on how Quality of Service works, please see 3.3.1, "ARM" on page 67.

J2EE

The J2EE monitoring component is used to analyze real-time J2EE application server transaction performance and status information of:

Servlets
EJBs
RMIs
JDBC objects

J2EE monitoring collects instance level metric data at numerous locations along the transaction path. It uses JITI technology to seamless insert probes into the Java methods at class load time. These probes issue ARM calls where appropriate.

For practical monitoring, J2EE is often combines with one of the other monitoring components (typically STI or GenWin) in order to provide transaction performance measurements in a controlled environment. This technique is used to provide baselining and to verify compliance with Service Level Objectives for pre-recorded transactions. For real-time transactions, J2EE monitoring is primarily used for monitoring a limited number of critical subtransactions and may be activated on-the-fly to help in problem determination and identification of bottle-necks.

Details of the inner workings of the J2EE endpoint are provided in 3.3.2, "J2EE instrumentation" on page 72 and are depicted in Figure 3-8 on page 75.

Note

J2EE is the only IBM Tivoli Monitoring for Transaction Performance Version 5.2 monitoring component that is capable of monitoring the subtransaction response times within WebSphere Application Server and BEA Weblogic application servers.

Generic Windows

The Generic Windows recording and playback component in TMTP Version 5.2 is based on technology from Rational, which was acquired by IBM in 2003. Rational Robot's Generic Windows component is specially designed to measure performance and availability of Windows-based applications. Like STI, Generic Windows (GenWin) performs analysis on synthetic transactions. Like STI, GenWin can record and playback Web browser-based applications, but in addition, GenWin can record and playback any application that can run on a Windows platform, provided the application performs some kind of screen interaction.

For playing back a GenWin recorded transaction and recording the transaction times in the TMTP environment, the GenWin recording, which is saved as a VisualBasic script, has to be executed from a Management Agent, and ARM calls must be inserted manually into the script in order to provide the measurements. The advantage of this technology is that it is possible to measure and analyze the response time of specific infinitely small or large parts of an application, because the arm_start and arm_stop calls may be placed anywhere in the script. This is an excellent supplement to STI.

In addition, GenWin provides functions to monitor dynamic page strings, which is currently a limitation in the STI endpoint. For details, see "Limitations of Synthetic Transaction Investigator" on page 231.

For more details on the Generic Windows endpoint technology, please refer to 9.2, "Introducing GenWin" on page 365.

Limitations of Generic Windows

Before planning to use GenWin scripts for production purposes, you should be aware of the following limitations in the current implementation:

GenWin runs playback in a visual mode using an automated operator type of playback. One implication of this mode of operation is that the playback systems has to be dedicated to the playback task, and that a user has to be logged on while playback is taking place. If a user, local or remote, manipulates the mouse and/or keyboard while playback is running, the playback will be interrupted.
If delay times are not used with the recording script, the GenWin playback will fail to search the dynamic strings.
When a transaction is recorded by GenWin, the user IDs and passwords for e-business application site login are placed in the script file as a clear text. To avoid exposing passwords in the script, it may be stored encrypted in an file (external to the script) and passed into the script at execution time. Please refer to "Obfuscating embedded passwords in Rational Scripts" on page 464 for a description on how to use this function.
For GenWin recording and playback, you only need a single piece of Rational Robot software, in contrast to STI. Both recording and playback should not be run from the same Rational Robot, because a Playback policy might trigger playback of a prerecorded Generic Windows synthetic transaction while you are recording another transaction.

8.1.3 Measurement component selection summary

Table 8-1 summarizes the capabilities and suggested use of the four different measurement technologies available in IBM Tivoli Monitoring for Transaction Performance Version 5.2.

Table 8-1: Choosing monitoring components
Component	Operation	Advantage	Correlation with other components	Description
STI	Transaction simulation with subtransaction correlation	Simple to use	Can be combined with J2EE and QoS with correlation	Simulated end-user experience
GenWin	Transaction simulation	Can be used as a complement of STI and a Windows application	Can be combined with QoS and J2EE, but without any correlation	Simulated end-user experience
QoS	Real-time Page Rendering Time and Back End Service Time with correlation	First step to measure back-end application service for end-user transactions	Can be combined with STI and J2EE with correlation	Real-time end-user experience
J2EE	Transaction breakdown	Full breakdown analysis of business application (EJB, JavaServlet, Java Servlet pages, and JDBC)	Can be combined with STI and QoS with correlation	Application transaction response time and other metric data

For more details, please see 3.3, "Key technologies utilized by WTP" on page 67.

< Day Day Up >