MQe can be used in a number of different configurations, and the performance you can expect will vary a great deal depending on your adapters and manner of use.
The main thing to be aware of when configuring MQe is that disk accesses are the single biggest cause of slowdown in an MQe system. All unnecessary disk accesses should be designed out from the beginning.
Try to split the messages that you'll be dealing with into messages that it's important are persistent and messages that do not need to be persistent. The persistent messages need to use a disk fields adapter for storage, but the non-persistent ones should use a memory fields adapter. Non-persistent messages stored in memory can go around 100 times faster than messages stored to disk.
When possible, distribute queues across different physical hard discs, so that reads and writes to different queues can take place using different hardware and happen simultaneously.
When multiple clients are accessing a single server, use multiple queues, as only one client can use a queue at a time. Avoid very large numbers of queues, as this increases the time to do any MQe access.
Keep polling systems such as trigger transmit rules or home server queue polls to a minimum. Unless you need a specific performance characteristic, the intervals between these can often be configured to be quite large. If you are using them together, then the trigger transmit rule, which is only used to automatically recover a home server queue from network stoppage can often be set to have a much larger interval. If you are designing an application that makes use of home server queues and you are using a trigger transmission rule, then consider replacing it with a user interaction to cause the trigger transmission.
Most JVMs can have their initial memory settings tweaked. These settings are often on -msX and -mxX. Executing java -X will give you more information. Try increasing the initial and maximum heap size to as much as you can without causing the machine to start paging.
If you are running some application with a queue manager that is under a lot of external load, be aware that your own application may suffer from reduced performance as many threads to deal with incoming messages are started. Making sure your own application is multithreaded can reduce this problem.