1) 连接数对性能影响较小，主要影响因素为 io，在每个连接发送或者接收频率较低
的情况下，amq可以支持更多的连接数，另外，每新增一个连接，amq需要增加
两个线程处理。 nio协议在5.2中还不够稳定，对减低系统负载的作用也不够明显。
2) 超过10K的大消息对吞吐量和服务器 load都影响很大，但是对大消息可以使用
amq的流协议处理，这次没有测试。对我们系统中的消息基本都不会超过 2k，这
种情况下性能差别不是很大。
3) 数据存储配置，jdbc 的性能远比 kaha 低，jdbc 单节点流量大概是 500~600 条，
kaha单节点处理可达4000~5000，相差一个数量级，但是jdbc的稳定性很好，发
送和接收非常稳定，kaha只因为文件存储的原因，当文件存储 hash bin扩展或者
文件碎片管理的时候经常会全部阻塞，导致短时间（1s~几秒）不可访问。
4) 生产端流量控制还是有必要的，避免高峰时阻塞消费。（？）
5) 高 级 特 性 （ Master/Slave,Networkconnector,Virtual Destination,Composite
Destination）等 5.2 都还不够稳定，目前建议部署为客户端负载均衡，类似
memcached的部署方式，这样也可以屏蔽mq，做到mq无关，另外这样性能也最
好，基本可以做到线形扩充。
6) 目前主要问题为消息重复消费问题，需要定位问题代码所在。具体表现为消息丢失
（发现过1、 2次），消费数多于发送数，消息可能有重复消费。（注：这个问题提
交到 amq 后，答复在 5.3 已经解决，在 5.2 上关闭 cache 后也可以避免这个，
useCache=false，经过测试，5.2上使用这个选项后问题解决，性能有所下降但是
并不严重，在10%以内）。
7) 每一个producer或consumer连接，broker会产生2个线程来提供服务，看来过多的连接会加重broker的线程上下文切换的成本。
8) 打开useAsyncSend=true功能，能提供带来10%-20%的发送速度提升，在IO频繁
操作的情况，可能会更明显，但如果broker出现当机时，极有可能出现消息丢失。
9) 64位的JDK和新的JVM配置参数对整体性能提供有一定的帮助。