关于MQ调优（续）

>>This optimal ratio depends on many factors including:
>>>the JDK version and operating system used
>>>whether or not the producers and consumers are running in the same JVM
>>>whether or not concurrent consumers are being used
>>>whether or not the producers/consumers are running on separate hosts
>>>the destination prefetch size
==>优化率依赖很多因素，包含如下：
==>使用的JDK版本和OS
==>producer和consumer是否在同一JVM
==>是否使用了并发的消费者
==>producer和consumer是否在独立的主机上运行
==>目标预取大小
前提：

>>>所有消息采用文本消息（TextMessage）并且大小是2KB==>All messages are text based and of a fixed size (2 KB).

>>>如无特别说明，producer,consumer和broker在同一主机的不同的JVM中。

1.消息大小==>消息类型影响性能的因素在于消息的大小，
==>Wherever possible, one should minimize the message size by choosing an appropriate message type.
==>可能地方，应该最小化消息大小，通过选择合适的消息类型来做到这一点。
==>建议ByteMessage
==>For example, a byte message would be smaller than its equivalent in text.==>例如，ByteMessage小于同样的TextMessage。
2.性能与可扩展性以及安全性的权衡：
==>Adding brokers in a cluster does decrease performance, but also increases scalability and data security.
==>往集群中添加Broker节点会降低性能，但是会增加可扩展性和数据安全性。
3.队里还是主题==>使用队列还是主题，一般取决于基础设施的需要。
==>with the 1/1/1 test registering about 18600 msgs/sec when using a queue and about 23500 msgs/sec when using a topic on the LOCAL-LINUX platform.
==>使用1:1:1（1producer:1destination:consumer）的方式，使用队列时，吞吐量是18600 msgs/sec，而采用主题模型，吞吐量达到23500 msgs/sec,前提是在本地linux上测试的。
==>仅在1:1:1下，topic吞吐量高于queue。
==>采用主题时，增加消费者的数量不是什么好事，因为每增加一个消费者，消息的备份都会发给主题。
==>但是多消费者，是可以提高队列的吞吐量的。
4.应答方式
==>Deciding between AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE for performance purposes depends on the topology.
==>本着性能的目标，选择AUTO_ACKNOWLEDGE还是DUPS_OK_ACKNOWLEDGE，取决网络拓扑
==>在broker网络下，建议auto_acknowledge，在客户端和broker在同一个机器时，不走网络的话，建议dups_ok_acknowledge。
==>一般来说dups_ok_acknowledge性能要高于auto_acknowledge，前提是基本不走网络时。
==>auto_acknowledge以为仅且一次应答，需要监控应答次数。而dups_ok_acknowledge不需要监控应答次数，允许重复应答，所以性能要高些，但前提是不走网络。
5.事务与非事务
==>When using transactions, messages are sent in a group (batch) before being acknowledged.
==>当使用事务时，在消息应答前，消息是按组或者批量发送的。
==>因此采用事务比不采用事务的性能要高，事务可以分别用于生产者和消费者上。
6.使用VMTransport
==>Using the VM transport increases the performance significantly if the broker and the clients are in the same VM.
==>This is because with the VM transport, messages are not sent to a network and no socket creation is necessary.
==>如果broker和clients在同一个JVM中，采用vm通道对性能有很大程度的提高。
==>这是因为采用vm通道，消息不会发送到网络，不必创建socket。
7.持久化与非持久化
==>The number of messages was reduced by more than 50% when the producer (but not the consumer) is made persistent.
==>If durable subscribers are used then the number of message per second falls dramatically.
==>当生产者采用持久化方式时，每秒消息的数量减少超过50%。（消费没有采用持久化）
==>如果持久化订阅也用上的话，每秒消息的数量会极大的减少。（消费者持久化，即持久化订阅）
==>持久化的方式：producer持久化、broker持久化、consumer持久化==>producer持久化？？
8.broker数量
==>the number of messages sent per second decreased as the number of brokers increases.
==>当broker网络中，broker的数量增加时，每秒发送消息的数量在减少。
==>With many more clients connected to a single broker those performance losses are offset by the benefits of scalability.
==>伴随着单broker上更多的客户端连接，性能的损失与可扩展性带来的好处需要权衡。
9.生产者数量==>10/1/1==>#producers/#consumers/#brokers==>n/1/1
==>there are no significant differences in performance when the number of producers keeps increasing in the Local-Linux environment.
==>between 1/1/1 to 10/1/1 the average plateau is 18800 msg/sec. In general, 2/1/1 showed a slight performance boost.
==>producer和broker同在一台机器时，生产者数量的增加在性能上没有带来明显变化
==>一般，2个生产者相对1个有稍微的性能提升，再增加生产者作用就不明显了。
10.消费者数量
==>In both environments, Local-Linux and EC2-Linux,
==>we see that the 1/1/1 configuration does not give the best performance
==>if the procedures and consumers are in different JVM. However,
==>when the producers and consumers were placed in the same JVM the results were different
==>as illustrated in Figure 4 and Figure 5 for Local-Linux and EC2-Linux respectively.
==>当producer和consumer在不同JVM时，无论是在实体linux还是虚机linux环境下，可以看到1/1/1配置不会带来最好的性能，。
==>当producer和consumer在同一个JVM时，在实体linux和虚机linux是不同的，在实体linux下，1/1/1的性能基本是最好的，比1/2/1稍差些。在虚linux下，1/1/1基本是最差的。
==>一般消费者保持在2或者3个时，达到最佳性能。再增加消费者性能没有明显变化。（实体linux下不同JVM时，建议2到3个消费者最佳）