0
1
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 property specifies 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.
Resources
Disclaimer:The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
