Configure WebSphere Business Monitor for high throughput and performance

Tuning guidelines and best practices

Learn best practices for architecture, implementation, and tuning parameters of IBM® WebSphere® Business Monitor components. This article contains tuning guidelines for Monitor components having the most impact on performance, based on benchmark tests, and includes event processing and dashboard server tuning.

Torsten Wilms (twilms@de.ibm.com), Advisory IT Specialist, IBM

Torsten Wilms photoTorsten Wilms is an Advisory IT Specialist in the Software Services for WebSphere Worldwide Technology Practice Team in Boeblingen, Germany. Torsten helps IBM customers develop and deploy business integration solutions based on the WebSphere platform. He has co-authored various technical publications for IBM and speaks regularly at technical conferences worldwide.



19 September 2009

Also available in Chinese

Introduction

This article provides performance tuning guidelines for IBM WebSphere Business Monitor V6.1 (hereafter referred to as Monitor). It discusses best practices for development and configuration, and describes tuning parameters for Monitor components that have the most impact on throughput and response times based on performance benchmark measurements. It is intended for WebSphere consultants, IT Specialists, and IT Architects who have a good understanding of Monitor.

Figure 1 shows the various components in a Monitor environment. This article covers each component of the diagram as follows:

  • Implementing models for performance in WebSphere Integration Developer
  • Modeling best practices for implementing a Monitor Model in the Monitor Toolkit
  • Tuning the Common Event Infrastructure (CEI)
  • Tuning Monitor
  • Tuning the Monitor database
  • Tuning the dashboard
Figure 1. The Monitor environment
Monitor

Implementing models for performance in WebSphere Integration Developer

Monitor receives Common Base Events (events) from the Common Event Infrastructure (CEI) using Java Message Service (JMS) destinations. From a performance point of view, this means that the JMS messages are serialized and deserialized, which is CPU-intensive. Also, JMS messages are persisted on the message engine’s database. Figure 2 shows a typical event flow in a Monitor environment.

Figure 2. Monitor event flow
Monitor event flow

To avoid unnecessary CPU and I/O costs, you should limit the number of events by turning on Integration Developer event emission only when truly necessary for business activity monitoring.

Modeling for performance

This section focuses on how to improve performance when modeling with the Monitor Toolkit.

Figure 3. Modeling for performance
Modeling for performance

Recurring wait-time triggers

In the Monitor Toolkit, you can set a recurring wait-time trigger in the monitor model, as shown in Figure 4. Recurring wait-time triggers are evaluated periodically. The value of a recurring wait-time trigger defines the time interval for evaluation of the trigger. The value of the recurring wait-time trigger depends on your application design. However, for optimal performance, you should set the value of recurring wait-time triggers to the longest possible interval, because short intervals mean lots of evaluations in a short time, resulting in high CPU utilization of the Monitor server.

Figure 4. Recurring wait time
Recurring wait time

Deliver to all instances

Deliver to all instances, shown in Figure 5, is an inbound event-delivery option for multiple correlation matches. If you select this option (the default isTreat as error), you need to be careful when you have many active instances and one event could correlate to a high percentage of the instances. For example, let's assume you have one million active instances. An event that correlates to all of them, arriving once every 10 seconds, would result in over 100,000 event deliveries per second, which in turn results in high CPU utilization of the Monitor server.

Figure 5. Deliver to all instances
Deliver to all instances

Tuning the CEI

Monitor consumes Common Base Events delivered by the CEI. Tuning the CEI is therefore an important factor for Monitor performance improvements. This section describes how you can configure event group profiles and minimize unnecessary processing for better performance.

Figure 6. CEI tuning
CEI tuning

CEI Event Group profile

Each monitor model has one Event Group profile deployed on the Common Base Infrastructure (CBI) server. By default, the Event Group profile has an event selector string with the value CommonBaseEvent[true()]. Figure 7 shows the Event Group for the default wbm_GlobalHTMM monitor model.

Figure 7. The Event selector string
Event selector

An event arriving at the CEI is sent to each Event Group for which the corresponding event selector string evaluates to true. In the case where n monitor models have the event selector string set to true, an event will be sent n times. To avoid having each event sent to all monitor models, use a more specific event selector string.

The default selector shown here forwards all the events submitted by all event producers from the CBI the monitor model:

CommonBaseEvent[true()]

However, the following selector forwards only the events submitted by a Business Process Execution Language (BPEL) process with a template called myBusinessProcess:

CommonBaseEvent[(extendedDataElements[@name = 
                        'processTemplateName']/values = 'myBusinessProcess')]

To edit the event selector string of an event group in the Integrated Solutions Console, do the following:

  1. Select Service Integration => Common Event Infrastructure => Event Services.
  2. Select Default Common Event Infrastructure event server.
  3. Select Event Groups.
  4. Select the Event Group you want to modify.
  5. Change the value of the Event Selector String field.
  6. Click OK, then Save.

