一次jmq性能下降的原因总结与思考

大家，好！

 我们目前使用的jmq是京东自己开发的，基于mq的一套消息机制。

我们都知道，jmq有个批量发送，一般遇到性能问题，也都建议将 单条发送改成批量发送，比如producer.send(list)。但是 改成批量发送 就一定会提高性能了吗？

 

今天遇到这样的问题。Jmq生产性能突然下降，有原来的90ms左右 下降到最低的220ms左右。下面这个图，性能突然下降。联系了 jmq负责人 林德强，他第一想到是要扩容。

下午的时候，我要上线，这个时候jmq那边仍然还没有扩容好。然后 跟JMQ管理员再次沟通，他问了下，我们是单条发送，还是批量发送（我们是批量）。随后他建议批量设小点（此时他应该是分析到了什么^_^），先改了再观察下。这次上线考虑到先前有一次批量发送jmq，单次批量内容超过2m这样的限制。考虑到双11的量，我又调整了一下，我这次就将一次发送，劈成3份，比如120条数据，分三次生产（先前是2次，分两份），像下面这样，这次分成三份。

producer.send(subList0);

producer.send(subList1);

producer.send(subList2);

 

5点后开始上线，然后，调取jmq的监控，如下

重新恢复成90ms左右。这个时候 jmq那边并没有扩容。看下面的调用量也上来了。性能反而提升上来了。

总结思考的时候到了，哈哈，如下：

 

再说下，jmq集群和负载策略。Jmq的负载跟JMQ管理员沟通，他们是随机策略。

 

这个问题就好比这样描述，举个例子

请求条件1：100w请求，每个请求2m

请求条件2：50w请求，每个请求4m，

问题：一个固定现有集群的性能在哪种条件下表现好。根据我们实际的上线结果看，显然是请求条件1，100w请求，每个请求2m

 

那也就是说，这个集群，比如一共200台机器，条件50w请求的情况下，根据它的负载策略，有些机器是闲着的。而有些机器已经比较繁忙了。批量太大，同一时间都分发到同一个broker了。

 

这样，我们并没有扩容，实际上是：我们没有充分发挥这个现有的集群的性能。