SIBus
as part of IBM Websphere v8.5 release, improved performance of Messaging Engine
startup in certain scenarios. This blog gives details about back ground of
Messaging Engine start up and how SIBus exploits data base concurrency support
to improve startup performance and the ways to tune the SIBus parameters to achieve
better startup performance.

These
Messaging Engine performance enhancements are applicable to only Data store i.e
data base is used for Message Store.

Messaging
Engine startup is two types: Cold start and Warm start. Cold start is first
time Messaging Engine is being created i.e Message Store is created freshly. In
case of Warm start, Messaging Engine uses the already existing Message Store.
However a Messaging Engine can not use Message Store which was created by other
Messaging Engine.

As
part of Messaging Engine Warm start, it has to load all Destinations and messages
(which are meant for it and for other Messaging Engine) from Message Store (i.e
from data base). This is called
reconstitution. Prior to WAS 8.5, SIBus runs reconstitution (i.e loading all
these objects from data base) sequentially from a single thread.

In
WAS 8.5, Messaging Engine startup time is improved, by
loading the destinations concurrently in a multi-core architecture. The
concurrent loading is possible if the message store is configured with the
database which supports parallel reads by multiple threads. The performance
improvement is directly proportional to the parallel processing capability of
the database and the capacity of the system on which the messaging engine is
running.

Now
reconstitution phase (i.e loading all required objects from data base during
Messaging Engine startup) by default uses number of threads equal to number of
cores/processors in machine. For example in case of dual core machine, it uses two dedicated
threads for reconstitution.

In
lab by testing various scenarios, we have concluded having one dedicated thread
for each core/processor would be optimal setting, and this setting has been used by default.

However
this may vary depending on your environment. Hence SIBus gives a way to
configure through custom property sib.processor.maxReconstituteThreadpoolSize.
This propertyspecifies the number of
threads used to load destinations concurrently when the messaging engine is
started.

In
your local environment, you can test various test scenarios and could arrive to
one suitable number.

In
case your database does not support parallel multiple reads by multiple
threads, then you might set the property value to 1, so that contention among
threads could be avoided.

The
unit of work in reconstitution phase is loading a destination i.e a loading of single
destination can not be split into multiple tasks and perform these tasks
simultaneously by multiple threads. This is not possible.In case if your configuration is having only
one destination, then these startup enhancements are not applicable.