代理调整

以下各节介绍为了提高性能可以对代理属性进行的调整。

内存管理：提高代理在负载下的稳定性

内存管理可以分别在各个目的地上配置，也可以在系统范围级别内（对于所有目的地）配置。

使用物理目的地限制

有关物理目的地限制的信息，请参见第 6 章，管理物理目的地。

使用系统范围的限制

如果消息生成方的数目超过消息使用方的数目，则消息可能在代理中堆积。代理包含限制生成方以及在内存很低的情况下将消息交换出活动内存的机制，但最好还是对代理可以保持的消息总数和消息字节总数进行严格限制。

可以通过设置 imq.system.max_count 和 imq.system.max_size 代理属性来控制这些限制。

例如：

imq.system.max_count=5000

上面定义的值表示代理最多只能保存 5000 条未传送/未确认的消息。如果发送了其他消息，它们将被代理拒绝。如果消息是持久性的，当生成方尝试发送该消息时，会收到一个异常。如果消息是非持久性的，代理将在不给出任何提示的情况下丢弃该消息。

如果在发送消息的过程中返回了异常，客户端应该暂停片刻，然后再次尝试发送。（请注意，异常绝不会是由于代理未能接收消息而引发的；所引发的异常都是由发送方客户端检测到的。）

多使用方队列性能

多队列使用方处理队列目的地中的消息的效率取决于下列可配置的队列目的地属性：

• 活动使用方数 (maxNumActiveConsumers)

• 可以在一批中传送给使用方的消息的最大数量 (consumerFlowLimit)

要达到最优的消息吞吐量，必须有足够数量的活动使用方以适应队列的消息生成速率，并且队列中的消息必须以最大化使用速率的方式路由和传送给活动使用方。Sun Java System^TM Message Queue Technical Overview中介绍了在多个使用方之间平衡消息传送的一般机制。

如果消息在队列中堆积，这可能是因为没有足够的活动使用方来处理消息负载。也可能是每批传送给使用方的消息太多，导致消息在使用方堆积。例如，如果每批的大小 (consumerFlowLimit) 太大，某个使用方就可能会收到一个队列中的所有消息，而其他活动使用方则一个也没有收到。如果使用方速度特别快，这也不会成为问题。

但是如果使用方相对较慢，而您又希望将消息均匀地分配给它们，则需要将每一批的大小减小。每一批的大小越小，将消息传送到使用方所需的开销就越多。但是，对于较慢的使用方，使用较小的批大小通常能获得网络性能的提升。