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

Neha Narkhede edited comment on KAFKA-736 at 2/3/13 6:37 PM:
-------------------------------------------------------------

In all the tests above, the number of partitions is 1. I think to compare the 2 
patches, we don't need to worry about changing the # of partitions simply 
because there is no change in the Log layer in both patches. But, just for 
curiosity, I can give that a try. Here are the results -

Number of producer threads 20
Number of partitions 10
Batch size 100
Message size 1K

v3 patch

2013-02-03 18:34:59:834, 2013-02-03 18:35:01:327, 0, 1000, 100, 95.37, 61.8764, 
100000, 66979.2364

draft patch

2013-02-03 18:34:05:757, 2013-02-03 18:34:07:132, 0, 1000, 100, 95.37, 70.3581, 
100000, 72727.2727

Still a ~13 % performance degradation
                
      was (Author: nehanarkhede):
    In all the tests above, the number of partitions is 1. I think to compare 
the 2 patches, we don't need to worry about changing the # of partitions simply 
because there is no change in the Log layer in both patches. But, just for 
curiosity, I can give that a try.
                  
> Add an option to the 0.8 producer to mimic 0.7 producer behavior
> ----------------------------------------------------------------
>
>                 Key: KAFKA-736
>                 URL: https://issues.apache.org/jira/browse/KAFKA-736
>             Project: Kafka
>          Issue Type: Improvement
>          Components: producer 
>    Affects Versions: 0.8
>            Reporter: Neha Narkhede
>            Assignee: Neha Narkhede
>            Priority: Blocker
>              Labels: p2, replication-performance
>         Attachments: check-message-ordering.py, kafka-736-draft.patch, 
> kafka-736-v1.patch, kafka-736-v2.patch, kafka-736-v3.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I profiled a producer throughput benchmark between a producer and a remote 
> broker. It turns out that the background send threads spends ~97% of its time 
> waiting to read the acknowledgement from the broker.
> I propose we change the current behavior of request.required.acks=0 to mean 
> no acknowledgement from the broker. This will mimic the 0.7 producer behavior 
> and will enable tuning the producer for very high throughput.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to