The All events event group

By default the All events event group is created during the CBI installation. This event group distributes all events to a default JMS destination. This distribution of events is not necessary for Business Monitor, so you should remove it to avoid this additional distribution.

To remove the All events event group in the Integrated Solutions Console, do the following:

  1. Select Service Integration => Common Event Infrastructure => Event Services.
  2. Select Default Common Event Infrastructure event server.
  3. Select Event Groups.
  4. Select All events, as shown in Figure 8.
  5. Click Delete.
  6. Click OK, then Save.
Figure 8. The All events event group
All events group

Disabling CBI event validation

By default, the CBI validates the semantics of a event, but this event validation is CPU-intensive and should only be used if absolutely necessary. If you're using WebSphere Process Server or another trusted Common Base Event emitter, this validation is unnecessary. To disable event validation, set a new custom property named validateEvent in the emitter profile. Give it a boolean value of false.

To add a validateEvent custom property in the Integrated Solutions Console, do the following:

  1. Select Service Integration => Common Event Infrastructure => Event emitter factories.
  2. Select Default Common Event Infrastructure event emitter.
  3. Select Custom Properties.
  4. Click New.
  5. In the Properties dialog, as shown in Figure 9, name the new custom property validateEvent, and specify a value of false.
  6. Select java.lang.Boolean as the Type.
  7. Click OK, then Save.
Figure 9. The validateEvent custom property
validateEvent property

Disabling the CBI event data store

By default the CBI distributes events to JMS destinations and to an event data store. Storing the events in the data store is an I/O-intensive operation, and is not required for Monitor. For improved performance, you should disable the use of the event data store. If necessary, you can turn it back on for debugging and testing purposes at any time.

To disable the event data store in the Integrated Solutions Console, do the following:

  1. Select Service Integration => Common Event Infrastructure => Event Services.
  2. Select Default Common Event Infrastructure event server.
  3. Uncheck Enable event data store, as shown in Figure 10.
  4. Click OK, then Save.
Figure 10. Disabling the event data store
Disable event data store

Tuning Monitor

This section discusses parameters for tuning the Monitor server.

Figure 11. The Monitor server
Monitor server

The important tuning parameters for the Monitor server are the message consumption batch size, the event processing batch size, and the recurring wait-time checking interval as shown in Figure 12.

Figure 12. Monitor server properties
Monitor server properties

Message consumption batch size

This message consumption batch size parameter defines the number of events a monitor model reads from the monitor model JMS input destination at a time, for a single transaction. The events are stored in JMS messages. When the JMS message is picked up from the monitor model, it gets de-serialized into the memory. De-serialization is a relatively CPU-intensive operation, so by default the message consumption batch size is set to 100. That means that each monitor model thread reads 100 JMS messages at a time. Depending on the number of incoming JMS messages, the batch size can be modified to increase the throughput. The trade-off is that, if one JMS message processing in the batch fails, the whole transaction is rolled back. If you observe the number of JMS messages in the JMS input destination growing, this indicates that Monitor is unable to process the incoming JMS messages fast enough. The reason could be that the message consumption batch size is too small.

To change the message consumption batch size, complete the following steps in the Integrated Solutions Console:

  1. Select Monitor Models.
  2. Select the version of the monitor model you want to edit.
  3. Click Change Runtime Configuration.
  4. In the Message Consumption section, as shown in Figure 13, specify a new value in the Batch size field.
  5. Click OK, then Save.
Figure 13. Message consumption batch size
Message consumption batch size

If you modify the message consumption batch size, also review the value of the work request queue size for the De-serialization Work Manager for each monitor model. The work request queue size parameter specifies the size of the work request queue, a buffer that holds scheduled work objects. Set the work request queue size to equal the message consumption batch size of a monitor model or leave it empty.

In the Integrated Solutions Console, complete the following steps to set the work request queue size:

  1. Select Resources => Asynchronous beans => Work managers.
  2. Select wbm_modelname_version_Deserializer, where modelname_version is the version of the monitor model you want to configure, as shown in Figure 14.
  3. In the Work request queue size field, enter the value that you specified for the message consumption batch size of that monitor model.
  4. Click OK, then Save.
Figure 14. Work request queue size
Work request queue size

Event processing batch size

After events from the queue are consumed, they are put into a holding area where they build a set of related events. Monitor waits for events to arrive for reordering. The latency is based on the Late arrival stand off delay parameter. The default latency is 10 seconds. Figure 15 shows a latency of five seconds.

Figure 15. Late arrival stand off delay
Late arrival stand-off delay

After the specified latency, events are dropped into a second holding area to build up a unit of work. The unit is considered ready for processing when either the "Last in stand off delay," "First in stand off delay," or "Event processing batch size" is reached, as shown in Figure 16.

  • First in time is calculated based on the time when the unit of work was created.
  • Last in time is calculated based on the time when the most recent event was added to a unit of work.
  • The event processing batch size is the number of events in the unit of work.
