[ 
https://issues.apache.org/jira/browse/ROCKETMQ-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906094#comment-15906094
 ] 

ASF GitHub Bot commented on ROCKETMQ-80:
----------------------------------------

Github user coveralls commented on the issue:

    https://github.com/apache/incubator-rocketmq/pull/53
  
    
    [![Coverage 
Status](https://coveralls.io/builds/10543227/badge)](https://coveralls.io/builds/10543227)
    
    Coverage increased (+0.9%) to 31.863% when pulling 
**854d4693ad99ae12485762f1f3bec9a43ae3c8c7 on dongeforever:ROCKETMQ-80** into 
**d7decc84abc32dab63ee423d4d904f28d18cb1d7 on apache:develop**.



> Add batch feature
> -----------------
>
>                 Key: ROCKETMQ-80
>                 URL: https://issues.apache.org/jira/browse/ROCKETMQ-80
>             Project: Apache RocketMQ
>          Issue Type: New Feature
>    Affects Versions: 4.1.0-incubating
>            Reporter: dongeforever
>            Assignee: dongeforever
>             Fix For: 4.1.0-incubating
>
>
> Tests show that Kafka's million-level TPS is mainly owed to batch. When set 
> batch size to 1, the TPS is reduced an order of magnitude. So I try to add 
> this feature to RocketMQ.
> For a minimal effort, it works as follows:
> Only add synchronous send functions to MQProducer interface, just like 
> send(final Collection msgs).
> Use MessageBatch which extends Message and implements Iterable<Message>.
> Use byte buffer instead of list of objects to avoid too much GC in Broker.
> Split the decode and encode logic from lockForPutMessage to avoid too many 
> race conditions.
> Tests:
> On linux with 24 Core 48G Ram and SSD, using 50 threads to send 50Byte(body) 
> message in batch size 50, we get about 150w TPS until the disk is full.
> Potential problems:
> Although the messages can be accumulated in the Broker very quickly, it need 
> time to dispatch to the consume queue, which is much slower than accepting 
> messages. So the messages may not be able to be consumed immediately.
> We may need to refactor the ReputMessageService to solve this problem.
> And if guys have some ideas, please let me know or just share it in this 
> issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to