Before discussing how to tune the performance of an Fuse MQ Enterprise application, it is worth recalling that performance is also affected by the system environment.

For persistent brokers, disk speed is a significant factor affecting performance. For example, whereas the typical seek time for an ordinary desktop drive is 9ms, the seek time of a high-end server disk could be as little as 3ms. You should also ensure that disks do not become excessively fragmented.

For both persistent and non-persistent brokers, the network speed can be a limiting factor. Evidently, there are limits to what can be achieved through Fuse MQ Enterprise tuning, if the underlying network is very slow. One strategy that you can try is to enable compression of large messages (see Enabling compression). In this case, it is also important to avoid delays caused by latency; for this reason, it might be a good idea to enable more asynchronous behavior.

Relevant aspects of the underlying hardware include the speed and number of CPUs, and the memory available to the broker. In particular, increasing the available memory can bring several performance advantages.

For example, if the broker's entire B-tree message index can fit into memory, this significantly reduces the amount of reading and writing to disk that is required. Also, if some consumers are slow, causing messages to back up in the broker, it can be an advantage to have a large amount of memory available to buffer the pending messages.

To increase the amount of memory available to a JVM instance, use the -Xmx option. For example, to increase JVM memory to 2048 MB, add -Xmx2048M (or equivalently, -Xmx2G) as a JVM option. In the Enterprise product, the startup scripts in bin/ take the maximum memory value from the JAVA_MAX_MEM environment variable. For example, to set the maximum JVM memory to 2 GB, use the following bash shell command:

export JAVA_MAX_MEM=2G