测试环境：

 硬盘：1T,5400  (效果不佳)

得出了一个异样的测试结果：

持久： 

插入200000条JSON，共消耗：25.175 s

平均：7944.389275074478 条/秒

插入200000条JSON，共消耗：34.47 s

平均：5802.146794313896 条/秒

插入200000条JSON，共消耗：29.937 s数量：1400000

平均：6680.696128536593 条/秒

插入200000条JSON，共消耗：29.094 s

平均：6874.269608854059 条/秒

非持久：

插入200000条JSON，共消耗：11.35 s数量：1800000

平均：17621.14537444934 条/秒

插入200000条JSON，共消耗：10.714 s

平均：18667.16445771887 条/秒

插入200000条JSON，共消耗：11.153 s

平均：17932.394871335066 条/秒

插入200000条JSON，共消耗：10.717 s数量：2400000

平均：18661.93897545955 条/秒

主要在自己本地测试，最终祸首是硬盘不给力啊；

在进行持久化操作时，ActiveMQ默认是kahadb管理

log的默认大小是32MB,当超过之后会新建一个新的log文件，完成操作后，activeMQ又将旧的log删除了。

代码贴上：

Java代码  

1. public class Sender {  
2.   
3.     static int size = 200000;  
4.     static Session session;  
5.     static MessageProducer producer;  
6.     static Topic topic;  
7.     static Connection connection;  
8.     static String str = "[{'flag':'1','value':'8854c92e92404b188e63c4031db0eac9','label':'交换机(虚机)'},{'flag':'1','value':'3f367296c2174b7981342dc6fcb39d64','label':'防火墙'},{'flag':'1','value':'8a3e05eeedf54f8cbed37c6fb38c6385','label':'负载均衡'},{'flag':'1','value':'4f0ebc601dfc40ed854e08953f0cdce8','label':'其他设备'},{'flag':'1','value':'6','label':'路由器'},{'flag':'1','value':'4','label':'交换机'},{'flag':'1','value':'b216ca1af7ec49e6965bac19aadf66da','label':'服务器'},{'flag':'1','value':'7','label':'安全设备'},{'flag':'1','value':'cd8b768a300a4ce4811f5deff91ef700','label':'DWDM\\SDH'},{'flag':'1','value':'5','label':'防火墙(模块)'},{'flag':'1','value':'01748963956649e589a11c644d6c09b5','label':'机箱'}]";  
9.   
10.     public static void init_connection() throws Exception {  
11.         ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory("tcp://localhost:61616");  
12.         connection = factory.createConnection();  
13.         connection.start();  
14.         session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);  
15.         topic = session.createTopic("java.activemq.tps");  
16.         producer = session.createProducer(topic);  
17.         producer.setDeliveryMode(DeliveryMode.PERSISTENT);  
18.     }  
19.   
20.     public static void sendMessage(String msg) {  
21.         TextMessage message;  
22.         try {  
23.             message = session.createTextMessage();  
24.             message.setText(str);  
25.             producer.send(message);  
26.         } catch (JMSException e) {  
27.             e.printStackTrace();  
28.         }  
29.     }  
30.   
31.     public static void close() throws Exception {  
32.         connection.close();  
33.     }  
34.   
35.     public static void main(String[] arg) throws Exception {  
36.         long start = System.currentTimeMillis();  
37.         ExecutorService es = Executors.newFixedThreadPool(10);  
38.         final CountDownLatch cdl = new CountDownLatch(size);  
39.         init_connection();  
40.         for (int a = 0; a < size; a++) {  
41.             es.execute(new Runnable() {  
42.                 @Override  
43.                 public void run() {  
44.                     sendMessage(str);  
45.                     cdl.countDown();  
46.                 }  
47.             });  
48.         }  
49.         cdl.await();  
50.         es.shutdown();  
51.         long time = System.currentTimeMillis() - start;  
52.         System.out.println("插入" + size + "条JSON，共消耗：" + (double)time / 1000 + " s");  
53.         System.out.println("平均：" + size / ((double)time/1000) + " 条/秒");  
54.         close();  
55.     }  
56. }  

影响ActiveMQ性能的几个重要因素

Queue
1、Send/dispatch Async 影响非常大

     同步异步的发送和投递，都非常影响吞吐量。另外，SystemUsage和PFC流控对同步发送有直接影响。
2、Not transacted 去掉了记录redo日志
3、Auto_ACK/Optim_ACK 优化确认

     减少交互次数
4、Non-persistence 持久化消息，跟下面几点有关

    持久化和非持久化，也是数量级的影响，毕竟为了提高可靠性，使用数据库或文件来存消息，开销非常大。
5、pendingQueuePolicy/vmQueueCursor 决定了消息存储+发送模式，影响很大

    内存最快，文件和jdbc方式更安全，但是非常慢。。。
6、producerFlowControl/memoryLimit  可能会直接block掉producer

      vmCursor+非持久时，直接变成一个内存MQ，为了不爆掉jvm，在消息积压到指定数量的时候，PFC会阻止生产消息。
7、fast/slow consumer      决定了消息处理模式

     跟上面几点有关系。

8、在connection或connectionFactory上关闭掉 copyMessageOnSend