IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments

Chapter 5. Optimizing performance within an IBM Tivoli Monitoring environment 183

򐂰 Use more efficient data manipulating functions, such as substring instead of

string scan. If you know the position of the string to search, do not scan the

whole string to check for the value.

Post-filters versus pre-filters

Performance will be improved for each view when you pre-filter the required view

information and only send to the portal client what is needed in that view. You

thereby reduce the amount of data sent through the network, and do not have to

post-process it either. However, there is one exception to the rule.

Think of a workspace that contains many views. Each of those views has a query

associated with it, which will be issued when the workspace is accessed. This

might result in many queries that have to be processed in parallel.

A better way of doing this might be to create one query that returns all data that is

required in the workspace. In this case, the query will only be issued once and

the data can then be post-filtered for each view to only display information as it

applies to each view.

One important consideration, however, is that queries are saved globally and are

not user ID-dependent. This means that only administrators will be able to modify

queries in most installations. For the end user to be able to modify filters, the

preferred method might be the filters applied in the view properties filters tab.

5.8.2 Defining custom queries

Custom queries reduce network traffic, processing at the agent and Tivoli

Enterprise Monitoring Server, and memory usage at the Tivoli Enterprise Portal

Server and Tivoli Enterprise Portal client. Custom queries accomplish this by

limiting the number of rows and columns passed from the Tivoli Enterprise

Monitoring Agent to the Tivoli Enterprise Monitoring Server.

Most of the predefined, product-provided queries request all columns and all

rows of an attribute group, of which only a few may be of interest to you.

Removing the unwanted columns (attributes) will reduce the amount of data

transferred from monitoring agent to Tivoli Enterprise Monitoring client via the

portal server, hub monitoring server and remote monitoring server. Additionally,

in the case of OMEGAMON monitoring agents that reside on z/OS, you will also

reduce the amount of EBCDIC/ASCII conversion required when data is passed

between mainframe and distributed platforms.

It is recommended that you tune any queries servicing workspaces that are

frequently executed or return large quantities of data. Query execution always

requires resources, and intermittent extremely large reports will cause a spike in

memory requirements and network resources.

184 IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments

򐂰 Restricting the number of rows

Most predefined queries return

all rows and columns. You can create a

custom query to filter out the irrelevant or uninteresting metrics. Not only does

this make it easier to read the report, but it saves Tivoli Enterprise Portal

Server memory, client memory, and CPU because there are fewer rows to

translate, sort, and transmit.

You may be using view filters inappropriately. View filters work only on the

current page returned from the query. For example, if page size is 100 lines

and the filter reduces it to five lines on page 1 and similarly on subsequent

pages, the row set cannot be seen on one page. Do not increase the

workspace page size to see everything on one page. Increased page size

actually increases Tivoli Enterprise Portal client memory requirements.

Instead, avoid this condition by creating a custom query that filters the data at

query execution time.

򐂰 Restricting the number of columns

Most predefined queries return

all columns (or attributes). A particular

attribute group may contain 50 columns, yet all you need is five. Creating a

custom query to retrieve just the desired five attributes will reduce Tivoli

Enterprise Portal Server and client CPU and memory.

For example, the OMEGAMON XE for z/OS product-provided

DASD_MVS_Devices query returns 32 columns for approximately 5,100 rows

of data in the ITSO environment. Many of the default columns and many of

the rows of data may not be of interest so we made a copy of the query and

modified the specification.

The modified version of the query, as shown in Figure 5-10 on page 185,

removes unwanted columns and selects only devices with an I/O rate greater

than zero and contains only 17 columns and 20 rows of data, which is a

drastically smaller amount of data.