Download PDF (1.3 MB) - IBM Redbooks

Beyond its persistent delivery of events to registered consumers, CEI offers the ability to
explicitly store events in a database. Database event storage requires significant processor
usage, so avoid storing the events in the database if this additional functionality is not needed.
You can also configure the CEI data store:
1. In the administrative console, select Service Integration Common Event
Infrastructure Event Service Event Services Default Common Event
Infrastructure event server.
2. Clear the Enable Data Store check box.
4.10.3 Configuring message consumption batch size
Processing events in large batches is much more efficient than doing it one at a time. Up to
some limit, the larger the batch size, the higher the throughput rate. But there is a trade-off:
processing and persisting events to the Monitor database is done as a transaction. Although
a larger batch size yields better throughput, it costs more if you must roll back. If you
experience frequent rollbacks, consider reducing the batch size. You can reduce cache size in
the administrative console under the server scope:
1. Click Applications Monitor Models and select the version of the batch.
2. Click Runtime Configuration Tuning Message Consumption Batch size and set
the batch size you want. The default value is 100.
4.10.4 Enabling key performance indicator caching
The cost of calculating aggregate key performance indicator (KPI) values increases as
completed process instances accumulate in the database. A KPI cache is available to reduce
the resource usage of these calculations at the cost of some staleness in the results. The
refresh interval is configurable in the WebSphere administrative console:
1. Click Applications Monitor Models and select the version.
2. Click Runtime Configuration KPI KPI Cache Refresh Interval.
A value of zero (the default) disables the cache.
4.10.5 Using table-based event delivery
There are two ways in which events can be delivered by CEI to a monitor model:
► Through a JMS queue
► Through a database table
You can choose a method at application installation time for a monitor model. A suggestion is
to choose table-based event delivery (sometimes called queue bypass), both for reliability and
for performance and scalability reasons.
4.10.6 Enabling the Data Movement Service
By default, the same tables are used for event processing and for dashboard reporting. You
can enable an optional scheduled service, called the Data Movement Service (DMS) to switch
dashboard reporting against a separate set of tables. DMS also periodically copies the data
from the event processing tables for the server to the dashboard reporting tables.
Chapter 4. Performance tuning and configuration 77