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.

Get IBM Tivoli Monitoring: Implementation and Performance Optimization for Large Scale Environments now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.