Chapter 7. Performance optimization 295
7.4.3 A simple scenario for this book
As part of this book, wee run some simple tests to verify how modifying some of
the configuration parameters can change the performance of the Tivoli Dynamic
Workload Broker server. The environment we used is the following:
򐂰 Server: Windows 2003, 4 GB RAM
򐂰 Five Agents: three agents Windows, two agents Linux
Increasing this number can improve the performances but can
cause the agent to discover changes on the network system with
delay. It is advisable to not set this parameter with a too low value.
Setting this value to true means that all the scans are performed at
each NotifyToResourceAdvisorIntervalSecs interval time, just
before sending the notification to the Resource Advisor. All the
previous scanning interval parameters will be ignored.
On a slow network, it is advisable to set this parameter to a higher
value. The value defined in this parameter should be consistent
with the RaaHeartBeatInterval parameter defined in the file on the IBM Tivoli Dynamic
Workload Broker server, which defines the time interval within
which the Resource Advisor expects a heartbeat signal from the
It is recommended to decrease this number if the agent is running
on a slow system to limit consumption of resources. Anyway, if the
value is too low, an higher number of jobs can remain in to a
SUBMITTED state causing an higher number of allocated
resources that fill the cache on the Resource Advisor, decreasing
performance on server.
Increasing this value might slightly increase network traffic, but this
is suggested if the IBM Tivoli Dynamic Workload Broker server
runs into a cluster environment. If, for any reason, primary server
can not be reached by the agents, an higher value for this
parameter allows to the backup server to be notified on jobs’ status
if it become available in a time shorter then notifier.maxretries *
notifier.retryinterval (default is 8 hours). If this time interval is
exceeded, the jobs will remain in RUNNING state, up the agents
are not restarted.
Increasing this value might slow the updating of information on the
server but the same considerations for notifier.maretries are valid
also for this parameter.
296 Getting Started with Tivoli Dynamic Workload Broker Version 1.1
Three jobs were defined, one running only on Windows platforms, one on Linux
and one on AIX.
Jobs have been submitted continuously for 5 minutes (at a rate of about 100 jobs
per minute) through the command-line interface. After the 5 minutes of jobs’
submission, Resource Advisor continued to work for matching resources for the
AIX job, which was still in the WAITING FOR ALLOCATION status.
The percentage of the CPU utilization by the java process running the
WebSphere application Server has been measured.
The following parameters on the Resource Advisor have been changed:
򐂰 TimeSlotLenght (default 15 sec, 1 sec, 600 sec)
򐂰 MaxWaitingTime (default 600 sec, 0 sec, 70 sec)
򐂰 CheckInterval (default 60 sec, 1 sec, 200 sec)
Figure 7-1 shows the results for the scenario that tests the TimeSlotLenght.
Figure 7-1 Test on TimeSlotLength
When we set a very high value for the TimeSlotChange (for example, 600 sec),
we experienced how CPU utilization is effected during the first part of the test,
the first 5 minutes, during the jobs’ submission. The CPU utilization went down
from about 35% (default value) to about %15. This is because a very high value
for the TimeSlotChange causes the Resource Advisor that performs the resource
matching and allocate resources, not to work for longer periods. The CPU was so

Get Getting Started with Tivoli Dynamic Workload Broker Version 1.1 now with O’Reilly online learning.

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