This page details important configuration options that can be changed on the server to improve performance. Important monitoring information that can be collected using the Admin API is also mentioned here. This monitoring information can be used to diagnose common problems.

Logging information can be useful for debugging a variety of problems that may occur. However, particularly verbose logging levels can negatively affect the performance of your application. Logging creates extra objects which increases memory usage, and also promotes contention between threads which wish to print to the logger.

The verbosity of the logging can be changed by using the Enterprise Manager. The most verbose log level is 0 and produces the most output. The least verbose log level is 6, which produces very little output. Unless you are attempting to gather logging information related to a particular issue, it is recommended to use a the log level no more verbose than 5 (Quiet). Particularly demanding applications may wish to reduce the verbosity to logging level 6.

For client side logging please see the relevant API documentation.

The server is configured to enter a peak operating mode when a certain number of messages are being delivered through the server per second. Peak mode will batch messages in an effort to keep server load at an optimal level. This batching may increase average latencies for clients.

It is possible to raise the peak mode threshold so that the server does not utilise peak mode until a much higher load is reached. It is important to stress that beyond a certain point the non batching performance will suffer as machine limitations are reached.

Machines with good hardware will benefit from having this threshold raised, but slower machines may function better in batching mode after a certain message rate is reached.

By default, the most aggressive fanout mechanism Universal Messaging provides is disabled. This particular mechanism is capable of meeting extremely demanding latency and message rate requirements, however is very demanding on the resources of a system. It is disabled to prevent it consuming resources on machines with less resources (for example development machines).

If the hardware which the Universal Messaging server runs has greater than 8 cores it is recommended that you enable this fanout mechanism to produce the best latencies. This fanout mechanism will consume multiple cores entirely, so will therefore increase the load average of the machine. It is important that you have sufficient free cores free, as otherwise it is possible that this mode will cause Universal Messaging to starve other threads/processes running on the system.

The mechanism can be enabled by adding the following flag to the nserver.conf or Server_Common.conf file under the server/<realm>/bin directory of your installation, where <realm> is the name of the Universal Messaging realm:

There are further flags that can be applied to the nserver.conf or Server_Common.conf file to customize the behaviour of this fanout setting. The first of these flags can be used to adjust the number of times that this fanout mode will spin on a core attempting to do work before switching to a less aggressive fanout mechanism.

The default value for this spin count is one billion. Reducing this value will generally encourage the server to switch to a CPU intensive fanout mechanism, if the server is not busy. Reducing this value may result in a performance penalty which occurs as a result of using the less intensive fanout mechanism. The maximum value of this parameter is the same as Long.MAX_VALUE.

The less aggressive fanout mechanism employs a wait as opposed to spinning mechanism, the second flag can be used to specify the wait time between checking if work is available.

This parameter will alter the number of nanoseconds which the fanout mechanism will wait for between checking if it has tasks to complete. Increasing this number will decrease the CPU consumption of Universal Messaging, but at a cost to latency.