This page will detail 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 high logging levels can negatively effect the performance of your application. Logging creates extra objects which increases memory usage, as well as promotes contention between threads which wish to print to the logger.

The log level can be lowered by using the enterprise manager. The highest log level is 0 and produces the most output. The lowest log level is 7, which produces very little output. Unless attempting to gather logging information related to a particular issue it is recommended to keep the log level no lower than 4 (Quiet). Particularly demanding applications may wish to increase this up to 7 if necessary.

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.lax file under the server installation directory:

There are further flags that can be applied to the lax 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.