Figure 16. Event processing parameters
Event processing parameters

Once a unit is ready, it is processed. The maximum number of events processed per transaction is based on the event processing batch size. If not all the events in the unit can be processed in a single transaction, more transactions are used until the unit is empty. Note that if you set the stand off delays to very large values, you may end up waiting a very long time.

Recurring wait-time checking interval

This parameter tells the monitor model how often to interrupt to check whether it is time to evaluate whether any recurring wait-time triggers need to be fired. This parameter should be set based on the greatest common factor of your recurring wait-time triggers in your monitor model.

For example, if some triggers are defined to evaluate every 10 minutes, and others are defined to evaluate every 15 minutes, you would want to choose a recurring wait-time checking interval of 5 minutes. Choosing 10 minutes, for example, would mean the 15-minute interval triggers may not get evaluated on time. To prevent missed evaluations of triggers, the default is to perform this check once per minute.

However, if you are certain you can increase this setting without compromising your recurring wait-time triggers, you can do so and thus gain a slight improvement in regular event processing throughput, because processing need not be paused as often to perform such checks.

In the Integrated Solutions Console, complete the following steps to set the recurring wait-time checking interval:

  1. Select Monitor Models.
  2. Select the version of the monitor model you want to edit.
  3. Select Change Runtime Configuration.
  4. In the Message Consumption section, change the value of the Recurring wait-time checking interval field, as shown in Figure 17.
  5. Click OK, then Save.
Figure 17. The recurring wait-time checking interval parameter
Recurring wait-time interval

Tuning the JMS

Monitor JMS destinations are created during the monitor model deployment. The destinations are intended for receiving events from the CEI. You should increase the size of the connection pool of the queue connection factories and the maxConcurrency parameter for the activation specification to appropriate values. The Tivoli® Performance Viewer can help you determine the optimal numbers. One symptom of insufficient concurrency and insufficient connection pool size is an idle CPU.

Tuning the Monitor database

Figure 18. Monitor database tuning
Monitor database tuning

To optimize Monitor performance, you usually need to configure the Monitor and the message engine databases. To understand database tuning for Monitor, you need to first understand the characteristics of Monitor applications from a database point of view. Monitor applications are transactional applications, which have a high number of read and write operations on the databases. Therefore, the databases must be optimized for read and write operations. Also, the file systems of the databases must be optimized for fast I/O. DB2 tuning is outside the scope of this article, but you can refer to DB2 Tuning Tips for OLTP Applications and the Administering section of the DB2 Information Center for more information .

Tuning the dashboard

The dashboard uses the Monitor database to form its reports. The performance of the dashboard’s queries in the Monitor database is by far the most important factor in dashboard performance.

Figure 19. Dashboard tuning
Dashboard tuning

Use the following guidelines to evaluate where optimization might be required for better dashboard performance.

  • Using the Instances view of the Dashboard results in SQL queries being sent directly to the Monitor database. The response time of these types of queries can be improved with standard SQL tuning activities. Refer to the Tuning section of the DB2 Information Center.
  • Using the Dimensional and Reports views results in multidimensional expression language (MDX) queries being sent to IBM DB2 Alphablox. IBM DB2 Alphablox maintains a cache of recent queries and the responses to them from DB2. These types of queries can be improved by tuning DB2 Alphablox cubes. Refer to the Administrator's Guide in the DB2 Alphablox Information Center.
  • Key Performance Indicator (KPI) views have an additional KPI cache built directly into the Dashboard application server. By default, the cache is disabled. To reduce KPI calculating costs and to improve system performance, you should enable the cache. To set the refresh interval of the cache, do the following:
    1. Select Monitor Models.
    2. Select the version of the monitor model you want to edit.
    3. Change the value of KPI Cache Refresh Interval.
    4. Click OK, then Save.
    For optimal performance, set the refresh interval as high as possible. However, be aware that this impacts the currency of the data on the dashboard.
  • Use Monitor’s Data Movement Service (DMS) to enable periodically copying of information from the event processing tables to the dashboard tables. The advantage of copying information to separate dashboard tables is so that the dashboard can have its own set of tables that can be optimized for dashboard SQL read commands.
  • If DB2 Alphablox is installed, the cubes that are defined for each installed monitor model are enabled by default with a one minute refresh interval. This means that each defined cube rebuilds its metadata every minute and thus incurs processing overhead as well as database activity. From a performance point of view, you should set the refresh interval as high as possible. However, be aware that this impacts on the currency of the data on the dashboard.

Summary

This article described some basic performance tuning tips and guidelines for WebSphere Business Monitor Version V6.1. It guided you through all parts of a Monitor environment, highlighting parameters and settings that can have a significant impact on throughput and response times for your application.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=421526
ArticleTitle=Configure WebSphere Business Monitor for high throughput and performance
publish-date=09192009