参照http://www.ibm.com/developerworks/cn/websphere/library/techarticles/loulijun/MQperformance.html 和http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0712_dunn/0712_dunn.html
1. It is better when the MQ and WAS set up in the same machine.
2. You should change the "Max queue depth" for your used queues as the message destination. The "Max queue depth" is as total number you can put messages to the queue. Its default value is 5000, so you can change it base on your situation.
3. You should set the "Connection pool -->Maximum connections" and "Session Pool-->Maximum connections" to a conformable value under your "Queue connection factories" base on your situation via WAS. You can set it to 50, or 100, or 200. You should do the test under your circumstance.
4. You should set "Channels" to a conformable value under your "Queue ManageràProperties" base on your situation via WMQ. You can set it 300, or 500, or 600. You should do the test under your circumstance.
5. You should change log configuration to a conformable value.
目前随着我们在中国的WebSphere MQ（MQSeries）用户数量越来越多，越来越多的用户开始对MQ使用时的性能优化问题提出要求，希望能够更好地使用我们的产品，并尽可能的发挥它的 最大优势，这里，我根据日常积累的经验谈一谈在MQ性能优化方面应该考虑的因素。
一、 与API 调用有关的MQ性能考虑因素
这里，我们在讨论各个API对性能的影响时，均以C语言提供的API为例，其他开发语言与此类似。
1 关于MQCONN/MQDISC的使用
在MQ的13个函数中，MQCONN/MQDISC是最耗CPU的两个函数，其次是MQOPEN和MQCLOSE这两个函数，因此要尽量避免必要地重复使用这几个函数。比如，当您需要从队列中读取多条消息时，正确的编程方法应该如下：
|
即：连接/断开队列管理器一次，打开/关闭队列一次，读取消息多次。而不应该反复建立与队列管理器的连接和反复进行队列打开/关闭操作。
2 MQCONNX的使用
通常，我们使用MQCONN这个函数建立与队列管理器的连接，除此之外，MQ支持trusted application binding，即fastpath binding，用MQCONNX来实现。当从性能方面考虑时，我们可以使用MQCONNX来提高性能。
在 使用MQCONNX时，我们可以设置MQCNO(connect option)来指定连接方式。缺省情况下，该选项为MQCNO_STANDARD_BINDING，如果设置为 MQCNO_FASTPATH_BINDING，即表明采用fastpath binding方式连接队列管理器，这种应用称为trusted application。所谓的trusted application，是指该应用程序和本地队列管理器代理组成同一个进程，从而提高性能。利用fastpath binding不仅能够提高连接队列管理器的性能，同时也能够提高mqopen,mqclose的性能。
3 消息大小对mqput, mqget函数耗时的影响
尽量减小消息的大小，小消息的读取效率要高。对于mqget, mqput这两个函数而言，8k以下的消息的耗时差别不大，8k到128k的消息的耗时随着消息大小的增加而增加。大于128k的消息耗时较大，因为当与队列相关的内存满了的时候，会有硬盘交换。
同时要注意，从传输效率而言，如果在广域网上进行消息传输，消息太小会影响传输效率，因为对于每一消息，MQ都会有一个消息头，它会占有一定的字节数，如果把消息拆分太小，每个消息的传输头都会占据一定的开销。
4 对一个空队列的open,close 操作比非空队列的同样操作耗时要多。
第一次open队列耗时比接下来的open 耗时要多，对本地队列和远程队列的open,close耗时基本相同。
5 使用MQCMIT对消息进行批处理
当处理一批消息时，可以采用MQCMIT函数，将若干消息作为一个完整的交易来处理，消息将作为一个batch统一提交，而不是一个个地分别提交，因此，可以提高性能。尤其对于永久性的消息效果更加明显。
6 使用Distribution List 方式来把相同的消息发往不同的目的地
大 家知道，MQ适用于不同类型的应用。不仅可以实现"点对点"的通讯，还通过DistributionList支持"多点广播"应用，即能够将消息发送到多 个目标站点。可以使用一个MQ函数调用将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息，减少了函数调用的个数。同时，MQ不仅提供了多点 广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户或队列时，MQ可以将消息的一个复制版本和该系统上接收者的名单发送到 目标系统。目标系统在本地复制这些消息，并将它们发送到DistributionList上的队列，从而减少了网络的传输量。
7 当向队列管理器仅发送一条消息时，使用MQPUT1函数。
在MQ的13个函数中，MQPUT1实现了这样一种功能，即它合并了MQOPEN, MQPUT, MQCLOSE三个函数的功能，在打开队列并且只希望发送一条消息时，它的CPU消耗比上述三个函数相加要少。
8 用match correlation ID的方法取消息比不匹配性能要差。
  |
