一次jmq性能下降的原因总结与思考
来源:互联网 发布:mac系统密码忘记 编辑:程序博客网 时间:2024/04/27 23:13
大家,好!
我们目前使用的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了。
这样,我们并没有扩容,实际上是:我们没有充分发挥这个现有的集群的性能。
- 一次jmq性能下降的原因总结与思考
- 思考与行动——执行力下降的原因
- TCP层性能优化:nagles算法与延迟ack共同工作导致的一次性能下降
- 一次真实项目性能测试与调优的总结
- 一次性能测试总结
- Iterator的总结与思考
- 性能思考总结
- 有关剃度下降和随机剃度下降的思考
- 梯度下降优化方法的思考
- Linux操作系统时间相关函数性能下降原因分析
- 一次BUG定位的过程与总结
- UITableView性能优化-一次面试后的反思总结
- 一次关于mongodb性能踩坑的总结
- 一次关于mongodb性能踩坑的总结
- 一次关于mongodb性能踩坑的总结
- 导致软件可维护性下降的四个原因
- 查找网站流量下降的原因
- Flash,一次Bug的思考
- 【bzoj1192】[HNOI2006]鬼谷子的钱袋
- ios判断邮箱,手机号码,车牌号是否合法(正则表达)
- Zend Studio改变字体大小
- java字节流与字符流区别
- javascript中call和apply
- 一次jmq性能下降的原因总结与思考
- JS组件系列——两种bootstrap multiselect组件大比拼
- 转:对称加密与非对称加密
- 【原创】【NOIP】火柴棒等式
- JS自定义选择器
- 输出文件
- 原生代码中接入React Native
- 微信号开通检测软件全面对比(2017)
- 【LIS】 洛谷 HAOI2007 上升序列(Longest Increasing Subsequence)