Hi,

第一个问题,确实这里涉及到了一次拷包,这里如果不聚合的话,写真正的File的IO次数会更频繁的,对于你说的Body非常的的情况下,这种情况瓶颈一般在磁盘上,但这里有优化的余地,可以节约点CPU。
第二个问题,现在主从同步双写的话确实会因为线程阻塞导致性能受到影响,我们也正在改造成全异步的形式。

祝好

2018-03-13 11:56 GMT+08:00 李煜洲 <iamzhou...@gmail.com>:

> hi,大家好。我是美团基础架构部的李煜洲,最近在对rocketmq做一些性能方面的测试,在阅读代码的时候发现两个问题,希望和大家讨论一下
> 1、AppendMessageResult doAppend函数,作用是把具体的消息格式化并刷到Commitlog的byteb
> uffer里面,但是感觉处理逻辑有些性能损耗,我看代码是先把message的消息内容以及等等一些信息统一写
> 到名为msgStoreItemMemory的bytebuffer里面,然后再把msgStoreItemMemory刷到底层comm
> itLog的bytebuffer里面,感觉如果我的单条消息的body非常大的话,反复拷贝来拷贝去带来的性能开销还是蛮大的
> 2、发送消息后处理落盘方式和主从同步的代码部分,感觉这部分完全可以异步化的,但是我看代码使用了wait和notify的方式进行了,
> rocketmq也是用的reactor网络模型,在真实网络环境下,主从同步不及时是比较容易出现的问题,一旦用了wait+notify
> 意味着上面的处理线程会被堵住,整体的吞吐就上不去了,周末对rocketmq做性能测试,主要耗时点有一个就是加锁解锁,感觉和这个有很大关系
>

Reply via email to