| |
二、 与队列属性有关的MQ性能考虑因素
1 消息的永久性和非永久性
大 家知道，MQ的消息分为永久性消息和非永久性消息两种，永久性消息是保存在硬盘存储介质上的，需要纪录日志的；相反，非永久性消息是存储在内存中的，不需 要硬盘读写，因此使用非永久性消息的性能比永久性消息的性能要高很多，具体而言，最大可以提高近十倍。要注意的是，只有永久性消息的可靠性是可以保证的， 即在发生故障，如当系统重启或队列管理器重启时，可以保证不丢失。因此，应根据您的业务需求和网络状况来确定消息的属性。
2 调整队列的相关参数设置：
对 于队列而言，除了可以通过MQSC的"define queue"命令设置它的属性之外，有另外两个参数直接影响队列的性能，而这两个参数只有通过qm.ini文件进行设定。它们分别是：队列文件的大小 (Maximum amount of bytes in a queue)和为每一个队列的非永久性消息保留的内存大小(Maximum amount of memory reserved for non-persistent messages)，它们的缺省值分别对应于DefaultQFileSize和DefaultQBufferSize这两个参数。
队列的定义存储在硬盘上，并且在队列被打开时申请资源。我们可以设置队列DafaultQFileSize和DafaultQBufferSize两个参数来确定队列的定义参数，这些参数在队列管理器重启时生效，下面分别给予描述。
1) 队列文件大小
缺 省情况下，队列文件在硬盘上的大小最大是320M, 它会被预先分配195kb内存，这195kb内存会在队列打开时获得。队列文件的大小最大值可以达到1G bytes, 这可以通过设置DefaultQFileSize参数来设定，当其设为1G时，队列打开时会申请350kb内存。
2）非永久性消息对应的内存大小
缺省 情况下，对每个队列而言，用来存储non-persistent消息的共享内存是64kb, 我们可以通过修改DafaultQBufferSize参数将其增加至1MB。在打开队列的时候，要申请如此数量的内存，因此它直接影响到队列管理器需要 的内存资源的大小，包括实存和虚存。推荐值是把该值设制成64kb的两倍，即128kb。永久性消息是存在硬盘上的，而非永久性消息是存在内存中的，当设 定的buffer不够时，要进行磁盘交换，速度就会减慢，把它扩大后，若不进行硬盘交换，读取队列的速度就会快。当然，对该参数的修改也取决于系统实际物 理内存的大小。
修改这两个参数的方法是更改队列管理器配置文件qm.ini的相关参数，具体方法举例如下：
在qm.ini文件中增加如下一节:
|
3 队列的深度和队列上的消息的长度的设置也会影响性能。
对 每一个队列而言，都会被分配一个设定的buffer size，当磁盘I/O很高时，说明队列的buffer size满了，从而产生了硬盘交换。每个消息的大小乘以队列的深度决定了队列上消息占内存的大小，可以增加队列的个数或者增加队列的buffer size来提高性能。
4 设置多个队列提高并行处理能力
例如在总部，可以针对每一个分支机构设置一个队列，采用多个应用程序读取这些队列；对于同一个队列，也可以采用多个进程/线程同时进行读取操作。
| |
| |
三、与日志有关的MQ性能考虑因素：
1 把MQ的log 和queue files 放在不同的文件系统上。即将/var/mqm/log, /var/mqm文件系统分开。
在 安装MQ的时候，我们经常推荐大家创建两个文件系统，即/var/mqm/log和/var/mqm，为了提高MQ的性能，我们建议把这两个文件系统放在 不同的物理磁盘上，以提高磁盘I/O的效率。这是由于，在记录数据日志时，MQ会同时更新位于/var/mqm下的队列文件以及位于/var/mqm /log下的数据日志，因此建议把它们放在不同的物理盘上。
2 扩大MQ的日志文件大小和个数
在qm.ini配置文件中，有一小节是专门控制MQ的系统日志的，如下所示：
|
其中，LogPrimaryFiles和LogSecondaryFiles指定了日志文件的个数，LogFilePages指定了每个日志文件的大小，LogBufferPages指定了日志缓冲区的大小，这些参数都可以影响MQ的性能。
增大这些参数的设定值，可以提高性能。例如：假设您设计MQ的日志总容量为128MB，那麽，采用2个64MB的日志文件的性能，要优于采用24个4MB的日志文件。这是因为它减少了日志文件切换的次数和频率，尤其在AS/400系统上，更为显著。
在 unix系统中，LogFilePages的缺省值为1024，即4MB，最大值为16384，即64MB。而Primary和Secondary日志文 件的总个数不能超过63个。为了提高性能，我们可以将LogFilePages和LogPrimaryFiles设置为较大的值，这可以通过MQ的控制命 令crtmqm来设置，方法如下：
|
或者通过修改qm.ini文件来设置。
除 了物理日志文件的大小和个数之外，LogBufferPages代表日志缓冲区的大小，增大它的数值，也可以提高性能，如：可以把它的值设置为最大，即 512x4K pages=2MB，这样，在日志写盘操作时，可以一次将2MB的数据从缓冲区写入磁盘。修改LogBufferPages的方法是修改qm.ini文件 来实现。
| |
| |
四、与channel有关的MQ性能考虑因素：
1. 选择侦听程序(Listener)的线程/进程运行方式：
MQ 的侦听程序有两种配置和启动方式，一种是通过配置/etc/inetd.conf文件选择使用inetd方式, 也可以使用MQ自身提供的runmqlsr程序，所不同的是：runmqlsr 是一个线程应用，所以比inetd需要更少的内存消耗。因此，采用runmqlsr方式可以提高通道相关的性能。
2. 选择通道的线程/进程运行方式
与侦听程序类似，与MQ通道对应的MCA代理程序也可以有线程和进程两种运行方式，可以通过定义通道的MCATYPE属性来设置通道MCA的运行方式为thread方式。让通道以线程方式运行而非进程方式运行，这样可以减少通道运行的进程个数和消耗的内存资源。
对于以上两点，要注意的是：当通道的连接个数很多时，如在Unix平台上超过500个时，建议MCATYPE和listener采用进程的方式。
3. 设置侦听程序的trusted运行方式
与 MQ应用程序类似，MQ的通道侦听程序也有trusted(fastpath)和non trusted(standard)两种运行方式，采用trusted运行方式可以降低CPU和内存消耗。将通道和侦听程序设置为trusted方式运行 的方法是通过修改qm.ini配置文件中的MQIBindType参数来实现，即创建或修改qm.ini文件中与Channels相关的小节，例如：
Channels:
-
MQIBindType=FASTPATH 或者
MQIBindType=STANDARD
其中，FASTPATH表示trusted运行方式，而STANDARD表示非trusted运行方式。
4. 加大通道的PipeLineLength属性
从MQ版本V5.2开始，MQ提供了一个新的通道参数，即PipeLineLength属性，通过该属性，可以设置MCA采用多个线程的方式来传输消息，从而成为提高通道性能的又一个手段。缺省情况下，该参数数值为1，任何大于1的设置MQ本身都会将其设置为2。
设置PipeLineLength的方法是修改qm.ini文件的Channels一节，如下：
Channels:
- PipeLineLength=2
注意，必须在通道两端都进行设置，否则会自动取两者之间的最小值。
5. 设置MaxChannels和MaxActiveChannels属性
MaxChannels 和MaxActiveChannels分别代表队列管理器允许配置的通道的最大个数和允许同时运行的通道的个数，MaxChannels的缺省值是 100，MaxActiveChannels的缺省值与MaxChannels相同。如果您的并发通道连接个数超过了100，您需要修改这两个参数。这对 于大并发的Client/Server间通讯尤为重要。
6. 调整通道的Batchsz( )属性
通道的Batchsz( )值是影响通道性能的一个关键参数。在MQ进行消息传输时，通道对消息的处理也是在同步点的控制之下并具有交易特性的，在以下条件满足时，它将统一提交一批消息：
当发送的消息个数达到BATCHSZ时；或传输队列为空，并且在BATCHINT指定的时间间隔内一直没有消息到达时。
缺 省情况下，通道的Batchsz是50，这是一个较为合理和优化的设置。一个小的Batch size值会使每条消息占用大的资源。比如，假设我们在局域网的情况下，Batch size值越大，通道的性能越好。然而，在广域网环境下，要根据网络状况的好坏来设置该参数，若网络状况很差，Batch size值越大，可能会导致通道的性能越差。
7. 推荐在两个队列管理器之间同方向上建立一条通道。
8. 设置通道的NPMSPEED(FAST)属性。
如前所述，MQ的消息分为永久性消息和非永久性消息两种，对于非永久性消息，通道属性NPMSPEED可以设置为FAST和NORMAL，为了提高性能，可以设定该属性为FAST。
除 了队列、队列管理器日志大小、通道和API的使用和设置对MQ性能的影响之外，MQSeries的性能与系统的资源或性能息息相关，如系统的CPU, RAM, Disk (I/O), network等方面的配置会直接影响WebSphere MQ的性能，在此，就不一一列举了。