Every messaging engine manages two memory buffers that contain
messages and message-related data. You can improve the interaction of a messaging
engine with its data store by tuning the properties that set the sizes of
the two buffers.
About this task
You can set the following properties to improve the interaction of
a messaging engine with its data store:
-
sib.msgstore.discardableDataBufferSize
- The size in bytes of the data buffer that the messaging engine
uses to contain data for which the quality of service attribute is
best effort nonpersistent. The default value is 320000,
which is approximately 320 kilobytes.
- The discardable data buffer contains all data for which the quality
of service attribute is best effort nonpersistent. That data comprises
both data that is involved in active transactions, and any other best
effort nonpersistent data that the messaging engine has neither discarded
nor consumed. The messaging engine holds this data entirely within
this memory buffer and never writes the data to the data store. When
the messaging engine adds data to the discardable data buffer, for
example when the messaging engine receives a best effort nonpersistent
message from a client, the messaging engine might discard data already
in the buffer to make space. The messaging engine can discard only
data that is not involved in active transactions. This behavior enables
the messaging engine to discard best effort nonpersistent messages.
- Increasing the size of the discardable data buffer allows more
best effort nonpersistent data to be handled before the messaging
engine begins to discard messages.
-
sib.msgstore.cachedDataBufferSize
- The size in bytes of the data buffer that the messaging engine
uses to contain data for which the quality of service attribute is better
than best effort nonpersistent and that is held
in the data store. The default value is 320000, which
is approximately 320 kilobytes.
- The purpose of the cached data buffer is to optimize the performance
of the messaging engine by caching in memory the data that the messaging
engine might otherwise have to read from the data store. As it writes
data to the data store and reads from the data store, the messaging
engine attempts to add that data to the cached data buffer. The messaging
engine might discard data already in the buffer to make space.
-
sib.msgstore.transactionSendLimit
- The maximum number of operations that the messaging engine includes
in each transaction. For example, each JMS send or receive is an operation
that counts towards the transaction send limit. The default value
is 100.
-
sib.msgstore.omPermanentStoreCacheSize
- The maximum number of managed objects that can be cached in the
file store's permanent store managed objects cache. The default
value is 1000. The managed objects are added to the cache when they
are written to the store file on a first in first out basis. When
the cache exceeds the maximum value specified, the new cache entries
overwrite the old entries.
- For every message that is sent, there are three managed objects
that are added to the file store. In the case of persistent messages,
two of the managed objects are governed by the sib.msgstore.cachedDataBufferSize
cache and the third managed object is not cached anywhere. The third
managed object is the link in the queue. In order to consume a message,
the link must either be present in memory (via the cache) or must
be read from the file store.
- If the performance of consumers decreases significantly as the
queue depth increases, increasing the size of the cache can be beneficial
(for example, increase the size to 100000). The size causes an array
of size 100000 SoftReferences to be used as the cache. Where this
cache structure itself might have a relatively minor heap requirement,
it will cause more managed objects to be retained in the heap until
the SoftReference itself is collected by the Garbage Collector. The
benefit of increasing the size of the cache might not always result
in a significant performance improvement because it is a soft cache,
and the cached objects are not retained forever even if they are not
overwritten by newer objects.
- The best performance results are obtained when messages are consumed
quickly and are not left on the queue for a long period or allowed
to accumulate in high numbers on the queue.
-
sib.msgstore.omTemporaryStoreCacheSize
- The maximum number of managed objects that can be cached in the
file store's temporary store managed objects cache. The default
value is 1000. The managed objects are added to the cache when they
are written to the store file on a first in first out basis. When
the cache exceeds the maximum value specified, the new cache entries
overwrite the old entries.
- For every message that is sent, there are three managed objects
that are added to the file store. In the case of non-persistent messaging,
two of the managed objects are governed by the sib.msgstore.discardableDataBufferSize
cache and the third is not cached anywhere. The third managed object
is the link in the queue. In order to consume a message, the link
must either be present in memory (via the cache) or must be read from
the file store.
- If the performance of consumers decreases significantly as the
queue depth increases, increasing the size of the cache can be beneficial
(for example, increase the size to 100000). The size causes an array
of size 100000 SoftReferences to be used as the cache. Where this
cache structure itself might have a relatively minor heap requirement,
it will cause more managed objects to be retained in the heap until
the SoftReference itself is collected by the Garbage Collector. The
benefit of increasing the size of the cache might not always result
in a significant performance improvement because it is a soft cache,
and the cached objects are not retained forever even if they are not
overwritten by newer objects.
- The best performance results are obtained when messages are consumed
quickly and are not left on the queue for a long period or allowed
to accumulate in high numbers on the queue.
Attention: The messaging engine uses approximate
calculations to manage the data it holds in the memory buffers. Neither of
the DataBufferSize properties gives an accurate indication of the amount
of memory that the messaging engine consumes in the JVM heap. The messaging
engine can consume considerably more heap storage than the DataBufferSize properties
indicate.
To set the properties of a messaging engine to improve
its interaction with its data store, use the administrative console to complete
the following steps:
Procedure
-
In the navigation pane, click
.
-
Type the name of the property that you want to set.
-
Type the value that you want to set for that property.
-
Click OK.
-
Save your changes to the master configuration.
What to do next
Remember: When you change any of these properties, the
new values do not take effect until you restart the messaging engine.